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