Saved Z axis value wrong when Pause button clicked whilst Z axis in motion

[gb0101010101]

When the Pause button is clicked whilst Z axis is in motion, it saves the current Z axis position, which is then wrong when Resume button is clicked as the Z axis continues to move until gcode command has completed. The resumeRun() action restores the wrong Z position which can cause big problems if the next gcode line does not set the correct Z height.

Right now the only way I see to fix this is to:

1. Stop all UI interaction, after Pause button click, until the Maslow has stopped moving
2. Get a position update from controller when Maslow has stopped and update the Paused Z height
3. Enable UI interaction and resume as normal

Unfortunately I don't know how to do point 2. If anyone can point me it the right direction I can work on a fix.

[madgrizzle]

Wow.. yeah, didn't think about that.

I think the only way to handle this is to parse the gcode that is being sent and keep track of the target Z height. Then, when the pause button is pressed, set that as the pausedzval.

Inserting a function in sendNextLine of serialPortThread, maybe after manageToolChange(), seems to make sense. This function (stolen from gcodeFile.py) should provide the target z-axis..

z = re.search("Z(?=.)(([ ]*)?[+-]?([0-9]*)(\.([0-9]+))?)", line)
      if z:
              zTarget = float(z.groups()[0])

[gb0101010101]

Keep in mind all Gcode that can provide Z like G2 & G3. Does the Malsow always pause operation after last gcode has completed?

[madgrizzle]

I think all gcode movement commands specify the target coordinates so we should good just parsing out the data of the gcode line. Of course, you need to account for absolute and relative positioning...

The controller doesn't actually 'pause' when you hit the pause button. Webcontrol (and ground control) just stops sending gcode when the user hits pause. If buffering is disabled, the controller will stop after the current gcode line is completed.. but if buffering is enabled, the controller will stop whenever its buffer is empty.. but the correct target Z location will still be the last line Webcontrol sent the controller.

[gb0101010101]

I been reading the firmware code and see that it has Pause and Stop states. I found sending serial ! tells it to stop. Does ~ make it pause? If not do you know what does?
I also see that controller sends state info back via serial
<Idle,MPos:-2.69,0.99,-2.44,WPos:0.000,0.000,0.0>..[PE:-0.07,0 .06,127]..
Where Idle is state. Do you know what MPos and WPos stands for? WPos always seems to be 0,0,0 but I am using FakeServo.
Maybe we should add to firmware to get controller reporting actual position (and relative/absolute mode) when requested so that we do not have to work it out and store it in WebControl?

[madgrizzle]

The controller can pause on its own when there's a tool change..(maybe something else as well?) and that pause indicator can let webcontrol/ground control know its paused. The '~' releases it from pause state. But webcontrol/ground control watches for the "tool change" in the data stream to notify the user. Webcontrol just recently started parsing the pause/idle states just to throw it up on the UI because its there.

MPos and WPos are Machine Space Pos and Work Space Pos.. they mimic grbl messages.. but the controller doesn't support work spaces so WPos is meaningless. I think they put it in with an eye on the future.

I think a lot could be done better if the firmware was reporting things back differently.. but I've avoided trying to change the firmware since it can impact ground control. Case in point, holey calibration is still not brought into the main branch. I think, however, if changes are made to the holey calibration branch on my repo (or whosoever) then it can be incorporated into webcontrol.. just might not be compatible with ground control.

[gb0101010101]

Thanks for the info. Will look into it further.

[madgrizzle]

Thanks for looking into it!

[madgrizzle]

I went ahead and put it in.. in process I discovered another bug, so fixed it.

[madgrizzle]

I also noticed that if the gcode doesn't include an initial z-axis move before an xy move, then the z-target during the xy move will be 0 (because the value is uninitialized). I added a line to set the current z-target to equal the current zpos at the beginning of startRun().