Support M0 pause for tool changes

tbfleming commented 7 years ago

It'd be nice to support this to allow tool changes:

Program pauses at M0
A notification shows comment on M0 line. e.g. "Switch to tool 7"
User can jog, set zero, and enter manual commands
A resume button (maybe the run button) continues running code

We'd probably have to do this client side. grbl allows jogging during M0 pause, but doesn't execute any sync commands, such as set zero, during pause.

tbfleming commented 7 years ago

One of the few places I believe a pop-up is in order. It'd have the message, but not interfere with the left side.

cprezzi commented 7 years ago

Smoothieware doesn't support M0-M2 (according to http://smoothieware.org/supported-g-codes) but M600 sounds to do the same. If M600 works, I would be able to replace all M0 by M600 for Smoothieware on server side.

cprezzi commented 7 years ago

Mach3 uses Tx M6 for Tool Change.

arthurwolf commented 7 years ago

The way we understand it, T/M6 is for automated tool change, while M0 means "pause until the user manually presses the 'continue' button" ( presumably to manually change a tool ) We plan on implementing both with smoothie v2, v1 lacks space a bit.

On Fri, Jul 14, 2017 at 6:46 PM, Claudio Prezzi notifications@github.com wrote:

Mach3 uses Tx M6 for Tool Change.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/LaserWeb/LaserWeb4/issues/378#issuecomment-315408093, or mute the thread https://github.com/notifications/unsubscribe-auth/AAGpFZSMIjtXd3_3pbHoEt5a0tAzDl80ks5sN5tWgaJpZM4OYPAx .

-- Courage et bonne humeur.

tbfleming commented 7 years ago

If we do this client side, then neither Smoothie nor grbl will see the M0.

arthurwolf commented 7 years ago

the controller doesn't really need to see the M0 ... 1) see M0 in gcode stream 2) stop sending gcode 3) wait for user to press "resume" button ( in lw ) 4) start sending gcode again

