I have a quick question about GRBL widget in chilipeppr.
When I click “Ctrl+X” button and then “Click to Unlock ($X)” the workspace lost his coordinates so I’m not enable to resend Gcode to extact previous stop position.
There is a way when you press the button to save the temporary coordinates so I don’t have to rewrite in the console “G92 X… Y…” to re-enter te current position?
Thanks!
You’d have to add some code to the widget that stores/tracks the last known location and then let the user pick from a pulldown perhaps to then send that as the new zero position. What if you could edit the code to watch the incoming coordinate change in the Axes widget, and just always store that in the menu. Then if you hit reset and realize you lost position, you aren’t stuck because you forgot to “grab” them earlier.
If the machine accidentally stops during X and/or Y axis movement the position is lost anyway, as this is almost not possible to stop the motor without loosing a step. Number of potentially lost steps is depending on the speed. Z axis is not so sensitive, as feedrate is usually slower and it is easy to probe Z zero again.
For X and Y the only way is to note the coordinates, run homing cycle after Ctrl+X, then move to lost position by G0 X…Y…Z… and continue. In case machine stops during Z axis movement only e.g. when drilling, you may skip homing and after Ctrl+X set the position with G28.3 X…Y…
Continuing gcode means that you need a gcode header to set inches or mm, G90 or G91, spindle speed etc.
What @jlauer proposed above could possibly be extended in a way that the button would not only recall the lost values, but set the machine back to it or run the full homing and re-establish all settings for the machine.
@sszafran I do think this is a major issue with cnc. On my last 5 hour milling job I had to feed hold like 20 times to fix stuff. I never lost position through the whole process.
Here my quickest solution…
You might consider upgrading to an alternate CNC controller that does not lose position on feed hold.
The position is not lost on the feed hold, but after the soft reset. On the feed hold I can’t do nothing, even the spindle is on so if I want to restart the process without losing the zero position this is the only way… ( I think …)
Correct, I think that is the only way, but on other controllers the resume doesn’t reset the controller, rather it keeps all position so you can beautifully resume
Provided the machine is not in motion when a soft reset is issued machine position is not lost in grbl.
So a feed hold followed by reset will not lose machine position.
Sorry John maybe I can’t explain myself. If I click resume after the feedhold, the process resume itself correctly. The problem is if I want to make some changes… like a broken bit or something else, I need to stop the work and the only way is to soft reset the machine… or I’m doing it wrong?
In config.h you have the option to enable a safety door function (from.0.9i+). Wire it to the feed hold pin.
When you trigger that it will feed hold and power down the spindle. The spindle will resume normally when you release the switch and resume the cycle.
I believe that you might be able to use the real-time command @ to do the same thing but have not fully parsed the grbl code base yet to know whether this works the way that I think it might.
Still not tested but the @ command does seem to be ‘live’ in the code. It is picked up as a real time command in serial.c and the motors are turned off in limits.c.
Position data is maintained as the mill is stopped via a controlled decelleration (in the code at least).
I have not checked the 1.1 branch. This is true of 0.9j (and probably i)
Seems that some new features like the solution to this problem has been implemented in the new release of GRBL https://github.com/gnea/grbl
@Luca_Nervetti have you tried the @ command? That is a real time command so should work identically to the feed hold and not lose position. Ideally it would also move the z axis to max z but that can be done with jogging (which should also work in feedhold when 1.1 compatibility is done (I think )).
I think the code for @ has been in the build since 0.9i.
I’ll try that later… but we definitely need a new widget for GRBL 1.1