Hey guys! I’ve been looking into some annoyances with the M105 reporting during homing, and have hit a bit of a wall. From octoprint, klipper appears to stop responding to M105 during homing sequences. I’ve tried digging through klippy.log to find the order the gcode buffer is processed, but it doesn’t appear to be there. I’m happy to keep digging into this myself, but I need some pointers as far as additional log file locations and what flags I may need to set to make diagnosing this a little easier.
If anybody has seen this, or knows of a direction to go in, help is appreciated!
It’s not a functionality problem, more nice from a user experience & datalogging perspective to not have the gaps in temperatures during the homing sequence. From a code perspective, I don’t see any reason why the gcode processing logic shouldn’t be able to go ahead and respond to that, as it should already be checking for M112 during the homing sequences , and respond to that as well.
As I mentioned, I’m more than happy to try and dig into this myself. I’ve dug through the gcode processing code a bit, but I’m not terribly familiar with the built-in logging around the gcode buffer from the host.
Just from the datalogging side, I did try and replicate the M155 functionality of Marlin. It also stops responding during the homing sequence, so from what I could tell it appears to be a bug in the response generation or sending code.
Again, I’m more looking for a direction to go in as far as what methods may be involved in this part of the code so I can dig into it myself. If I fix it, great, I can submit a pull request. If not, also great, it’s just part of it.
This is a fundamental limitation of G-Code. It is a command and response system that is inadequate when one wishes to get timely data updates during long running commands.
Is the gcode implementation also the limitation on the delayed gcode macro not getting through? I did a bit of digging into it, and got a bit lost when I got into the reactor code… I’ve seen a few implementations using the API I’ll start looking into. I think at this point it’s more of an exercise is learning how Klipper works internally.
Yes. All “g-code” commands in Klipper run sequentially - no two commands run in parallel. So, if there is a long running command then it naturally delays all other commands.
In the implementation this is done by taking the gcode.mutex lock.