This is really good to know. Thanks @PhilJohnson!
1 Like
in the latest 2.0 nightly build (possibly older versions too) of the classic GUI, if you click on settings at the top right and click firmware settings, you can change any of the grbl settings on the list and update them all at once when you save
i just found this the other day, had been entering them all individually when i needed changes
not sure if this is helpful for what you are doing here but will save you from using a macro slot
Just for reference, there is a potential issue with sending your settings at once with GRBL. When GRBL writes to the EEPROM (which each $x setting does), it shuts off the RX serial port communicating with the host while it’s writing to the EEPROM.
When Grbl stores data to EEPROM, the AVR requires all interrupts to be disabled during this write process, including the serial RX ISR. This means that if a g-code or Grbl $ command writes to EEPROM, the data sent during the write may be lost. This is usually rare and typically occurs when streaming a G10 command inappropriately inside a program. For robustness, GUIs should track and detect these EEPROM write commands and handle them appropriately by waiting for the queue to finish executing before sending more data. Note that the simple send-response protocol doesn’t not suffer from this issue.
What this means is that when you send all of your settings, there is a potential that some may get truncated and the wrong value set. As mentioned, it may be rare, but there is an open issue with UGS where a simple probe Gcode file causes this to show up.
Just a warning that you want to verify the “$$” after sending them all at once.
He might be handling macros differently than streaming files as well. As stated in the GRBL wiki, the simple send-response doesn’t suffer from this (since you wait for the write to complete then send the next command).
This is a G-code sender issue. I have found that UGCS 1.0.9 does not wait for the Ok before sending the next command when sending a file.
Don’t know about the nightly build.
ok i dont know what the advanced probe settings you mention are so this way may be best for what you are doing
interestingly, i use the macro slots to do my probing for finding XYZ zero
Not yet. He’s now aware of it and had an exchange with Sonny and plans to fix it. He specifically mentions streaming settings.
My understanding is line based. The different senders have to process the different commands based on what they are.
It depends.
On regular G-code lines (and $ commands) it’s line by line.
For the immediate commands (like status, feed hold, cycle start, abort) it’s by character.
This is done in the GRBL menu and there is no issue sending all the grbl settings at one time with PicSender.
2 Likes
That’s by design. The two protocols are “Simple Send-Response” and “Character Counting”.
The Character Counting protocol on the other hand requires additional book keeping by the gcode sender, but allows GRBL to run at full efficiency. This is the default mode UGS has used since one of the earliest versions. There are some special cases @JustinBusby mentioned, when GRBL needs to modify the EEPROM the serial hardware is temporarily disabled which can cause weird issues. In practice this hasn’t come up very often so I hadn’t investigated a solution. It sounds like @PhilJohnson’s macro is pretty reliable as long as you click the button a few times.
With Simple Send-Response the sender waits for GRBL to respond to every command before sending another. Because the sender waits between each command this protocol is not effected by the above EEPROM issue. This protocol is easy to implement but is much slower because of the latency between GRBL sending the ‘ok’, the sender receiving it and sending the next command, and the next command being received and parsed by GRBL. Limiting GRBL to a single command at a time also prevents GRBL from running at full efficiency. Enable “Single Step Mode” in UGS to use this protocol.
Soon the UGS nightly build will automatically switch to the Simple Send-Response protocol when commands which modify the EEPROM are detected. So it will have the best of both worlds. I’m still running some tests, but the change was small so I’ve shared it over here.
2 Likes
I think it’s a race condition, so it might only work some of the time. Basically when GRBL receives the first $ setting it needs to parse the command before storing it. If the remaining settings are received before GRBL is able to store the first, it should behave the way you’re thinking. But if only half of them are sent, the other half would be skipped.