No control of Z axis on tool change

[ersdds]

Whenever I have a tool change and a pause, the Z-axis does not move. After there is a new tool in place it doesn't seem to be zeroed with Z-axis control. I have been recording the line number of code, Stopping the CNC, Using touch Z, Lifting the bit to the level it was at, at the line of code it paused on, Then, issuing a goto command and finally a resume and I think I even need a go to the next lint to get it to restart. I assume I'm doing something wrong since surely others have had this issue?

[madgrizzle]

Which release version of webcontrol?

[ersdds]

Version v0.9333 I think I had the same issues in ground control when I was using it. Is there anything I can do with G-code to unlock the Z-axis? I imagine everything is locked. Another small point. When the machine asks for a new tool it goes to +5mm or whatever the setting is. If the Z-Axis becomes accessible, once the tool is replaced it would be nice to leave the new tool at zero and the g-code resume from zero Z, instead of +5mm. If you forget to move your tool up, you destroy your work.

[madgrizzle]

Can you send gcode to madgrizzlemaslow at gmail dot com with a file that is causing an issue?

[madgrizzle]

Thanks for the file. I think part of the issue is that Estlcam is setup to put in a "stop" command (M0) that causes the controller to pause. WebControl catches this and enables the resume button. However, it doesn't allow (or at least currently allow) any move to take place. Once you press resume, it just resumes the cut.

But, Maslow and WebControl support the tool change gcode command, M6, which does allow you to move while paused. If you replace the M00 with T1 M06 then it will pause and alert you to insert tool 1. There's another tool change later on, for part 4 so you would need to replace that M00 with T2 M06 so it will pause (if the machine is asked to change to tool 1 and it already has tool 1, it won't stop and will keep cutting). You need to do this for each tool change.

But better still, try to change Estlcam as follows and see what it produces:

I think that will produce Maslow-compatible tool change messages instead of using M00.

[madgrizzle]

Sorry, I noticed the cursor got caught in the screenshot. The middle line should be:

T<t> M06 (Change tool: <n>)

[ersdds]

You're the best;-)

Thanks That helps alot

[madgrizzle]

Nevertheless.. I don't think the intent is to lock up the machine because of a M0 (or M1) command..so that's something to look into .

When the machine asks for a new tool it goes to +5mm or whatever the setting is. If the Z-Axis becomes accessible, once the tool is replaced it would be nice to leave the new tool at zero and the g-code resume from zero Z, instead of +5mm. If you forget to move your tool up, you destroy your work.

Try it out with the Tx M6 command. We worked hard to get it to automatically revert back to the correct position when you hit resume after changing the bit. Try it on some test files/scrap and let me know if it doesn't "just work".

[madgrizzle]

