Phil1988 / FreeDi

LCD firmware for Qidi X-3 Series printers with mainline Klipper
Other
99 stars 3 forks source link

[External bug] When printing a file with many small objects, printer freaks out and requires complete shutdown / restart #89

Closed breathless19 closed 2 weeks ago

breathless19 commented 2 weeks ago

Describe the bug When printing a file with many small objects (anything too much over 1000 typically) on my X-Max 3 (FreeDi 1.3.0), the printer freaks out and requires a hard power off / power on cycle to regain functionality. It happens right after the "upload & print" process is complete (Using QidiSlicer but also occurs in other Slicers like Orca). Sometimes the screen on the printer shows the thumbnail of the print before it crashes, sometimes not. I know the print will continue / succeed if it gets to the point where it starts the bed mesh. Klipper / firmware restart is insufficient when the issue occurs, it must be powered off / on. I've tried just the "upload" without print option in the slicer to perhaps give the machine time to "think" about the file prior to immediately starting the print to no avail. As long as the total piece count is under roughly 1000 total pieces, the print will usually succeed, though I can cheat a little and get a little over 1000 with certain prints.

To be fair, the same issue occurs with the original Qidi firmware, so I'm not sure if this is a limitation of the printer or of the firmware. It does not appear to be related to the cpu being overloaded at first glance, as it doesn't seem to peak over about 50% when viewing the process / result via Mainsail when the print job is started. Memory does not appear to overload either. The printer does appear to fully recover and print without issue after the hard shutdown.

Why this is relevant? ("why don't you just print lower quantities?") I often use the "fill bed with instances" option within QidiSlicer for tiny objects like spacers that we print. Its almost the only way that I print when / where possible. These prints don't take more than a day, and often times a lot less than that, even with massive quantities. Being able to print the highest possible number of pieces at a time is more efficient. We have pieces so small that its possible to fit well over 4000 of them on the bed, and such a print would only be between 24 - 36 hours to print, so it would be nice to be able to do a print like that once VS having to start such a print 4 different times to get the same number of pieces.

Expected behavior The printer should be able to print a file with a full bed of many small objects.

To Reproduce Steps to reproduce the behavior:

  1. Download my STL / Gcode / 3mf files. The 3mf with "1444" in the title contains the full project, which is simply the single STL "spacer" imported into a new project and then use the "fill bed with instances" option. This file will crash the printer. The file that contains "1024" in the title prints without issue.
  2. Print it if you dare! :) You'll be fine after a reboot, and you can reproduce the same issue with any other slicer assuming it fits significantly more than 1000 pieces on the bed.
  3. You will likely get the standard error screen that allows you to restart klipper / firmware, etc, but you'll need to hard shutdown.
  4. Reboot your printer and scratch your head
  5. Here is a link to watch a video I took of the situation so you can see for yourself: https://youtu.be/vmqfeqKMgWA

Image Image

Console output Attached, but doesn't seem to be helpful

Base (please complete the following information):

rosenrot00 commented 2 weeks ago

Thanks for the detailed report. Could you share the gcode in a way we don't need to login with my Google account? I would be happy to look at it.

Phil1988 commented 2 weeks ago

Thanks for your issue report. This is not related to FreeDi but to klipper, moonraker and/or the UI (Fluidd | Mainsail).

I guess it may be connected to the "Label objects" option. This amount of parts may just be too much for such a large number of different objects. You can try to deactivate this option and see if this workaround solves it for you. You can find it here in QIDI Slicer

Image

A fix can not be applied on my side as its linked to the klipper/moonraker. I suggest you ask on their discord channels to see who is responsible for this first and then open the an issue report with the same good and informative text there.

Leave the FreeDi debug screenshot out as its not relevant.

EDIT: And please feedback if my workaround does "solve" it in your case.

pmbroth commented 2 weeks ago

I printed 18 objects, and had no issues..

breathless19 commented 2 weeks ago

I printed 18 objects, and had no issues..

Not 18.... 1444. Load my STL in a new file (or use my ready made file), "fill bed with instances", then print.

Thanks for the detailed report. Could you share the gcode in a way we don't need to login with my Google account? I would be happy to look at it.

Thanks! Try my OneDrive link.... You shouldn't need to login: https://1drv.ms/f/s!AkMPYkY7E_ogjkbD73qTXsZtnbE1?e=pxfqgm

Thanks for your issue report. This is not related to FreeDi but to klipper, moonraker and/or the UI (Fluidd | Mainsail).

I guess it may be connected to the "Label objects" option. This amount of parts may just be too much for such a large number of different objects. You can try to deactivate this option and see if this workaround solves it for you. You can find it here in QIDI Slicer

Image

A fix can not be applied on my side as its linked to the klipper/moonraker. I suggest you ask on their discord channels to see who is responsible for this first and then open the an issue report with the same good and informative text there.

Leave the FreeDi debug screenshot out as its not relevant.

EDIT: And please feedback if my workaround does "solve" it in your case.

I tried the suggested setting change, and interestingly enough, it was able to start a print with about 1300 pieces, but not without issue. So when the print starts, it cuts really quick to the Klipper error screen on the printer, and then cuts right back to the print screen and seemingly continues on with the print as it should. However, if I had to guess I would say that certain modules crashed even though it was able to continue the print, because my cartographer went half the speed as its programmed to, and my pieces weren't sticking to the bed after the mesh.

Phil1988 commented 2 weeks ago

I'll change the title now, as I am sure it's not related at all to FreeDi.

I don't own a cartographer and frequently hear/read about different issues/bugs in combination.
So my best guess is still Klipper, Moonraker, and now also Cartographer as the "cause candidates." :)

breathless19 commented 2 weeks ago

I agree, except that I'll just add that its definitely not caused by Cartographer. All of my 7 x Qidi X-Max 3's have had this issue from day one, and this is the only one of my printers that has the Cartographer installed.

pmbroth commented 2 weeks ago

I’ll try tomorrow and see what happens

pmbroth commented 2 weeks ago

I tried to print your stl, get the same error see below:

Image

Phil1988 commented 2 weeks ago

I'll just add that its definitely not caused by Cartographer.

Good to know that. So with the screenshot from @pmbroth its likely an cpu overload/optimization problem inside of the klipper jungle ^^

Ill close this issue right now, just to keep it off my "urgent-radar", but please keep us updated!