search

aegean-odyssey / mpmd_marlin_1.1.x

a fork of Marlin firmware (bugfix-1.1.x) for the Monoprice MP Mini Delta 3d printer
GNU General Public License v3.0
76 stars 19 forks source link

Printer pauses midprint using octopi #96

Closed THE-BOW closed 2 years ago

THE-BOW commented 2 years ago

I have an issue printing whatever from octopi. Printer starts to print over serial without issues (prints fast without stuttering) Suddenly the printer pauses and stays for a couple of seconds then it goes on. Might be caused by small buffer size...

BackwardEcho commented 2 years ago

Are you on r16? I'm having a issue with serial prints myself. I tried to print a couple of tests prints only to have it pause and not resume after a while. I don't know if it's because of pronterface or the printer itself, but I just stick with SD card printing no matter what now.

THE-BOW commented 2 years ago

Thank you for replying. I switched to upload directly to SD card in Cura. Takes some seconds more but prints without pausing or stuttering. The SD Upload takes maybe 5 to 10 seconds.

aegean-odyssey commented 2 years ago

Printing directly from an SD card does eliminate sources for potential problems, and I think it's the best solution.

As far as printing from Octopi, I do know of one user whose four MPMD printers print exclusively via Octoprint on a Raspberry PI. That said, there is a fair amount of cpu overhead when the printer communicates via usb. It's not a buffer size problem, but more of the motion control and usb communication require a high priority when either demand the cpu's attention. Either activity can bog down the cpu.

As I recall, OctoPrint is pretty good at syncing up with the printer to provide g-code commands at a rate to match the printer. The firmware enables Marlin's extended handshaking for this purpose, as well. If the communication link is solid and the OctoPrint side of things is able to keep up (it problably is) and not the cause the pauses, then the printer's cpu is likely "maxxed" out.

One way to reduce the load of the motion control is too reduce the "segments per seconds" that the firmware tries to generate when computing a path. This is specified in the S parameter of the M665 command. A number to high and the printer's cpu is bogged down computing line seqments for each motion. Too low and the motion becomes a bit sloppy. I chose the default value, 200, after some testing, but I can't say for sure that it's the best value to use -- it seems to work.

BackwardEcho commented 2 years ago

If the problem is M665 S###, then this was mentioned before on the roadmap guide, page 41 and 45, 41 specifically mentions octopi printing. It suggest a value of 120 instead of 200.

THE-BOW commented 2 years ago

Thank you all. I will give it a try to change the values. If not i will stay with the "Upload to SD Card option" Think we can close the issue ;-)