Based on comments from here, I got to thinking that a periodic readout would be handy. And @jeffeb3 mentioned Marling has periodic reporting, which is true, but it is a relatively new feature and not in Ryan’s firmware (not even an option). Maybe one day it would be an option but right now it’s not feasible.
I was trying to better understand how the Python backend and Knockout frontend work together, and what started as a test application accidentally morphed into a periodic M114 polling plugin. The position is shown in the nav bar at the top:
There was some drama/problems over M114 a while ago. As far as I understand it, frequently asking for position via M114 was causing hiccups or pauses in playing gcode. There were two solutions:
The periodic reporting was added. If we need to add this to the MarlinBuilder releases, we should. Ramps is always the hang up, but we have a back log of stuff that ramps sucks at, so we may need to force it to have a mechanism to separate these advanced options.
M114 was reporting actual position, using the current step values and inverse kinematics. That was taking too long and sometimes causing other important stuff to pause. The workaround was to change the default M114 behaviour to report the next position in the planner (which is faster, but may not be as accurate).
Just some back story there. The periodic reporting is probably going to be more reliable long term. But the M114 query will probably work most of the time. If there was a lot of people having issues, you could add a toggle and turn it off during cuts or something.
I only really care about coordinates when setting up a job not so much when it’s running. The polling interval could be turned way down and I don’t think it would hurt too much. There may be other use cases that need real-time info but I havnt really run across many beyond curiousity over what depth it’s currently at.
Right now it won’t let you put an interval shorter than 1 second (or it will allow you, but it will act as if you entered 1 second). I’m not sure why it would stutter unless it’s a lot more resource intensive than I can imagine, or if it also implicitly flushes the queue or something.
I was thinking of using a gcode hook to update an internal model of where the machine has been asked to go, but this has a major hole where OctoPrint is unaware of joystick movements, and would have incorrect beliefs about where the machine is. If setup is the most important time to track the position, this makes it mostly useless.
It is also possible to click on the navbar where the position is reported, and it will perform M114 “manually” and update. This allows disabling the polling and clicking whenever you want an update.
Having an option to toggle during a job is also a good idea. I am a little nervous about what would happen on a long-running command like a long G4 or a blocking temperature command. It could queue up a very large number of M114 commands on the OctoPrint side that then burst through when the machine starts accepting new commands. But when paused, the location readout would probably be useful again, so it should be enabled.
Maybe the rule is, when idle and paused, it polls, and when printing, it uses an internal model from snooping on the stream of gcode that’s been sent.
