Is this a bug or intended ?
-
I was printing a temp tower for some new filament,
and went to switch to a different tab in my web browser and accidentally managed to click the home all button in dwc while half way through the print ( using a touchpad on my laptop)the printer did exactly that,
it homed all axis and then tried to continue the print, failing miserably lolfirmware b7+2
-
@mikedc
RRF is designed to accept g code from multiple channels concurrently (or near to it)
That's its strength as it allows live adjustments.
The flip side is you have to be careful not to send something dangerous.
Hitting "home all" sends G28, which in turn typically runs your "home all.g" macro. This typically has a bunch of G1 movements not unlike a print.
You need sufficient logic in that file to not run the moves if a print is in progress if you want to avoid accidental triggering.
Perhaps setting a global variable to true AFTER you call G28 in your print and setting it to false again in your end gcode. -
Thankyou for the explanation, it was purely by accident i clicked it and didnt expect it to actually carry it out.
I will try your suggestion setting a global var to prevent it in future
-
@mikedc If you put:
if !move.axes[0].homed || !move.axes[1].homed || !move.axes[2].homed
at the start of homeall.g and indent the rest of the code one space, it'll stop that. -
@stephen6309
Thankyou, ill try that -
@mikedc While the suggestion by @Stephen6309 will work to prevent homing if one or more axes are currently homed, there are a couple of caveats. Firstly, if one axis had been homed but you wanted to home the other axes, then the boolean "or" will prevent you from doing that using homeall.g. Secondly, if you had made some adjustments to the physical position of an end stop or some such, you might at some time want to home the printer even though it has already been homed.
As an alternative suggestion, you could instead use something like this at the beginning of your homeall.g...
if state.status != "processing"That means if the status does not equal "processing" i.e. a print is not running, then......(carry on with the homing macro).
I'm by no means an expert on conditional gcode so someone more knowledgeable than I might say it won't work - but I use that in one of my trigger macros so I think it will work.
-
This is actually a quite dangerous behaviour. I'm running 2 CNC machines, and on two occasions I've accidentally homed one machine while the other was running. The last time it could have ended quite bad due to the material setup. Now I'm using two different laptops to avoid any incidents. Maybe a checkbox in DWC or a M code to allow or disable manual gcode (or any other source) while the machine is procession a gcode file. With the exception of M112 etc.
-
@rzi The solution deckingman posted above is a good option for when a job is in progress.
-
@phaedrux You can still press a jog button.
-
I like this more and will try it thankyou
-
@rzi said in Is this a bug or intended ?:
@phaedrux You can still press a jog button.
Yes this is true. And I agree that maybe having the option to lock out most DWC controls during a job would be a good idea.
If you have a good idea how something like that could be implemented perhaps you'd like to create a thread for the idea in the DWC wishlist where it can get some feed back.
-
@mikedc said in Is this a bug or intended ?:
I like this more and will try it thankyou
I can't claim much credit as someone else on these forums told me how to do it. I think it was @T3P3Tony . In my case, I had installed a joystick and used triggers to jog the gantries around depending on the state of the 4 switches in the joystick. At the time, triggers could be "fired" even if a print was running and it is very easy to accidentally nudge that joystick. So I needed a mechanism to disable the joystick when a print was running.
-
well its a nice solution, ill be using it in other places too
