Guest
Show Posts
2201
Mach4 General Discussion / Re: Feed Hold in MDI Window hangs up mach 4?
« on: August 02, 2019, 09:23:12 PM »
Hi,
I don't have an answer...but rather a question.
When Mach is executing a Gcode program and you <feedhold> the buffered moves execute and then the machine stops.
Mach would transition from MC_STATE_FRUN to MC_STATE_HOLD. No problems....normal. The length of time between
you hitting <feedhold> and the machine stopping is determined by the buffer length of the your motion controller, the default
with the ESS is 180ms.
With the code you have posted the buffer will have time slices stacked up in the buffer, to the length of the buffer, all with
no motion because the Gcode is a g4 p.....Thus when you hit <feedhold> I would expect the buffered moves to be executed,
ie nothing happen as they are all no-motion time slices, and then Mach would stop. Mach would in this case transition from
MC_STATE_MRUN, because the executing code string is MDI data, to MC_STATE_MRUN_FH. Because the <feedhold> has
interrupted the Gcode interpreter I would not expect the m5 to have been interpreted and put in the buffer. In this circumstance
I would anticipate that the spindle would carry on running because you have not commanded it do otherwise.
Note that this behavior can be changed. See the attached pic. I'm guessing that these two settings add code to enact the desired
behavior to the <feedhold> function within Machs core.
Even if you make those settings as appropriate to your desired behavior that does not explain why Mach should hang
up after hitting <feedhold>.
May I suggest some experiments that explore this quirk a little further. For instance if you had a motion command that was
interrupted rather than a wait command. For example MDI:
m3
g1 x100 f100
m5
and while the X axis move is executing hit <feedhold> and see what happens.
This is normal, if Mach crashes or exits unusually then one chunk of code is left running and must be manually shut down
before you can restart. The trick is to avoid Mach crashing!
Craig
I don't have an answer...but rather a question.
When Mach is executing a Gcode program and you <feedhold> the buffered moves execute and then the machine stops.
Mach would transition from MC_STATE_FRUN to MC_STATE_HOLD. No problems....normal. The length of time between
you hitting <feedhold> and the machine stopping is determined by the buffer length of the your motion controller, the default
with the ESS is 180ms.
With the code you have posted the buffer will have time slices stacked up in the buffer, to the length of the buffer, all with
no motion because the Gcode is a g4 p.....Thus when you hit <feedhold> I would expect the buffered moves to be executed,
ie nothing happen as they are all no-motion time slices, and then Mach would stop. Mach would in this case transition from
MC_STATE_MRUN, because the executing code string is MDI data, to MC_STATE_MRUN_FH. Because the <feedhold> has
interrupted the Gcode interpreter I would not expect the m5 to have been interpreted and put in the buffer. In this circumstance
I would anticipate that the spindle would carry on running because you have not commanded it do otherwise.
Note that this behavior can be changed. See the attached pic. I'm guessing that these two settings add code to enact the desired
behavior to the <feedhold> function within Machs core.
Even if you make those settings as appropriate to your desired behavior that does not explain why Mach should hang
up after hitting <feedhold>.
May I suggest some experiments that explore this quirk a little further. For instance if you had a motion command that was
interrupted rather than a wait command. For example MDI:
m3
g1 x100 f100
m5
and while the X axis move is executing hit <feedhold> and see what happens.
Quote
Even when exiting Mach 4 - it can not be started again because a "Mach 4 GUI" Process is still running as seen in the task manager. You have to manual quit this task with windows task manager and start complete mach 4 again.
This is normal, if Mach crashes or exits unusually then one chunk of code is left running and must be manually shut down
before you can restart. The trick is to avoid Mach crashing!
Craig