Closed breathless19 closed 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.
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
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 printed 18 objects, and had no issues..
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
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.
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." :)
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.
I’ll try tomorrow and see what happens
I tried to print your stl, get the same error see below:
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!
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:
Console output Attached, but doesn't seem to be helpful
Base (please complete the following information):