as I understand it this is a correct implementation of M0, and doesn't require anything on the controller's side ( it would if the "resume" button was plugged into the controller instead of in lw's gui )

On Fri, Jul 14, 2017 at 6:51 PM, Todd Fleming notifications@github.com wrote:

If we do this client side, then neither Smoothie nor grbl will see the M0.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/LaserWeb/LaserWeb4/issues/378#issuecomment-315409336, or mute the thread https://github.com/notifications/unsubscribe-auth/AAGpFSszYYx5jQpaboPyYORWY0YQmYjsks5sN5yMgaJpZM4OYPAx .

-- Courage et bonne humeur.

tbfleming commented 7 years ago

Yep.

cprezzi commented 7 years ago

Ok, that sounds doable too.

cprezzi commented 7 years ago

But what if the gcode is run from SD card?

arthurwolf commented 7 years ago

then you can't really do anything about it currently

On Fri, Jul 14, 2017 at 7:17 PM, Claudio Prezzi notifications@github.com wrote:

But what it the gcode is run from SD card?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/LaserWeb/LaserWeb4/issues/378#issuecomment-315415409, or mute the thread https://github.com/notifications/unsubscribe-auth/AAGpFRHZW8tk419j3fjPHLSpaTebiw_Pks5sN6KvgaJpZM4OYPAx .

-- Courage et bonne humeur.

cprezzi commented 7 years ago

Is M600 in a gcode file running from the SD card not suspending the job and can be resumed?

arthurwolf commented 7 years ago

nope, I don't expect to. M600 is meant to be sent from a switch module or the serial connection or the screen

On Fri, Jul 14, 2017 at 8:50 PM, Claudio Prezzi notifications@github.com wrote:

Is M600 in a gcode file running from the SD card not suspending the job and can be resumed?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/LaserWeb/LaserWeb4/issues/378#issuecomment-315438409, or mute the thread https://github.com/notifications/unsubscribe-auth/AAGpFd_NSK2EaYuT8_o4EdRHNlPDLvsmks5sN7iTgaJpZM4OYPAx .

-- Courage et bonne humeur.

cprezzi commented 7 years ago

I'm working on the M0 for tool change. At the moment, when the queue detects an M0, the streaming stops and sets the runStatus to paused. The frontend is then waiting for the "resume job" button to be clicked. Peter somewhen implemented disabling of all jog buttons while on pause, but I think we need jogging for toolchange, right?

@tbfleming @openhardwarecoza @cojarbi What is the exact process needed for a manual tool change?

tbfleming commented 7 years ago

Short term plan for lathe:

M0 with message
User jogs to a spot where it's safe to change tools
User changes tool
User jogs and sets zero
Resume

Long term plan for lathe:

CAM produces gcode which moves to a spot where it's safe to change tools
M0 with message
User changes tool
Resume. CAM uses tool table to adjust the gcode it generates. grbl's tool length offsets right now aren't suitable for lathes; I may fix that.

Mill is probably similar, but user could also use probing to set tool offset.

ghost commented 7 years ago

Yip would need jogging active when paused. The disabled buttons on jog is for during PLAY. Anytime its not playing (paused, stopped, disconnected, lost connection, aborted, in M0, etc) it should be enabled (now that you mention it, i should open an issue. When usb connection gets lost, upon reconnecting, buttons stay disabled)

On Jul 18, 2017 6:32 PM, "Claudio Prezzi" notifications@github.com wrote:

I'm working on the M0 for tool change. At the moment, when the queue detects an M0, the streaming stops and sets the runStatus to paused. The frontend is then waiting for the "resume job" button to be clicked. Peter somewhen implemented disable of all jog buttons while on pause, but I think we need jogging for toolchange, right?

@tbfleming https://github.com/tbfleming @openhardwarecoza https://github.com/openhardwarecoza @cojarbi https://github.com/cojarbi What is the exact process needed for a manual tool change?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/LaserWeb/LaserWeb4/issues/378#issuecomment-316120955, or mute the thread https://github.com/notifications/unsubscribe-auth/AHVr23gYaC_Il-wuSWgp4c1VajxWL5Usks5sPN4IgaJpZM4OYPAx .

cprezzi commented 7 years ago

Ok. I made toolchange an additional status and only special commands like jogging, probing or setZero of Z are allowed in this status.

Probably it would be good to let the user define pre-M0 and post-M0 gcodes. This way the user could define where/how to move for toolchange and how to get back to the location before.

ghost commented 7 years ago

Yay! I like. Dedicated statusses in backend make debugging and changes easier.

Now, @tbfleming you know its not going to be long will we want Tools in CAM now (; lol.

On Jul 18, 2017 8:54 PM, "Claudio Prezzi" notifications@github.com wrote:

Ok. I made toolchange an additional status and only special commands like jogging, probing or setZero of Z are allowed in this status.

Probably it would be good to let the user define pre-M0 and post-M0 gcodes. This way the user could define where/how to move for toolchange and how to get back to the location before.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/LaserWeb/LaserWeb4/issues/378#issuecomment-316162868, or mute the thread https://github.com/notifications/unsubscribe-auth/AHVr24Lo5opf7g9QoXGXJl3c7e1jZGvOks5sPP9cgaJpZM4OYPAx .

tbfleming commented 7 years ago

Now, @tbfleming you know its not going to be long will we want Tools in CAM now (; lol.

Yep. I need to add a tool table for lathe.

ghost commented 7 years ago

Yay!

On Jul 18, 2017 9:42 PM, "Todd Fleming" notifications@github.com wrote:

Now, @tbfleming https://github.com/tbfleming you know its not going to be long will we want Tools in CAM now (; lol.

Yep. I need to add a tool table for lathe.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/LaserWeb/LaserWeb4/issues/378#issuecomment-316175742, or mute the thread https://github.com/notifications/unsubscribe-auth/AHVr294fwTKC53ne13MZUr1NtO38sWUfks5sPQq_gaJpZM4OYPAx .

jorgerobles commented 7 years ago

Is that on cnc or also on 3dprint? I expected to use regular filament change plugin from cura on my next reprap iteration...

El 14 jul. 2017 9:22 p. m., "Arthur Wolf" notifications@github.com escribió:

nope, I don't expect to. M600 is meant to be sent from a switch module or the serial connection or the screen

On Fri, Jul 14, 2017 at 8:50 PM, Claudio Prezzi notifications@github.com wrote:

Is M600 in a gcode file running from the SD card not suspending the job and can be resumed?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub <https://github.com/LaserWeb/LaserWeb4/issues/378#issuecomment-315438409 , or mute the thread https://github.com/notifications/unsubscribe-auth/AAGpFd_NSK2EaYuT8_ o4EdRHNlPDLvsmks5sN7iTgaJpZM4OYPAx .

-- Courage et bonne humeur.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/LaserWeb/LaserWeb4/issues/378#issuecomment-315446011, or mute the thread https://github.com/notifications/unsubscribe-auth/ABoIYICjEfV35WK93f1LSQ9xMB1xWDFfks5sN8AJgaJpZM4OYPAx .

tbfleming commented 7 years ago

Ok. I made toolchange an additional status and only special commands like jogging, probing or setZero of Z are allowed in this status.

Short term: Lathe will need setZero of X

Long term: Lathe will need setDiameter of X: user jogs to touch tool to workpiece, and enters measured diameter. Sets X to either +Diameter/2 (for back tools) or -Diameter/2 (for front tools).

ghost commented 7 years ago

Shouldnt we catch M6 then too? Since many other CAMs use M6 Tx as the command? Just in case

tbfleming commented 7 years ago

I just realized: Lathe will need to set Z to a user-entered value also. The first op often shaves away Z=0, leaving Z=some other value as a touch point.

arthurwolf commented 7 years ago

M0 and M6 are two very different things. M0 is "wait for user to press button before continue" and M6 is "automatically change tools". All users will want M0 to do the same thing, but some users will want M6 to be the same as M0, but others will want M6 to be up to the controller. Thinking about it some users will want M0 too to be up to the controller ...

On Tue, Jul 18, 2017 at 9:51 PM, Peter van der Walt < notifications@github.com> wrote:

Shouldnt we catch M6 then too? Since many other CAMs use M6 Tx as the command? Just in case

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/LaserWeb/LaserWeb4/issues/378#issuecomment-316177920, or mute the thread https://github.com/notifications/unsubscribe-auth/AAGpFb9QUSh61nqwIDQFXIyKfSx405Tvks5sPQzIgaJpZM4OYPAx .

-- Courage et bonne humeur.

ghost commented 7 years ago

Well aware of the diff... But ... CP handles the M6 in host... works well with Grbl and TinyG (Remember, we are a multi firmware host)

arthurwolf commented 7 years ago

I'm not talking about any particular firmware, just saying you most probably want a configuration option to let users choose what M0 and M6 do since different users will want them to do different things.

On Tue, Jul 18, 2017 at 9:56 PM, Peter van der Walt < notifications@github.com> wrote:

CP handles the M6 in host... works well with Grbl and TinyG (Remember, we are a multi firmware host)

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/LaserWeb/LaserWeb4/issues/378#issuecomment-316179100, or mute the thread https://github.com/notifications/unsubscribe-auth/AAGpFYx6gpMqZ1KQAP3xyz-kV-Gp0nbmks5sPQ3TgaJpZM4OYPAx .

-- Courage et bonne humeur.

ghost commented 7 years ago

https://github.com/grbl/grbl/issues/1103#issuecomment-251807161 (Explains Grbl implementation of M6)

https://github.com/synthetos/TinyG/issues/186#issuecomment-263029588 (Explains CP+TinyG use of M6)

https://github.com/vlachoudis/bCNC/wiki/Tool-Change (bCNC M6)

Mach3: Calls a Macro when M6 is encountered:

Here is the default Mach3 M6 tool change macro scripts.

C:\Mach3\macros\Mach3Mill\M6Start.m1s
Code:
  tool = GetSelectedTool()
  SetCurrentTool( tool )
C:\Mach3\macros\Mach3Mill\M6End.m1s
Code:
x = GetToolChangeStart( 0 )
y = GetToolChangeStart( 1 )
z = GetToolChangeStart( 2 )
a = GetToolChangeStart( 3 )
b = GetToolChangeStart( 4 )
c = GetToolChangeStart( 5 )
if(IsSafeZ() = 1) Then
   SafeZ = GetSafeZ()
   if  SafeZ  > z then StraightTraverse x, y,SafeZ, a, b, c 
      StraightFeed  x, y,  z  , a, b, c
else
Code"G00 X" & x & "Y" & y
end if

Tormach: https://www.tormach.com/m6.html Calls a macro too

LinuxCNC: Pauses and prompts (same as M0 in LW): http://linuxcnc.org/docs/html/gcode/m-code.html#mcode:m6

Due to the popular use (abuse) of M6, we can't really ignore it. None of the targetted controllers has an automated tool changer that reacts to M6. Things like XTC (Xpix) would also rely on the Macros instead.... So if anything, we should make M0 pause only, and M6 should pause, maybe call macros?

cprezzi commented 7 years ago

Jep, we should support M0 and M6 Tx. M0 hast to be implemented in the backend, as it has to stop the streaming. The M6 could probably be implemented in the frontend (before sending the gcode to the backend) and use a pre- and post macro (in which M0 could be used).

cprezzi commented 7 years ago

@arthurwolf Yes, it probably makes sense to make the behaviour for M0/M6 configurable or dependant to the used firmware.

cprezzi commented 7 years ago

I've implemented M0 support in https://github.com/LaserWeb/lw.comm-server/tree/Toolchange (needs actual lw4/dev-es6).

Can someone test please?

This is the actual implementation:

M0 in the code stops streaming (server side)
The frontend shows the job like paused (Run Job button with play sign)
In this mode, supported functions (like jogging, probing, setZero...,) are sent directly to the machine instead of adding at the end of the queue
Clicking the play button resumes from M0, which resumes the queue

To initiate a "toolchange" in the cam, you can create a M0 Toolchange macro with only M0 in it and assign this macro as the post-operation macro (or pre-operation of next operation).

The presentation to the user is not finished yet. I would prefer a tri-state button Run Job / Pause Job / Resume Job instead of just Run Job and probably a better state display at the top.

cprezzi commented 7 years ago

Think about the following scenario:

The first operation stops at a certain location with a M0.
The user joggs out of the area to change the tool.
After changing the tool he runs a probe z for tool-length compensation (or does a manual touch probe an setZero).
Then he would like to resume from M0, but first he would need to jog back to the former location (which he doesn't remember).

Would it be ok to save the actual location from the moment of the M0 and restore this location when the M0 is resumed? Alternatively I could provide a function to get back to that position.

ghost commented 7 years ago

The first G0 'should' bring you back to where it should be unless you do something stupid like setzero (keep button disabled) or manually break the coordinate system. Per axis comms (on the dropdown in the dro) has to be used to zero and probe

On Jul 27, 2017 5:48 PM, "Claudio Prezzi" notifications@github.com wrote:

Think about the following scenario:

The first operation stops at a certain location with a M0.

The user joggs out of the area to change the tool.

After changing the tool he runs a probe z for tool-length compensation (or does a manual touch probe an setZero).

Then he would like to resume from M0, but first he would need to jog back to the former location (which he doesn't remember).

Would it be ok to save the actual location from the moment of the M0 and restore this location when the M0 is resumed? Alternatively I could provide a function to get back to that position.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/LaserWeb/LaserWeb4/issues/378#issuecomment-318403217, or mute the thread https://github.com/notifications/unsubscribe-auth/AHVr2-vawuaFG47ny0uqha3jf0gmQq3Zks5sSLFlgaJpZM4OYPAx .

tbfleming commented 7 years ago

Just tried it. It works, but it doesn't allow set zero, which I need for tool changes.

tbfleming commented 7 years ago

I wish I could use G43.1 tool length offset, but grbl restricted that to Z offsets (mills). 2-axis lathes need both Z and X tool offsetting. 3-axis lathes (some day...) need X, Y, and Z offsets.

cprezzi commented 7 years ago

At the moment I did only allow setZero and Probe of Z-Axis, because on mills it would be risky to accept it on X and Y axis. How about adding a "machine type" dropdown to the machine settings (laser, mill, lathe..), which can be sent to the server for configuration?

ghost commented 7 years ago

@cprezzi : machine type: i still really want my autodetect, exactly for use cases like this... https://github.com/LaserWeb/lw.comm-server/issues/31

On Jul 31, 2017 10:46 AM, "Claudio Prezzi" notifications@github.com wrote:

At the moment I did only allow setZero and Probe of Z-Axis, because on mills it would be wrong to accept it on X and Y axis. How about adding a "machine type" dropdown to the machine profile (laser, mill, lathe..), which can be sent to the server for configuration?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/LaserWeb/LaserWeb4/issues/378#issuecomment-319006292, or mute the thread https://github.com/notifications/unsubscribe-auth/AHVr22lA6dVCNSl5glJlnXCp6MZH-4Yxks5sTZRngaJpZM4OYPAx .

tbfleming commented 7 years ago

I'm uncomfortable with settings like "machine type" since the name gives no indication to the user what the setting does. That's why I added a new "create empty operations" setting instead of "lathe mode". I probably need to come up with a better wording; it allows the Create Single button to work when no documents are selected.

I've just had to deal with a similar issue right now. My laptop battery drained because Window's "When I press the power button: Sleep" setting doesn't actually do that. Instead it should be worded "When I press the power button: Sleep unless any app says No, in that case just turn off the screen and let the app drain the battery".

cprezzi commented 7 years ago

I think it's much easyer for a user to tell if he has a mill or lathe, than understanding what "create empty operations" does and if he needs it.

cprezzi commented 7 years ago

@openhardwarecoza Autodetect would be a nice feature but I think it's not realistic to correctly detect every case of possible firmware configuration and different machine constructions. And we cannot be sure if the firmware has even been configured correctly.

Think about the oposite solution. The user selects his machine profile and everything is configured accordingly, including server ip, interface, port... and machine settings! This means we would have a firmware config dialog in LW4 which is saved in the machine profile and automatically restored when this machine is connected.

tbfleming commented 7 years ago

I'm afraid this will happen:

We add a machine type config
Someone requests machine type hides cam operations
Now people trying it for the first time think it's for lasers only. We've been here with the CAM Mode switch; not good.

I also don't look forward to this:

I plug it into my laser or help users with their laser questions. Have to switch modes. Involves digging though the settings, the most painful tab we have.
I plug it into my mill or help users with their mill questions. Have to switch modes.
I plug it into my lathe or help users with their lathe questions. Have to switch modes.

Instead, I prefer enabling everything. It's my own fault if I hit Set Zero on X during a tool change while plugged into the mill.

cprezzi commented 7 years ago

That's not the case. Once you have configured your machine profiles, the procedure would be:

Connect one ore multiple machines to the pc.
Select the desired machine profile and connect. Done!

(because the machine profile knows the interface, port, settings...)

tbfleming commented 7 years ago

I don't like step 2. Right now I safely ignore the profiles and keep all options enabled.

tbfleming commented 7 years ago

How about this: don't do any restrictions server side; do it in the UI. The more I play with the control tab using my mill, the more I'm realizing it gets in the way and needs a serious reorg.

tbfleming commented 7 years ago

Stuff I'm running into that I hope to find fixes for without hurting new users:

No clear visual indicators of current modes.
- e.g. I switch back and forth between G90 and G91 depending on which is easiest to think about for the particular area of the part I'm working on.
- e.g. I keep scrolling back though the history to see what my current F value is.
I do a lot of single-axis set-zero's (i.e. I'm using it as a DRO). Going through the drop-downs feels clumsy.
I'd like to make offsets more convenient, e.g. G92 set-zero and set-to-value shortcuts so I can keep G54 on a specific point on my part. This one's tricky since the interaction between G54 and G92 confuses new users. Maybe I'll just leave G92 manual entry only.
Hitting buttons moves focus away from the entry field. This is a tough one; I need to rethink how focus is handled across the entire app.
The help text in the entry field is distracting. Tricky since it helps train new users.
I quickly abandoned joystick. I wonder if there's a way to make it work more like a jog wheel. Maybe different joystick buttons switch modes; would need a clear on-screen indicator.

tbfleming commented 7 years ago

Idea: maybe a separate machine-control tab which covers the entire page. It'd have room for more controls and indicators. Useless for lasers, which seem to benefit from the current side-by-side approach.

tbfleming commented 7 years ago

That may be the answer:

Existing tab for lasers and new users. Loaded with restrictions to help keep users from hurting themselves or their equipment
New tab that provides full control. A I-know-what-I'm-doing-so-just-do-it tab.

cprezzi commented 7 years ago

@tbfleming I don't understand you. Why do we have machine profiles if you don't want to use it? It's much easyer to just select the machine I want to use (once it is configured), than checking all settings when I switch from smoothie to grbl!

We could replace the Comms tab with an upper toolbar (like in LW3) where the user can select the active machine profile, connect it and see status informations.

Each tab could then filter features depending on the selected machine (if any selected).

If a noob starts LW4, there is no machine profile actve and therefore no limitation. Then he configures his machine and only gets functions that are supported by his machine. That is how it should be in my opinion!

cprezzi commented 7 years ago

I do like your idea of a "extended view" for pro's! (I like the different screens of mach3)

What about a machine type (laser/mill/lathe) dependant screen? Or a user configurable screen?

tbfleming commented 7 years ago

I think we're starting to reach agreement:

Default config: no restrictions
Machine profiles: add restrictions
Upper toolbar: sounds good
Machine type defendant screen or user configurable screen: I'm leaning toward the latter since not all lathe and mill users will understand a screen loaded with offsets.

cprezzi commented 7 years ago

I would love the feature of switchable, user configurable screens. This way the community could design their own screens and contribute them to other users (like a touch device screen). 💯

LaserWeb / LaserWeb4

Support M0 pause for tool changes #378