have few minutes?
we located some bug in hm2 and I wanted you to confirm patch
the stepgen thing on the sf bugtracker?
i'm swamped with dayjob work right now, but i'll look at it later today or tomorrow
micges: what is the issue? (with the 'tool crash when stop')
It look like emctask hangs for a while after hitting escape
only if you have interp queue full
(when you have >1000 g1 lines)
hang is nothing danger, worse that while hangs emc is going is some direction (!)
is that on 2.4?
don't know yet
I think I saw that on my lathe once
if so, I have long evening...
actually I recall now it was while jogging with the MPG
JT-Work: you have 2.4 pre on lathe?
it just took off and my left hand did it's job on the big red button
I love hitting BRB at full speed ;)
yesterday I've spotted stepgen bug after I've done that :D
the program start button is very close to the BRB
that the one you were talking about earlier about?
and another one that joints are not unhomed when hitting estop, only if you hit machine off
ouch for a stepper machine for sure
I'll keep that bug report in the back of my head until I see a fix for it...
JT-Work: it would be cool if you can remember things that lead to bug you saw
I was jogging the Z axis with the MPG using a scale of 0.1000" per click and when I stopped turning the MPG it kept going slowly till I hit the BRB
I don't have mpg to test it
it only did it once but 0.1000 was too fast to jog so I removed that option
* JT-Work has to run and hang some steel
ewww, 'tool crash' bug is in 2.4 too...
good news is that I found commit that mess that thing, don't know yet why
micges: got a link to the commit number?
[20:55:09] <micges> http://git.linuxcnc.org/gitweb?p=emc2.git;a=commit;h=74ce25ac44d72ba18c5a229ef813cae0377bc26b
looks like interp synch is called in bad moment
I wonder how your change makes sense
synch() is for interp to get the current status from outside
I'm not sure the SET_MOTION_CONTROL_MODE() in there isn't a problem
rather this is becouse removing this one line fixes it
I think the proper fix is to add a new _setup variable called tolerance
and remember _setup.tolerance = GET_EXTERNAL_*
then later when _setup.control_mode is used to issue some SET_*, do the same for _setup.tolerance
this fix was for issue that after estop, ferror and such emcmot reset blending to G64 and canon did not
I think whole idea that this code was added here is wrong
blending issue after estop is that task didn't execute states gcodes "G64 Pnn" when running from line, that's main problem
this was only workaround
where are you working now?
I'm on the way home, stopped at the Chicago airport for a couple of hours
alex_joni: tomorrow I'll revert that commit, need rt machine to check runtests
Just this once .. here's the log: http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2010-04-14.txt
ries_ is now known as ries