Open krkeegan opened 6 years ago
What will this do to the real-time view in GC?
I believe that GC is interpreting the g-code and displaying what should be happening, as opposed to reporting the current position of the bit as reported by the maslow
What will this do to the real-time view in GC?
Well GC could ask for updates as frequently as it likes so it could send the ? command at the same 5hz frequency that we currently use and you wouldn't notice a difference from the user end in GC. GC could even throttle down or up the frequency at times, for example when nothing is moving only request once per second. The only benefit I can see if fewer log messages.
I believe that GC is interpreting the g-code and displaying what should be happening, as opposed to reporting the current position of the bit as reported by the maslow
Both the white and the red reticle are calculated by the data from the firmware. The expected location (red I think) is a direct report from the firmware. The actual position (white I think) is extrapolated from the reported position error.
If I understand this correctly, there is also a consensus about using the M114
command to get the XYZ position. The Smoothieware folks have even extended their supported GCodes to include the M114
command to give different types of information (current position, machine position, actuator position, etc.) by adding a "dot number" suffix.
For example:
gcode | description | command |
---|---|---|
M114 | Show current position of all axes, XYZ will be the last requested position | M114 |
M114.1 | Show current real time position of all axes | M114.1 |
M114.2 | Show current real time machine position of all axes | M114.2 |
M114.3 | Show current real time actuator position of all actuators | M114.3 |
M114.4 | Show last milestone | M114.4 |
Maybe it's more appropriate to implement this GCode?
I think switching to a ?
based system is a great idea.
@blurfl is right that it would impact the real time view in Ground Control, but we could fix that by sending the ? command frequently. Having the call and response be triggered from the Ground Control end gives us the opportunity to turn off position updates if we don't want them.
One thing to keep in mind is that GC thinks the connection is dropped if it doesn't hear anything for 3 seconds which might need to be rethought.
As we continue to add support for gcode senders and generally interfacing with the firmware without a GUI frontend, it is becoming apparent that the position reports 5x per second are really annoying. It buries a log of the responses from the firmware, and clogs up our logs.
Grbl uses the ? command to request a status update. Basically it forces the interface to request an update rather than pushing one constantly. This should be relatively easy to implement, but will require an update to GC as well.