Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support M0 pause for tool changes #378

Open
tbfleming opened this issue Jul 14, 2017 · 63 comments
Open

Support M0 pause for tool changes #378

tbfleming opened this issue Jul 14, 2017 · 63 comments

Comments

@tbfleming
Copy link
Member

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
Copy link
Member Author

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
Copy link
Member

cprezzi commented Jul 14, 2017

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
Copy link
Member

cprezzi commented Jul 14, 2017

Mach3 uses Tx M6 for Tool Change.

@arthurwolf
Copy link

arthurwolf commented Jul 14, 2017 via email

@tbfleming
Copy link
Member Author

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

@arthurwolf
Copy link

arthurwolf commented Jul 14, 2017 via email

@tbfleming
Copy link
Member Author

Yep.

@cprezzi
Copy link
Member

cprezzi commented Jul 14, 2017

Ok, that sounds doable too.

@cprezzi
Copy link
Member

cprezzi commented Jul 14, 2017

But what if the gcode is run from SD card?

@arthurwolf
Copy link

arthurwolf commented Jul 14, 2017 via email

@cprezzi
Copy link
Member

cprezzi commented Jul 14, 2017

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

@arthurwolf
Copy link

arthurwolf commented Jul 14, 2017 via email

@cprezzi
Copy link
Member

cprezzi commented Jul 18, 2017

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
Copy link
Member Author

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
Copy link

ghost commented Jul 18, 2017 via email

@cprezzi
Copy link
Member

cprezzi commented Jul 18, 2017

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
Copy link

ghost commented Jul 18, 2017 via email

@tbfleming
Copy link
Member Author

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
Copy link

ghost commented Jul 18, 2017 via email

@jorgerobles
Copy link
Collaborator

jorgerobles commented Jul 18, 2017 via email

@tbfleming
Copy link
Member Author

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
Copy link

ghost commented Jul 18, 2017

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

@tbfleming
Copy link
Member Author

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
Copy link

arthurwolf commented Jul 18, 2017 via email

@ghost
Copy link

ghost commented Jul 18, 2017

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
Copy link

arthurwolf commented Jul 18, 2017 via email

@ghost
Copy link

ghost commented Jul 18, 2017

grbl/grbl#1103 (comment) (Explains Grbl implementation of M6)

synthetos/TinyG#186 (comment) (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
Copy link
Member

cprezzi commented Jul 19, 2017

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
Copy link
Member

cprezzi commented Jul 19, 2017

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

@cprezzi
Copy link
Member

cprezzi commented Jul 31, 2017

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
Copy link

ghost commented Jul 31, 2017 via email

@tbfleming
Copy link
Member Author

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
Copy link
Member

cprezzi commented Jul 31, 2017

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
Copy link
Member

cprezzi commented Jul 31, 2017

@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
Copy link
Member Author

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
Copy link
Member

cprezzi commented Aug 2, 2017

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
Copy link
Member Author

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

@tbfleming
Copy link
Member Author

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
Copy link
Member Author

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
Copy link
Member Author

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
Copy link
Member Author

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
Copy link
Member

cprezzi commented Aug 3, 2017

@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
Copy link
Member

cprezzi commented Aug 3, 2017

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
Copy link
Member Author

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
Copy link
Member

cprezzi commented Aug 3, 2017

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). 💯

@tbfleming
Copy link
Member Author

I don't want to make a screen designer, unless there's already a React component which does that. I'll probably have a long list of checkbox options.

@jorgerobles
Copy link
Collaborator

I would love the feature of switchable, user configurable screens.

Yay! another thing of the recap #343 (comment)

@tbfleming
Copy link
Member Author

Side issue: build times have gotten annoying; we probably need to find out which packages we use are pulling in a large number of dependencies and replace them. There may also be packages we've used in the past, stopped using, but are still in the package list.

@tbfleming
Copy link
Member Author

I had an idea while drawing up some custom controls in Inkscape for it. Why not draw the whole UI in Inkscape? If this works then we'll have user-drawable screens!

image

@jorgerobles
Copy link
Collaborator

Pronterface!

@cprezzi
Copy link
Member

cprezzi commented Aug 3, 2017

Godd idea. If we could give each shape a name, we could use these names to map functions.

@jorgerobles
Copy link
Collaborator

jorgerobles commented Aug 4, 2017 via email

@tbfleming
Copy link
Member Author

I'm creating a new repo: lw.controller. It will function as both a stand-alone app and integrate into the main app. It will have an URL field which can load SVGs that people post online.

@tbfleming
Copy link
Member Author

How to configure what something does in Inkscape:

image

@tbfleming
Copy link
Member Author

load gcode

@ghost
Copy link

ghost commented Aug 11, 2017

Perhaps this needs it's own issue/development topic?

@tbfleming
Copy link
Member Author

Probably. One thing led to another...

@fpvmustang
Copy link

I would like G43.1 to work in X,Y offset to switch between plasma and router heads.

tbfleming commented on Jul 29, 2017

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
Owner
cprezzi commented on Jul 31, 2017 •

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants