commands get messed at the end of print job

[dmmedia]

At the end of printjob, extruder tries to push about 5cm of filament at max speed with heater switched off and parking X axis. This looks like line N11369 is getting executed after line N11370 from my g-code snippet below. This behaviour started after pulling all the last week code up to commit https://github.com/MarlinFirmware/Marlin/commit/196db5720e43dd03ba64e6967f8b949b852c25b9 and from about https://github.com/MarlinFirmware/Marlin/commit/34e51f576f5c4edfb6c0e56a73a9b739b40ad351

Code snippet from end of my print job

N11367 G1 X158.434 Y215.456 E46.99333 127 N11368 G1 X158.544 Y215.566 E46.99552 117 N11369 G1 E45.99552 F2400 28 N11370 G92 E0 99 N11371 M104 S0 64 N11372 G28 X0 125 N11373 M84 *56

Printer is RigidBot with RigidBoard controller and only difference in code from this repo is button support for LCD controller, which did not triggered such a behaviour before.

[alexborro]

I have heard something similar from a friend of mine. I think we should take care of it.

Cheers.

Alex. Em 14/03/2015 08:37, "Denis" notifications@github.com escreveu:

At the end of printjob, extruder tries to push about 5cm of filament at max speed with heater switched off and parking X axis. This looks like line N11369 is getting executed after line N11370 from my g-code snippet below. This behaviour started after pulling all the last week code up to commit 196db57 https://github.com/MarlinFirmware/Marlin/commit/196db5720e43dd03ba64e6967f8b949b852c25b9 and from about 34e51f5 https://github.com/MarlinFirmware/Marlin/commit/34e51f576f5c4edfb6c0e56a73a9b739b40ad351

Code snippet from end of my print job

N11367 G1 X158.434 Y215.456 E46.99333 127 N11368 G1 X158.544 Y215.566 E46.99552 117 N11369 G1 E45.99552 F2400 28 N11370 G92 E0 99 N11371 M104 S0 64 N11372 G28 X0 125 N11373 M84 *56

Printer is RigidBot with RigidBoard controller and only difference in code from this repo is button support for LCD controller, which did not triggered such a behaviour before.

— Reply to this email directly or view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/1605.

[scotty1024]

Not likely involved in your described behavior but it’s best practice to insert an M400 in your post g-code like this…

M400 G92 E0 M104 S0 G28 X0 M84

On Mar 14, 2015, at 4:37 AM, Denis notifications@github.com wrote:

N11367 G1 X158.434 Y215.456 E46.99333 127 N11368 G1 X158.544 Y215.566 E46.99552 117 N11369 G1 E45.99552 F2400 28 N11370 G92 E0 99 N11371 M104 S0 64 N11372 G28 X0 125 N11373 M84 *56

[dmmedia]

Thanks for the hint, I'll put M400 code into slic3r and give it a try.

[ErikZalm]

We should find the cause of this bug. If we are to busy with the stepper interrupt this can happen. That is why I added the serial check in the past. If the stepper interrupt can be to long we should change it. (There are some optimisations possible)

[dmmedia]

@scotty1024 Unfortunately G92 E0 is generated automatically by Slic3r, so I can put it only before M104 S0 in the custom end g-code, so the problem still exists.

[thinkyhead]

@dmmedia Is this issue reproducible every time? I would love to narrow this down to a specific segment of the code. I forget whether Marlin has a "simulation mode" where it doesn't actually move the printer but just runs the G-Code through, but maybe I can put that together…. In any case, post your full G-Code someplace – as a gist or snippet – and we can use it to test to see what causes this.

[scotty1024]

@thinkyhead I was thinking a cool project would be a QEMU style AVR emulator complete with emulated stepper chips/motors that would flag timing errors etc

On Mar 15, 2015, at 4:00 PM, Scott Lahteine notifications@github.com wrote:

@dmmedia Is this issue reproducible every time? I would love to narrow this down to a specific segment of the code. I forget whether Marlin has a "simulation mode" where it doesn't actually move the printer but just runs the G-Code through, but maybe I can put that together…. In any case, post your full G-Code someplace – as a gist or snippet – and we can use it to test to see what causes this.

— Reply to this email directly or view it on GitHub.

[thinkyhead]

@scotty1024 I see an interesting variety of Arduino emulators / simulators starting to pop up, such as those listed in this article. The thing is, at such a low level it becomes hard to simulate the RAMPS or other hardware attached. I could see making a debug mode for Marlin where no signals are sent or received (be redefining READ and WRITE macros, etc.). But either way it's a pretty big job.

[dmmedia]

@thinkyhead Yes, issue is reproducible every time. I was printing couple of dozen of 1-inch calibration cubes yesterday and every time, when at the end of g-code was large enough number to notice the movement for extruder, I did noticed that.

Issue only occur at the end of the print, when G92 command issued after last retraction G1 Exx.xxx. There are many places in g-code where G92 is used for extruder, e.g. at every hop from perimeters to infill or at every layer change. But only last one triggers the issue.

Can it be related to look-ahead functionality in planner?

EDIT: posted code sample here: http://pastebin.com/nKcSSXkb

[ErikZalm]

@dmmedia Can you find the commit where it starts to fail? Then it should be easy to find the cause.

[dmmedia]

@ErikZalm I will try in the coming days. I have my printer at home and work at the office. So it will be not very fast.

[woodsmoke]

Something similar happening during my End G-codes. I have auto bed clear. Printer waits ten minutes for bed to cool down (M190 S[roomtemperature] is no good of course, because bed temp is higher than target bed temp.) Then the bed rises, then the Y gantry clears. But line 8 is skipped and the bed does not drop before the gantry returns.

1:G92 E0 2:M104 S0 3:M140 S0 4:G1 X0 Y10 F6000 5:G4 P600000 6:G1 Z-30 F200 7:G1 Y154 F1000 8:G1 Z4 F200 9:G28 Y 10:G90 11:M84 12:M107 13:M107 14:M107

[nophead]

M190 R[roomtemperature] will wait for it to cool.

Try M400 after line 9.

[woodsmoke]

Thanks nophead.

[nophead]

Did the M400 solve your problem?

[woodsmoke]

Heh, you put it on the wrong line to see if I was paying attention? It works after line 8.

[thinkyhead]

So does this expose a bug or is this just a "feature"?

[nophead]

G code should always be executed in the order it is written but Marlin queues some commands and immediately executes others. This messes things up all over the place but people tend to notice it more at the end.

[alexborro]

What @nophead said is expected and "as designed". All movement commands (G1/G2/G3) are buffered. The default buffer has 16 positions, so you have 16 commands in line. If one send 10 G1 commands and then a M104 S230 command, the last one will probably be executed before the first G1 finishes. That's the reason we have the M400 commands if one needs to finish all buffered commands before executing a non-to-be-buffered command.

One option would be buffering all commands.. for that we will need to change some concepts - it is like a low risk brain surgery.. It is perfectly feasible, not that complicated but needs care and attention.

Cheers.

Alex.

[thinkyhead]

@alexborro I have no problem with buffered versus unbuffered commands. We should delineate that in the documentation, primarily on the new wiki, which commands are buffered and which are unbuffered – make M400 a primary topic in the G-Code Essentials section.

[dmmedia]

Seems to be fixed in the latest code. I will try several of more prints and will close the issue if it is not observed any more.

[boelle]

closing as it was reported fixed 4 days ago and no reports since

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.