chilipeppr
Unclear when jogging happens in mm or inch
The jogging controls in the top right of the grbl workspace seem to follow the gcode files for wether to use metric or imperial units. It defaults to mm, but it seems that when you load a gcode file containing a G20 commands the display switches to inch (though I've seen one occasion where the display said "inch", but the values shown were really mm). However, even though the display says "inch", the controls are still in mm. Now, once you start executing a gcode file, that contains a G20, and halfway pause (or during a M6 toolchange command), then the jogging will be in inches, which quite surprised me.
Perhaps it would be good to have an explicit selection of units ("inch", "mm" or "auto"). Furthermore, it would be good if the controls always explicitely specify G20 or G21 if the current unit selection does not match the current grbl units (though I'm not sure if it's easy for chilipeppr to know what grbl is thinking?).
Hi Matthijs, I would email Jarret Luft directly. His email is in the Grbl workspace. The Grbl workspace works very differently than the TinyG workspace on units. TinyG reports units on-the-fly back to ChiliPeppr because TinyG is a 32-bit platform with more firepower, so the workspace has a really good reflection of the current units. Grbl does not report units back to the workspace automatically because that's too heavy for a lightweight processor like the Arduino. So you have to query Grbl for the currently active units and I'm not sure Jarret is doing that.
Ah, thanks for clarifying. Let's try highlighting @jarretluft instead of mailing him, should also get his attention :-)
The first issue I'm running into is that changing axes widget units to something different than the 3d viewer causes incorrect visualization of the tool head position in 3d viewer. IE: You load a file in inch but your controller is in mm, everything (3d viewer and axes widget) currently gets set to inch so they are in sync. The units are still being converted, so if you are in MM and move 10mm, the CNC will move 10mm, but show up as 0.393 inches, and move the tool head in the visualizer the appropriate 0.393 inches relative to the gcode file rendering you have imported.
The second issue, as John said, is that grbl does not send a response with what units mode it is in each time a command is executed, and by default all coordinates are passed back in mm, even if you are in inches mode, so at any given time there are multiple units conversions/settings that need to be considered, and different commands that would need to be sent continually to the controller just to see if the status of the units has changed (like $G). To make this even more complicated, lets say I did implement a loop that sent the $G command every 5 seconds to get the current units setting back from grbl. If I start in mm mode, and then buffer an entire file in inch mode into SPJS with (as an example) 5,000 gcode lines, what happens is all 5,000 lines now take priority to my $G commands in the queue, so every 5 seconds during the job a $G command gets queued to the end of the job, but doesn't actually run in real-time, so for the entire job the axes widget will still show mm and wreck the 3d viewer rendering until the end of the job after all 5,000 lines have completed, then those 5 second queued up $G commands will get run one after another. (which, if your job takes 45 minutes, is 540 queued up $G commands that would still end up needing to run)
I'm open to suggestions though (John, if you have an ideas feel free to jump in here), I just don't want to implement a change that breaks some other aspect of chilipeppr when this issue could be considered more of a minor inconvenience than a bug. I'm presuming that most people spend 90% of time working in a single unit, and would have their grbl configured to start in that units mode (via startup blocks) to eliminate the constant need to jump back and forth, but maybe i'm wrong in that assumption and this is an issue for more than a fringe group.
(though I've seen one occasion where the display said "inch", but the values shown were really mm)
If you can provide me details on how to reproduce this, I would like to take a closer look. This does sound like a genuine bug but not something I have ever seen.
So, looking at this again, I think there's two different modes:
- Chilipeppr can be in inch or mm mode, which affects the display of units. This mode is triggered by G20/G21 in the loaded gcode file.
- Grbl can be in inch or mm mode, which affects the interpretation of gcode commands (jogging in particular). AFAIU, it does not affect the status reports and/or display of things, which seems good to me. This mode is triggered by executing G20/G21 commands on grbl.
When these two modes do not match, then the display of the current position and the effect the jogging controls will mismatch. If you intend to jog 1mm and end up 1", this will break things. This is most pressing issue I think needs to be fixed - jogging needs to be predictable.
Looking at the above, the current grbl mode is really only relevant when sending manual commands, e.g. jogging. This means it could be sufficient to, before sending a jogging command, first query grbl for the current unit, and then either change the unit to what's needed for jogging and then change it back or, simpler, just convert the jogging command to whatever mode grbl is in. A simple caching could improve performance - query the current mode, except when only commands were sent that are known not to affect the mode since the last query. I'd implement this by resetting the mode cache whenever a command is sent other than through the jogging controls (and perhaps coordinate offset controls), though actually looking at the gcode commands sent might also work.
If gcode processing is halted and/or the queue is full, this means that the $G command won't be processed right away. Since the jogging command isn't either, that shouldn't be a problem (though it might be a bit tricky to decide what to do in this case - queue the $G command and only add the actual move command when it's done? What if you press the jog controls twice? Perhaps just refusing to jog when the queue is not empty and the unit is unknown might be better?)
I think the above would fix the unexpected behaviour I described, without triggering the queue full of $G commands problem you described, or breaking other behaviour? The only surprise left is when the modes mismatch and the user types gcodes manually, but then you should doublecheck what you're doing anyway.
As a second feature, it would be good if the chilipeppr mode (e.g. display and jogging controls) could be fixed to mm or inch, instead of automatically switching based on the file loaded. In my workflow, I use pcb2gcode which can only generate files using inches. However, being a mainland European, I can't properly think in inches, so I want my interface and jogging to stay in mm always.
(though I've seen one occasion where the display said "inch", but the values shown were really mm)If you can provide me details on how to reproduce this, I would like to take a closer look. This does sound like a genuine bug but not something I have ever seen.
This just happened once, not sure what triggered it. I'll keep an eye out and let you know if I can make it reproducible.