-
Notifications
You must be signed in to change notification settings - Fork 194
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
Comments
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. |
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. |
Mach3 uses Tx M6 for Tool Change. |
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 ***@***.***> 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
<#378 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAGpFZSMIjtXd3_3pbHoEt5a0tAzDl80ks5sN5tWgaJpZM4OYPAx>
.
--
Courage et bonne humeur.
|
If we do this client side, then neither Smoothie nor grbl will see the M0. |
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 ***@***.***> 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
<#378 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAGpFSszYYx5jQpaboPyYORWY0YQmYjsks5sN5yMgaJpZM4OYPAx>
.
--
Courage et bonne humeur.
|
Yep. |
Ok, that sounds doable too. |
But what if the gcode is run from SD card? |
then you can't really do anything about it currently
…On Fri, Jul 14, 2017 at 7:17 PM, Claudio Prezzi ***@***.***> 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
<#378 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAGpFRHZW8tk419j3fjPHLSpaTebiw_Pks5sN6KvgaJpZM4OYPAx>
.
--
Courage et bonne humeur.
|
Is M600 in a gcode file running from the SD card not suspending the job and can be resumed? |
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 ***@***.***> 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
<#378 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAGpFd_NSK2EaYuT8_o4EdRHNlPDLvsmks5sN7iTgaJpZM4OYPAx>
.
--
Courage et bonne humeur.
|
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? |
Short term plan for lathe:
Long term plan for lathe:
Mill is probably similar, but user could also use probing to set tool offset. |
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" ***@***.***> 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
<#378 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AHVr23gYaC_Il-wuSWgp4c1VajxWL5Usks5sPN4IgaJpZM4OYPAx>
.
|
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. |
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" ***@***.***> 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
<#378 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AHVr24Lo5opf7g9QoXGXJl3c7e1jZGvOks5sPP9cgaJpZM4OYPAx>
.
|
Yep. I need to add a tool table for lathe. |
Yay!
…On Jul 18, 2017 9:42 PM, "Todd Fleming" ***@***.***> 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
<#378 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AHVr294fwTKC53ne13MZUr1NtO38sWUfks5sPQq_gaJpZM4OYPAx>
.
|
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" <[email protected]>
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 ***@***.***>
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
> <#378 (comment)
>,
> 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
<#378 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABoIYICjEfV35WK93f1LSQ9xMB1xWDFfks5sN8AJgaJpZM4OYPAx>
.
|
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). |
Shouldnt we catch M6 then too? Since many other CAMs use M6 Tx as the command? Just in case |
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. |
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 < ***@***.***> 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
<#378 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAGpFb9QUSh61nqwIDQFXIyKfSx405Tvks5sPQzIgaJpZM4OYPAx>
.
--
Courage et bonne humeur.
|
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) |
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 < ***@***.***> 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
<#378 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAGpFYx6gpMqZ1KQAP3xyz-kV-Gp0nbmks5sPQ3TgaJpZM4OYPAx>
.
--
Courage et bonne humeur.
|
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:
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? |
Jep, we should support |
@arthurwolf Yes, it probably makes sense to make the behaviour for M0/M6 configurable or dependant to the used firmware. |
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. |
@cprezzi : machine type: i still really want my autodetect, exactly for use
cases like this... LaserWeb/lw.comm-server#31
…On Jul 31, 2017 10:46 AM, "Claudio Prezzi" ***@***.***> 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
<#378 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AHVr22lA6dVCNSl5glJlnXCp6MZH-4Yxks5sTZRngaJpZM4OYPAx>
.
|
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". |
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. |
@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! |
I'm afraid this will happen:
I also don't look forward to this:
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. |
That's not the case. Once you have configured your machine profiles, the procedure would be:
(because the machine profile knows the interface, port, settings...) |
I don't like step 2. Right now I safely ignore the profiles and keep all options enabled. |
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. |
Stuff I'm running into that I hope to find fixes for without hurting new users:
|
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. |
That may be the answer:
|
@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! |
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? |
I think we're starting to reach agreement:
|
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). 💯 |
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. |
Yay! another thing of the recap #343 (comment) |
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. |
Pronterface! |
Godd idea. If we could give each shape a name, we could use these names to map functions. |
Name the shape as the name of the function, pipe thru all clicks and voilà
:)
El 4 ago. 2017 1:03, "Claudio Prezzi" <[email protected]> escribió:
… Godd idea. If we could give each shape a name, we could use these names to
map functions.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#378 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABoIYLjQJ7IAtxdvWNdEprVpk2AK8RNHks5sUlGvgaJpZM4OYPAx>
.
|
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. |
Perhaps this needs it's own issue/development topic? |
Probably. One thing led to another... |
I would like G43.1 to work in X,Y offset to switch between plasma and router heads.
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. 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. |
It'd be nice to support this to allow tool changes:
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.
The text was updated successfully, but these errors were encountered: