[BUG] Sending files from Prusaslicer to Prusalink often generates Conflict error

[mix579]

Please, before you create a new bug report, please make sure you searched in open and closed issues and couldn't find anything that matches.

Printer type - Mini

Printer firmware version - 4.4.0-RC1

Original or Custom firmware - Original Optional upgrades - Filament Runout Sensor

USB drive or USB/Octoprint Prusalink — from Prusaslicer

Describe the bug Probably have of the time I send a file from Prusaslicer directly to the printer via Prusalink (wifi), I get a Conflict error and the printer displays the screen that shows a preview of the model and requires me to manually select Print on the LCD display. But not all of the time. Sometimes the print starts immediately. In all cases I made sure the LCD screen shows the home screen. Why that is a requirement at all is a different subject…

How to reproduce I have not been able to find a pattern. Sometimes it happens, sometimes it doesn't.

Expected behavior Start print immediately without operator assistance.

[Prusa-Support]

Thanks for the report. We need clear instructions for the reproducibility of the error. Possibly, also the exact error message or a picture of it.

Please provide a problematic gcode if you don't mind, or information about it like exact name of the fail and approximate size. Is there a chance that it was sent twice? Is there a chance that the printer was temporarily disconnected? Is there a chance the printer was not on home screen without you noticing?

What modality of sending the file are you selecting in Prusa Slicer, "upload" or "upload & print"? Does this even make a difference? Did you happen to upload multiple files in a row? Is Prusa Link dashboard displayed from the browser meantime?

Michele Moramarco Prusa Research

[murk-sy]

Note that (I believe at least) moving between menus during upload can cause an error as well, even if you leave it on the home screen at the end. If you do anything else with the printer in the mean time (for example start preheat), that may be a cause, but I haven't tested that extensively.

[thomasguenzel]

I've got the same problem using the ethernet connection (4.4.0-RC1). The printer just displays the preview and PrusaSlicer says "409: Can't print right now".

[Prusa-Support]

Indeed, it was observed that overlapping commands could cause issues either on the printer or the server side. This may result in "out of memory" errors on the printer side (https://github.com/prusa3d/Prusa-Firmware-Buddy/issues/2351), or "409" errors on the browser. In this case, the latter.

We would need to be able to reproduce the problem intentionally to really understand it, and possibly exclude known variables that may cause issues like "wrong screen displayed".

Michele Moramarco Prusa Research

[Devirex]

Hi, i have it too. Steps to reproduce: "Upload and print" a sliced file. While printing go to the slicer and slice a new file. After print is finished clean the bed and leave the printmenu on the mini so that you are in homescreen. "Upload and print" the new gcode. Than you get the error 409 Can't print right now even when the mini is idle. Also if there is already a file with same name on the printer, you get a "Conflict" error. An option to "overwrite and print" would be great.

[rinkek]

Got this issue too. Would also like the option to overwrite, which is really helpful when doing a testprint over and over again. Now you have to delete the file manually each time.

[Prusa-Support]

There is an issue already listed about conflicts due to files with the same name and the inability to overwrite https://github.com/prusa3d/Prusa-Firmware-Buddy/issues/2447.

.

I tried to reproduce the issue as recently suggested, but I was not able to.

1. Prusa Slicer / Prusa Link browser dashboard > Upload and print / Start print after transfer
2. Print finished > Home
3. Prusa Slicer / Prusa Link browser dashboard > Upload and print / Start print after transfer (different name)

I tested a few times on FW 4.4.0 (final) and 4.4.0-RC1 too.

I'm unable to reproduce the issue but as far as I can tell you, my Wi-Fi module (or router) loses connection every once in a while. Fun fact: it most often (maybe coincidentally) happens during the mesh bed leveling. If the connection is not restored, the ESP module is restarted every 60 seconds and eventually restores the connection. My suggestion here is to actively monitor if Wi-Fi symbol on the MINI's display, as the connection could be interrupted several seconds before and after it is grayed out.

.

Please mind that we have other issues without a conclusion, probably because the issue is not reported clearly enough or is not always reproducible. Also, the currently known firmware limitations could lead to confusion during the operations as noticed in a few cases, for example, in issue https://github.com/prusa3d/Prusa-Firmware-Buddy/issues/2301. I actually don't want that this issue is a duplicate of the same generic and undefined issue discussed there. My suggestion is to add as many details as possible to reproduce the issue, and possibly clearly document the steps and the issue itself with videos.

Michele Moramarco Prusa Research

[mix579]

This is turning into a serious issue. And unfortunately I have not found a way to reliably reproduce it. This afternoon I printed three jobs. In each case, I loaded fresh filament, the LCD screen is on the home menu. I slice the file, upload and print from PrusaSlicer. The first two times, no problem. The third time (same procedure: fresh filament load, making sure LCD screen is on home menu, upload and print from PS): ERROR. I walk to my print shop and sure enough, the print preview is showing, waiting for me to press the button to confirm.

I really wished there was a way to create a reproducible series of steps to generate this error but it really feels random. And it's getting more than annoyance. Yesterday I checked on my printers after a few hours just to discover that one of them was still sitting on the "please confirm" screen, wasting hours of possible print time.

[Eldenroot]

I have same issue, but cannot find a way how to reproduce it. It happens sometimes, I use ethernet connection. You can see a new file and view on the printer display but it does not start (printing).

[hreality]

So, in my instance.. If I upload a file to print (prusalink mini via wifi) 'upload and print' once that print is complete it remains on the reprint screen. If I try and upload and print again I get the conflict error message. IF however I manually return to home the issue doesnt present itself. Is there some code I can place in the slicer 'print end' to return to home after success?

[ivan-sadovsky]

Same issue here with v4.4.0 via WiFi. The steps in PrusaSlicer
Slice -> Send to printer -> Upload and Print produce the following error message

If Prusa Mini is in the printing mode (even if the print is finished) I get this error message with 100% probability as it should be.

If Prusa Mini is in the main menu, I get this message with about 50% probability; sometimes the print dialog with the model preview appears on the printer. With other 50% probability, it starts printing the model I sent.

[Prusa-Support]

Please mind there could be various other "more or less obvious problems" that intervene in this "undefined issue". For example, the Wi-Fi connection (where used) may have gone interrupted, or the USB flash drive doesn't work as intended. Moving the printer closer to the Wi-Fi source, or changing the USB flash drive, maybe interesting tests.

I'm positive that Wi-Fi connection stability and data transfer reliability will be improved over time and possibly reduce the chances of erratic issues, allowing us to focus on more recurrent and reproducible issues.

Thanks for your efforts to reproduce and document the issues.

Michele Moramarco Prusa Research

[Eldenroot]

Well I use both wifi module and ethernet port. Both connection types are affected. Tried different usb thumb drives, including a one one... It just happens... Printer connected via switch, tested also connected directly and also second switch.

When the error occur and you turn off/on printer, all is fine. Also when you go do print section on display and back. All is fixed

[mix579]

While I wish there were a 100% reproducible way of creating this scenario it clearly has nothing to do with network connectivity. Like eldenroot, it happens on Ethernet as much as on WiFi. Almost feels like a race condition. After the file is sent it seems that sometimes the firmware just manages to sneak the print preview dialog in before Prusalink can execute the print command.

[ivan-sadovsky]

@Prusa-Support, the .gcode files appear at the flash drive in 100% cases, which cannot happen with interrupted wifi connection of corrupted flash drive. The problem is that sometimes printer (1) starts the new print and sometimes (2) one gets the error message 409: conflict. The filenames are unique.

[ivan-sadovsky]

Btw, @mix579, @Eldenroot, what PrusaSlicer version and OS do you use? I have this bug at PrusaSlicer 2.5.0 and macOS 12.6.2.

[mix579]

PS 2.5, MacOS 13.1.

As you said, files get transferred without any issues (as long as the filenames are unique). It then seems to be the flip of a coin whether a print is started or the print preview pops up.

[Eldenroot]

Win 11 Pro and Prusa slicer 2.5

[daver360]

Windows 10 Pro and Prusa slicer 2.5 I'm still using the original USB stick provided by Prusa.

[Prusa-Support]

Alright, thanks for your feedback. We may need more clues about the problem as it is still rather generic now. Please keep on posting any recurrent aspect of the issue that you may have noticed as well as new details that you may have not noticed in the first place, and feel free to share your thoughts.

So the Operating System and the type of connection are less of a concern apparently.

I'm still positive that the natural optimization of data transfer and management will improve the issue, and rule out some of the possible players of the problem.

Michele Moramarco Prusa Research

[dwbmb]

I finished the print, cleared the heatbed and went to work. Tried to upload and print something remotly from PrusaSlicer (2.6.0-alpha3), ending in 409: Conflict. Connected directly via PrusaLink, found uploaded file, pressed the print button and ended up with the same 409 on PrusaLink website.

Maybe the clue is that I did not switch back to the main menu before I left home. FW 4.4.1

[murk-sy]

I've managed to reproduce it on my machine, more or less. Conclusions/TLDR below

1) Prepare a short print to run.
2) Turn off the printer for 10 seconds and then turn it back on. USB storage should be connected.

3) U&P file A. Print starts automatically.
4) Stop A and go back to Home.
5) U&P file B. 409 conflict, but b.gcode is displayed (as if only Upload was pressed).
6) Go back to Home.
7) U&P file C. Print starts automatically.
8) Stop C and go back to Home.
9) U&P file D. 409 conflict, but d.gcode is displayed.
10) Go back to Home.

11) On the printer. manually start d.gcode.
12) Stop D and go back to Home.
13) U&P file E. Print starts automatically.
14) Stop E and go back to Home.
15) U&P file F. 409 conflict, but f.gcode is displayed.
16) Start f.gcode from the displayed menu.
14) Stop F and go back to Home.
15) U&P file G. Print starts automatically.
16) Stop g and go back to Home.

17) Only upload file H.
18) H is displayed. Go back to Home.
19) U&P file i. Print starts automatically.
16) Stop i and go back to Home.
17) Only upload file J.
18) J is displayed. Go back to Home.
19) Only upload file K.
20) K is displayed. Go back to Home.
21) U&P file L. Print starts automatically.
22) Stop L and go back to Home.

23) Change to a different USB drive, preferably freshly formatted.
24) U&P file M. 409 conflict, but m.gcode is displayed.
25) Go back to Home.
26) U&P file N. Print starts automatically.
27) Stop N and go back to Home.

28) Manually start and stop file M, then start and stop file N.
29) Open file N preview, but then go back to Home.
30) U&P file O. Print starts automatically.
31) Stop O and go back to Home.

Conclusions:

• 3-10 - Every second U&P appears to fail
• 11-16 - Starting a print manually after failed autostart does not seem to break the next U&P
• 17-22 - Normal uploads seem to "reset" the error - only 2 U&P in a row appear to cause issues.
• 23-27 - Issue is not related to storage or corrupt storage
• 28-31 - Reconfirmation of 17-22

Mini is connected via ethernet, but has a (reliable) wlan hop in between. I've tested this on one mini, but if you can't reproduce it on your end, I'll try the others too when time allows.

[ivan-sadovsky]

@murk-sy did you run steps 1-10 once? Or several times with the same result?

[dwbmb]

With 4.4.1 firmware and 2.6.0-alpha4 prusaslicer I do have this issue every single time even with the printer ready on the home screen before sending the print via WiFi. PrusaSlicer gives me this error, but the gcode is sent to printer correctly and is ready to print, but I have to press the print button on printer manually.

[mix579]

I've been thinking more about this… With the caveat that my days as a software engineer have been over for 20 years and I don't know anything about the innards of the Prusalink protocol:

This feels less like a connection issue and more like a race condition between the firmware detecting a new file on the USB stick and throwing up the preview screen, and the Prusalink protocol sending the print command after uploading the file. Assuming that the firmware only checks periodically for new files that would explain why sometimes it's faster than the Prusalink print command, in which case the preview blocks the print, and sometimes it's not, in which case the uploaded file will be printed fine.

But then again, this is just me trying to come up with some ideas for what might be going on, not based on digging into the code. Take it for what it is, a scenario that seems to mesh with the observations.

[nickrbogdanov]

With 4.4.1 firmware and 2.6.0-alpha4 prusaslicer I do have this issue every single time even with the printer ready on the home screen before sending the print via WiFi. PrusaSlicer gives me this error, but the gcode is sent to printer correctly and is ready to print, but I have to press the print button on printer manually.

I see the same exact thing with 4.4.1. If Prusa is having trouble reproducing the issue, please let me know how I could help debug?

Even if I manually add random characters to the gcode filename to ensure it's unique, I get a 409 Conflict error for no reason at all. I then return to Home, hit Print, and select the new file. This is nearly 100% reproducible.

