So this is not really an issue, its more a clarification of what should happen with delayed gcode macros and starting new prints. From my very basic testing it seems like a delayed gcode macro will prevent a new print starting, but even if a delayed gcode macro is not currently executing, when it does get scheduled it actually will cause the print to stop executing (it won’t pause it in the normal sense of PAUSE), and once the delayed gcode finishes the print will continue like nothing happened.
The reason for the loop of 10000 loops is because I did not want to add G4 commands which I thought might distort my tests and I wanted a long running gcode.
if I execute START_WAIT and then immediately start a print, after 10 seconds the delayed gcode will start executing and cause the print to pause.
So really what I want to know is is this expected?
Before someone says thats a stupid macro, yes I know, I was exaggerating the situation to clearly understand the relationship between printing and delayed gcode macros.
You invoke START_WAIT. From the moment UPDATE_DELAYED_GCODE ID=wait_a_bit DURATION=10 is executed, “wait_a_bit” will be executed in 10 seconds, regardless if you start a print or not. That’s how it works.
I mean that is what is happening but I just wanted to make sure that was expected to happen, I actually asked in another forum and their answer was that the queued gcode is cancelled, I also asked ChatGPT, which stated quite emphatically:
This will not run if a print is started before the 10-second timer completes. Klipper cancels or suspends delayed_gcode execution when printing begins.
Yes I know stupid to rely on chat gpt, but I wonder at some point if klipper was doing this.
I didn’t see in the above linked documentation anything about cancelling delayed gcode automatically. My experience neither showed me that. Oversimplifying, actually Klipper doesn’t know it’s printing, Klipper simply executes GCode commands, whether they come from.
ya makes sense, but i think its a common misconception that delayed gcode is canceled or paused when a print starts or that gcode execution is single threaded. I know that chat gpt pulls stuff out of its butt all the time, but do wonder that maybe in an earlier version of klipper gcode was single threaded. Or perhaps all Chad was telling me is that a delayed gcode command will not execute while START_PRINT is running, because I am fairly sure START_PRINT as a macro will block all other macros from running, I assume the reason why the delayed gcode was executing in my test print is because it was getting executed in between normal gcode commands, after START_PRINT finished.
So I asked Chad again to clarify and the response was different, proves my Chad Fu is newb level
Responses from ChatGPT are not a useful tool for understanding how any piece of software works, and asking it to lie to you some more is not adding anything to the conversation except for even more incorrect information. Read the documentation, read the code, or ask actual people who understand what they’re talking about. Klipper does not “[block] their scheduling from gcode macros once printing begins.”
ChatGPT I think can be a useful contrasting viewpoint and it is also a common resource for newer klipper users too. It seems to be common misconception about delayed gcode that it is cancelled when a print starts. The reason why I asked on this discourse was to ask actual people, but I involved ChatGPT because my experience with it (I am a java dev for 27 years), is that its information is often accurate but out of date, it can also just flat out make shit up!
