ioSender
ioSender copied to clipboard
terjeio
(Re-)Start or Resume GCode from a certain point in the Code
Hi,
I realy love grblHAL and this sender. One thing I am regularly missing is the possibility to start, restart or resume a milling job from a certain point in the code. This would be very helpful after certain errors, crashes, broken cutters, or just to continue a job the next day... For now I help myself by deleting parts of the gcode file in a text editor, but this is quite laborious. So maybe this could be a feature for a future release of IoSender?
Kind regards Paul
Probably should be a discussion topic. It has been brought up before. The problem is you need to keep the "preamble" that sets up the job (turn on the spindle, set workspace, etc) and there is no standard for that. It's pretty easy for a person to see in the GCode, not so easy to automatically determine. You can edit the loaded GCode file from ioSender. Though, that also updates the original file. Save-as doesn't change the loaded GCode so you you would edit, save-as something else and then load that. Maybe have an edit-and-load without changing the original GCode?
For a lot of people (like me), leaving out the "preamble" might not be an issue. For me, i have to start/set the spindle manually, as well as workspaces. So for me, a behaviour like "start from line" (as UGS does it) would be completely sufficent. But I also found, that the way, bCNC does it, is very interesting. There, you can activate/deactivate single lines in your code, so you could leave the preamble as it is, then deacivate some lines and finaly let it do the rest of the job.
bCNC also has buttons for things like "activate/deactivate all", "invert selection" and some more options. Very helpful, but of course a lot of work to integrate this into IOSender code and user interface...
One possible solution would be to run the gcode until the desired line in a non-move mode, extract the machine state (MPos, coordinate system, g90/91, spindle rpm and such) from the simulated "history". After that, make a safe move to the required position (z up, x y subsequently), turn on the spindle and approach in negative z.
This might be problematic with cutters that cannot plunge, but I guess one would probably resume cutting in an already cut toolpath just right before the previous run stopped.
I used LinuxCNC in the past and always wanted this feature, because I too had to manually delete parts of code when something went wrong. That's ok for simple parts. When it happens while carving a 3D guitar top in expensive wood with a rather complex toolpath that follows the outline, it get's scary :D let's say, there is a reason I mentioned g90 and 91 in the beginning..
One possible solution would be to run the gcode until the desired line in a non-move mode, extract the machine state (MPos, coordinate system, g90/91, spindle rpm and such) from the simulated "history".
Sounds like a good idea to me, but ...
After that, make a safe move to the required position (z up, x y subsequently), turn on the spindle and approach in negative z.
this will probably work for the most machines, but on the other hand we never really know, what X,Y,Z is on a certain machine and if Z-up -> go-to-X&Y -> Z-down is the right order to do it. Especially, if we are talking about machines with more than 3 Axis.
For me, this would rather vote for a solution where you can individually activate/deactivate single lines and blocks of code. Of course this is a might tool, and everyone using it should be aware and understanding what he/she is doing. As with every good tool..
(sorry for closing/reopening. was a misclick)
Yes, that is of course true. However, I guess most people use a 3 axis machine were at least the z axis orientation is pretty standard. In any case, it is advisable to jog close to the restart location. But keep in mind, that gcode commands only tell the parser where to go next, not where to start. If you restart e.g. at the wrong layer in a typical 2.5D job, there are certainly many things that can go wrong even when doing it manually.
Obviously, restarting automatically is not for everyone and should be done with great caution. But that is also true for manual restarts. Having the parser state correctly set is a great benefit in my opinion and helps for both approaches. The only difference would be if you approach the starting location manually or automatically. This could be selected by the user? I see two possible attempts for implementation: 1) send the gcode to the controller in check mode until the restart line, disable check mode and continue cutting. 2) strip all move commands at runtime from the gcode until the restart line and send all parser related commands, then continue with the code.
Option 2 has the benefit of being independent from the controller firmware because it's all done in the sender.
I guess most people use a 3 axis machine were at least the z axis orientation is pretty standard.
I am one of these 4-axis guys ;)
In any case, it is advisable to jog close to the restart location.
True. I usually try to find a startig point where Z is above my stock. And when I am working with the 4th axis, I also have to be aware of the right rotation to start with.
Option 2 has the benefit of being independent from the controller firmware because it's all done in the sender.
I definitly see this as a task for the sender not the controller.
Anyway... I think the discussion shows, that there is a need for such a feature and it would be a real benefit. Unfortunately my C# skills are far from being able to try implementing it myself. So I think we kindly have to ask Terjeio (or someone else in the community?): Could you consider this for a future release?
I definitely see this as a task for the sender not the controller.
Totally agree.
For a first step, I like the idea of being able to select a range of GCode and have it be skipped over. Pretty much what I do manually if a job has crashed and I want to save it. That will require the user to have a decent level of understanding of GCode as well as the CAM SW. Definitely not a beginner feature.
Anything more clever may be really hard to get right. Maybe break a job up into a set of sequences that are separated by rapids? That is clearly imperfect but may help manual selection of the preamble and new start point.
Here is a list of modal states that has to be restored?
The sender has an embedded emulator that could be used to determine the current state at any given block/line. This could make a restart feature easier to add...
To start playing with this function it will be enough to specify start and stop point before program run. Also it's need precise logging of execution progress - now, if execution stopped you only see current program string in status bar and this information completely disappeared if you click any button.