My Mini is on wired ethernet (sadly, it doesn't appear to support connecting to my EAP wifi).

I have an MK3S attached to an OctoPi and that setup is far more reliable than this. I don't understand why submitting a print job to an idle machine needs to be so finicky. While the competition is blazing new trails, Prusa is struggling just to make the basic functions work. 😑

[DFEvans]

I observe this semi-regularly, as with others. I'm not entirely sure if everyone's viewing this as the same cause. Prusa Support seems to be interpreting the sequence of events as:

1. File is uploaded
2. Some unknown error causes a conflict to be generated when "print" command is sent
3. Printer recovers from that unknown error by showing newly uploaded file for printing, as if a USB had been inserted with a new file on board

My interpretation of the sequence of events has been that:

1. File is uploaded
2. Printer firmware sees a new file and believes a USB has just been inserted with a new file, causing it to show the "Print?" prompt on the screen (as if the user were at the printer, inserting the USB)
3. "print" command is sent, but printer detects it is not on the home screen, and so returns the Conflict status

i.e. there is some issue with the suppression of the "new file detected, show user prompt on screen" logic - perhaps a failure to turn off that feature for all uploads, perhaps the USB connection briefly being interrupted and the printer seeing the USB as having just been connected, or perhaps a race condition where the printer is polling the USB filesystem every so often to look for new files and sometimes does this between "Upload" and "Print" commands.

[mix579]

Exactly what I suggested earlier, a race condition. Which is also why a simple "do step 1 then do step 2" is not going to reproduce the issue consistently.

[DFEvans]

A case this morning - once again:

• Printer turned on and booted to the home screen
• File sent via "Upload and Print"
• "Conflict" error after successful upload
• On inspecting the printer, it has started showing a "Print" prompt as if a USB had been plugged in with a new file

What we noticed this time is that the "Print" prompt on the printer was in an unusual, confused state. The filename shown was the newly uploaded one, but the print details - picture, print time, etc. - were all for the previous file. The previous file was uploaded and printed the day before (also via Wifi), with the printer having been turned off overnight after that.

(My colleague stated that this confused state, showing one filename but details of another after the printer sends back a Conflict error, has been observed before)

[mix579]

Yes, "confused state" is common on my XL as well.

[greywolfsystems]

Not sure if my experience is within this bug or seperate, however the descriptions follow fairly closely. Using FW 4.6.2 and PS 2.6 RC1. Connected via Wifi and Ethernet. The steps I usually find preceding this issue:

1. Slice and Upload G-Code from PS
2. Preview of G-Code automatically appears on XL Screen
3. Return Home on XL screen
4. Start print from Prusa Connect
5. Allow print to complete
6. Upload new G-Code from PS
7. Preview of G-Code automatically appears on XL Screen
8. Forget to return Home on XL Screen
9. Start print from Prusa Connect
10. Printer freezes, unable to navigate or start print via any method.
11. Switch off printer at wall - makes a significant noise
12. Switch on printer at wall
13. Printer automatically starts printing g-code from step 9

[ivan-sadovsky]

It seems the bug is gone with PrusaSlicer 2.6.0. I use it with Prusa Mini having 4.4.1 firmware

[DFEvans]

My colleague reports that they have seen it still occurring in 2.6.0, though less frequently than before - we'll keep a closer eye on it to see if there are any other changes.

Also, I'd happy to hear from @Prusa-Support if there is anything further which they would find helpful - log files from the slicer or printer (if it has any), packet capture to show the network activity, photos/video of the printer when the issue occurs, etc.

[rinkek]

Problem still persists on 2.6.0 It mostly happens when i have printed something and the LCD is still on the 100%-finished-printing display, then when printing from prusaslicer again, i get a "Conflict" in PrusaSlicer.

Edit, just tested this again, and yes

Or when a file already exists, which for me is the most annoying one:

[dwbmb]

I can confirm it is still in 2.6.0. Was in beta, RC and now also in stable. I do not print from prusa slicer anymore, just upload.

[DFEvans]

It mostly happens when i have printed something and the LCD is still on the 100%-finished-printing display, then when printing from prusaslicer again, i get a "Conflict" in PrusaSlicer.

Note that this is the intended behaviour - starting a print from Wifi is intended to fail if the printer is not on the home screen, including the "print complete" screen:

The printer should be on the home screen. If there is any prompt on the LCD screen, the printer will reject any remote command.

https://help.prusa3d.com/guide/wi-fi-and-prusalink-setup-mini-_316781

*MINI+ must be on the home screen and “print-preview” screen - this is intentional for safety reasons

https://github.com/prusa3d/Prusa-Firmware-Buddy/releases/tag/v4.4.0

The issue in this thread is that the Mini is intermittently opening the print preview screen (and in an inconsistent state, mixing data from two different gcode files) when a print is uploaded, as if a USB with new files had just been plugged in, causing that "must be on home screen" check to fail.

[neuron-whisperer]

+1

I have encountered this bug several times now on an MK4 running firmware version 4.7.0.

For me, this bug occurs when uploading files directly via the web interface, rather than through PrusaSlicer.

[Prusa-Support]

The developers are tirelessly working on improving the connection reliability and data transfer speed. Progress has already been done over the last few firmware releases (for MK4/XL, which will eventually be ported to MINI) and additional measures are being taken to reduce file transfer downtimes.

Most of the reported cases actually fall in the scenario "no home/print-preview screen" and limitation is actually put in place for safety reasons so this won't change - until further notice, I would say.

By the way, in this issue are gathered pretty much mixed generic problems, which is not ideal. I think the problem you call "confused state" was actually reproducible and already posted as a separate specific issue (as it should), and it has supposedly been solved - I'm talking about issue https://github.com/prusa3d/Prusa-Firmware-Buddy/issues/3046.

Michele Moramarco Prusa Research

[github-actions[bot]]

This issue has been flagged as stale because it has been open for 60 days with no activity. The issue will be closed in 7 days unless someone removes the "stale" label or adds a comment.

[github-actions[bot]]

This issue has been closed due to lack of recent activity. Please consider opening a new one if needed.