@gb0101010101, the issue is the functionality of the M0/M1 commands. These are commands to pause the controller. The controller, itself, stops responding to commands until it receives a "~" (that's grbl). So should we support moves during an M0/M1 command? We can kick it out of pause mode by adding this to the managePause function in serialPortThread

self.data.quick_queue.put("~")

It would unlock the controller so it will respond to moves after an M0 or M1 command is issued. But then it really isn't a command to pause the controller but rather a command to pause webcontrol. That is, it tells the controller to pause and then resume right afte.. negating the pause command.. and its webcontrol that enters into a paused state. I think I'm ok with this since webcontrol is rather tightly coupled to the maslow firmware at this point.

[ersdds]

When you say to revert back to the pre-tool change position, does that mean x y and z should go back to where they were prior to the tool change? Are those variables stored prior to the tool change? If you are using the touch zero command I believe it not only stops the machine at zero but pushes the zero to the z reference. Reason I am asking about x and y coordinate, is because sometimes when the router is down low it's easier to do a tool change if you can raise the Maslow sled up and then resume its coordinate position? Not a necessity but it would be nice to know if that's a capability.

[madgrizzle]

Yes. the intent is to track all that (x, y, and z position, as well as other things) and after the user does whatever, moves the sled to where it was when the tool change was initiated. This should be the case for things like user initiated pause and gcode pauses as well. The idea is that when you hit resume, it should go back to where it was and how it was when the pause button was pressed.

[madgrizzle]

Just note, when it does a x,y move to return to its previous position, it lifts the z-axis to whatever is defined as the safe height. So if you set z=zero, you don't have to worry about raising it when you hit resume as webcontrol will do that for you (and then when its where its supposed to be, put the z-height to where it was when the pause occurred).

[ersdds]

That's Awesome!!

[gb0101010101]

@madgrizzle AFAIK M0 is like an emergency pause rather than something that is needed/wanted before a tool change or on standard workflow. I don't think it should allow movement. I checked the firmware and M0 does put controller in pause() which requires sending "~" to resume. So no gcode can be sent until it is resumed. Current WebControl mimics the state of firmware, which is good, but could be modified.

@ersdds Is M0 required in your gcode for any particular reason? What functionality do you need that is not doable using other M commands? Perhaps you want M5 (spindle stop) and M3/M4 (spindle on Clock/counterclock)? These do not pause the controller. M6 auto triggers spindle off when tool number changes.

@ all: Pretty sure that 'M06/M6' tool change is working and allows Z-axis movement. Could have sworn I was using "goto zero" when tool change was triggered. The Z-axis move did revert back to auto saved pre tool change height. We could certainly allow movement after M0 but would need to make it work like M6 restoring position.

[madgrizzle]

His CAM program just issues an M0 at tool changes so the user can change the tool. I suggested a setting change to Estlcam to produce the Tx M6 instead.

In the firmware, M0 and M1 are treated the same (pauses). In webcontrol, we could make M0 a blocking pause (by not issuing a ~) and M1 a nonblocking pause (by issuing a ~).

[gb0101010101]

His CAM program just issues an M0 at tool changes so the user can change the tool. I suggested a setting change to Estlcam to produce the Tx M6 instead.

Yes, This is probably an issue with CAM program that might be fixed for @ersdds unique case rather than making a broad feature change in WebControl. Suggest checking settings for gcode export in CAM software so that M0 is not added as it does not appear to be applicable. Or possibly creating a MaslowCNC gcode post processor to ignore it like the one we have for Fusion360.

In the firmware, M0 and M1 are treated the same (pauses). In webcontrol, we could make M0 a blocking pause (by not issuing a ~) and M1 a nonblocking pause (by issuing a ~).

AFAIK M1 has be deprecated in many CNC applications and reverts to M0. So don't know if we should treat them differently as it may be a step back. If you really want to make a distinction between these then Maslow Firmware would need be updated to support it (again).

Queues and states

I have thought about this a bit, may have mentioned it before, but can't remember, so forgive me if I did not. It would be good to create a class to track states consistently for Controller, WebControl Gcode file, WebControl UI Gcode interactions. This would require a new python queue for UI initiated gcode sent from WebControl. So have existing _gcode_quickqueue for emergency operations, _gcode_filequeue for gcode from project file, and _gcode_uiqueue for all movements caused by UI interaction.

The common state/status class for each queue could store all necessary variables like X, Y, Z, positioning mode, tool, etc and provide methods to compare states, deal with differences between states, and revert states automatically.

We could then pause _gcode_filequeue, save state, keep the other queues functional allowing for manual UI interaction, then easily revert state using comparison methods, and resume _gcode_filequeue operation with minimal code.

@madgrizzle, can you PM me the sample gcode file provided by @ersdds on Malsow Forums so I can check it out?

UI States

I also have back-burner branch code that limits WebControl UI functionality based on Controller state. This defaults to disabling all WebControl UI controls (menus and buttons) until controller responds allowing certain operations. This will help reduce problems when multiple devices connect to WebControl whilst a gcode file is running.