Back
[13:21:36] <BigJohnT> to checkout the 2.2.6 branch what is the name of it?
[13:23:11] <jepler> BigJohnT: good morning
[13:23:19] <BigJohnT> good morning
[13:23:20] <SWPadnos> co -r v2_2_branch
[13:23:25] <SWPadnos> I think
[13:23:30] <SWPadnos> morning :)
[13:23:32] <BigJohnT> :)
[13:24:19] <jepler> to see a list of tags you can 'cvs log somefile | less' or look in the 'show only files with tag' pulldown in viewcvs
http://cvs.linuxcnc.org/cvs/emc2/
[13:25:54] <BigJohnT> jepler: thanks I was on that page but missed that, I got it now (I think) :)
[13:36:44] <BigJohnT> Ok, that is working... this will take a while on dialup :)
[14:45:45] <CIA-20> EMC: 03bigjohnt 07v2_2_branch * 10emc2/docs/src/Master_User.lyx: Organized and cleaned up parts in Master_User.lyx (index)
[14:46:45] <BigJohnT> * BigJohnT is off to check on Dad he is 82
[16:16:34] <cradek> uh-oh, stuart reported the skipping-over-arcs problem too
[16:16:45] <cradek> but he says version 2.1.xx. I wonder if it's still around.
[16:17:55] <CIA-20> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/Master_User.lyx: Organized and cleaned up parts in Master_User.lyx (index) to match 2.2.x
[17:01:06] <CIA-20> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/config/ini_config.lyx: Added HOME_FINAL_VEL to ini_config
[17:23:39] <SWPadnos> it looked like he said it was impossible to rstart from any non-motion-producing line
[17:23:42] <SWPadnos> not just arcs
[17:23:58] <SWPadnos> unless I didn't read the same thing you did
[17:38:19] <cradek> he made several reports at once, we're talking about different ones
[17:38:33] <SWPadnos> ok. I probably just scanned some of them :)
[17:52:17] <jmkasunich> SWPadnos: hi
[17:52:40] <SWPadnos> hi
[17:53:09] <jmkasunich> I'm slowly getting caught up on all the chores left over from when I was away, and starting to think about low ppr
[17:53:17] <SWPadnos> ah, ok
[17:53:27] <jmkasunich> we've talked about doing it as an extension to the main encoder module
[17:53:38] <jmkasunich> the only thing that nags me about that is that people are stupid
[17:53:42] <SWPadnos> heh
[17:53:59] <jmkasunich> somebody will try to use interpolation for position control feedback, or for rigid tapping
[17:54:26] <jmkasunich> it is _only_ usefull when speed is approximately constant, which means pretty much only lathe threading
[17:54:47] <jmkasunich> I suppose with enough words in the man page, etc, we can deal with that
[17:55:01] <jmkasunich> (won't stop them from doing it, but we can point and say RTFM when they do)
[17:55:28] <SWPadnos> anything that uses the velocity output will be improved, though it won't improve things enough to use for everything (like rigid tapping)
[17:55:37] <jmkasunich> ?
[17:55:44] <jmkasunich> the velocity output is already as good as its gonna get
[17:56:16] <SWPadnos> hmmm. are you thinking of using a significantly different algorithm for low PPR?
[17:56:30] <jmkasunich> not really
[17:56:46] <jmkasunich> position interpolation is (sort of) integrating the estimated velocity
[17:57:41] <jmkasunich> the velocity output already produces a "best guess" at the velocity in any period when there isn't an encoder count
[18:02:08] <SWPadnos> hmmm. yeah - you can never integrate past the prior pulse (or you go backwards when it arrives)
[18:02:16] <SWPadnos> err - past the next pulse position ...
[18:02:24] <jmkasunich> that issue is why I said "sort of"
[18:02:43] <SWPadnos> heh
[18:03:10] <jmkasunich> the current velocity estimate uses the previous value until it is obviously too high (when the pulse should have arrived but hasn't)
[18:03:39] <jmkasunich> then it starts ramping down, to "whatever would be the right answer if the pulse arrives a nanosecond from now"
[18:04:16] <SWPadnos> right, which is too far if the position is the integral of that
[18:04:42] <jmkasunich> and after some period ( I think its a hard-coded constant) it gives up and says "that pulse isn't coming, set the velocity estimate to zero"
[18:07:04] <jmkasunich> in the case of the position estimate, I'll have to do something different
[18:07:11] <jmkasunich> I sure don't want to go backwards
[18:07:17] <jmkasunich> and I don't want to stop abruptly either
[18:07:56] <jmkasunich> I know what I'm gonna do after a late pulse arrives - I'll use that pulse and the previous one to estimate the time for the next one, and start a linear ramp towards that position/time point
[18:08:08] <jmkasunich> (which is basically what I'll be doing for every pulse, late or not)
[18:08:28] <jmkasunich> the question is what to do between the expected arrival time and the actual arrival time, assuming the pulse is late
[18:11:07] <jmkasunich> I should probably just start coding and see what happens ;-)
[18:11:16] <SWPadnos> heh
[18:12:17] <SWPadnos> ok, you just update the ramp when the next pulse arrives, assuming that the time delta will change the same way it changed last time (ie, constant accel)
[18:12:36] <jmkasunich> actually I wasn't going to assume any change in time delta
[18:13:06] <SWPadnos> well, start coding and see if you need to ;)
[18:13:37] <jmkasunich> if you are threading and the speed is constantly dropping over multiple revs, you got real issues
[18:14:20] <jmkasunich> so I'm not planning on assuming constant accel - I'm gonna assume that any speed changes are steps, not ongoing ramps
[18:39:04] <jmkasunich> logger_dev: bookmark
[18:39:04] <jmkasunich> Just this once .. here's the log:
http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2008-06-28.txt
[18:56:22] <skunkworks> jmkasunich: did you see if changing the traj period helped the threading bobble?
[18:57:09] <jmkasunich> no, haven't done much emc stuff this week, too much catching up to do
[18:57:26] <jmkasunich> this afternoon I was cleaning maple seeds and seedlings out of the gutters
[18:58:16] <skunkworks> yeck
[18:59:26] <jmkasunich> seems like every few years the maples go nuts and produce many more seeds than usual
[18:59:29] <jmkasunich> this was one of those years
[19:18:53] <CIA-20> EMC: 03jmkasunich 07TRUNK * 10emc2/lib/python/vismach.py: allow vismach models to be viewed from all angles
[19:19:03] <CIA-20> EMC: 03jmkasunich 07TRUNK * 10emc2/lib/python/rs274/OpenGLTk.py: allow vismach models to be viewed from all angles