New “Executed” status added to ChiliPeppr for TinyG. That means the Gcode widget will follow along exactly with which line just got executed. If you have a failed spot, now you’ll know exactly which line you were executing if you hit Feedhold !.
Sweet going to give this a go
Just so folks get what this means–prior to this the Gcode widget followed “Completed” which meant the Gcode widget showed you which line you were on based on when the line was read from the serial port buffer of TinyG. That was great, but since the planner buffer on TinyG is about 24 slots, you were always roughly 24 lines ahead in the Gcode widget of where your toolhead was at. With “Executed” you are at the line that is currently executing because TinyG sends back the line number right as it starts executing (not at the end of executing that line).
BTW, you need line numbers in your Gcode for this to work, so a new feature was added and is now on by default that auto-adds line numbers to your Gcode. If you turn that option off the “Executed” mode won’t show, rather it will fallback to “Completed” mode.
this is cool. I was trying to decode this today when I was running a file that had a tool change in the middle of it (I had to change bits). Normally I see the prompts about pausing to change tools, so this time I figured I would actually do that - but shortly after I hit play, I got the prompt up on the screen for a tool change pause, which was WAY further in the file. All I can guess is that the prompt was triggered when the tool change line was either Sent, Queued, or Written since almost all the Gcode gets sent to grbl with the preloading option set. I tried to just manually watch the code when it got to the tool change line and hit feed hold, but as the job went on, performance on the machine got so bad that I was hitting the button many times before it finally paused.
Anyhow, does the detection of the tool change command wait to see when the command is actually executed… and if so, does it send the feed-hold so that the machine pauses?
Tool change pauses act a bit different. They allow all the lines to buffer to SPJS up to the tool change line. Then when you unpause from a tool change it just starts buffering again. You must’ve changed to pre-upload mode or something such that it got to the toolchange line really fast and tossed up that dialog. I always just click off the dialog and leave the job in the pause mode waiting for the code to execute. I could, however, based on this new setting change the way it acts.
ahhh. So, I bet what I should have done was left it in pause mode. I don’t think I did that. Yes another case where I think I know better than the computer… and I don’t. Thanks!
What’s really interesting about your use case and what you did intuitively, is that you almost want ChiliPeppr to do an inline feedhold. That’s fascinating and probably a good idea. Right now when a feedhold ! gets to SPJS, it jumps the queue and goes right to the CNC controller. However, we could add an inline feedhold that actually executes with the lines of Gcode. Then ChiliPeppr could place a feedhold just before an M6 command. You could run your job as normal but get nice pauses. Right now, the pauses are happening at a layer much higher up the foodchain, i.e. right at the buffering layer of CP. It’s hard to say what is a better approach, but I kinda like the inline feedhold.
well, i do like knowing that no code beyond the pause is getting sent at all - that seems reassuring and I didn’t realize that is what it was doing. I think the only bad part was that the popup dialog showed up at an incorrect time. So, a compromise could be to do what you are doing now, but just not show the dialog until the line is hit. But of course, you’re never REALLY sure when the line is going to be executed with all the buffers involved. So maybe what you really want to do is issue a feedhold into the gcode itself so that it will happen and then, when you see that line approaching in execution, throw up the dialog. Dunno.