Cura or UM3+ reprints same job again, recurring bug

[SilverDynamic 1]

This has happened several times now and is becoming rather frustrating wasting both time and material.

Often when I send a new job to the printer it just goes ahead and reprints the job it did last.

Today it did it after a cold restart of both the printer, the PC and obviously Cura.

It can happen at any time after an aborted print in which I am careful to select NO to retry? It can happen after a fresh start or after successful completion of a job when I send a new job.

Today despite having cleared the printer last night and "removed the print" when I fired it up the "print removed" query was back again. This delayed the print and when I cleared it it just printed the last job again instead of the new job, which was the only job that was queued... obviously because I had only just turned the whole lot on.

I am utterly baffled.

Firmware is and always has been the latest version. So is Cura.

[kmanstudios 1,120]

I have never seen this issue. Did it start immediately or did you notice shortly after? Are you using Cura Connect to print or other method?

[ultiarjan 1,223]

I have seen it during the cura connect early beta... But have not had it recently.

[robinmdh 100]

can you maybe provide some logs? You can get those via the dump logs to USB option in the maintenance menu.

Did you turn off the printer shortly after confirming the buildplate was cleared?

If you do/did that, it can explain the behavior you're seeing.

There will always be a chance of unintended consequences when you turn a computer of just after doing something that should be saved, this is no different. And in our case unfortunately off is just that, imediate, like pulling a plug.

Edited December 11, 2017 by Guest

[cjs 34]

I also experienced the bug(printing the last job even when not selected) a few times in the stable 4.0 release.

@robinmdh How long do you recommend to wait? What about a way to turn of the machine by selecting shutdown on the lcd?

[robinmdh 100]

@cjs, A minute or 2 should suffice.

There currently is turn off menu option and with the current hardware it is dubious. (yes, the software can turn off, but then everything is still powered on, the user must then still use the switch at the back; why would you want to do both?)

can you confirm then that this happens after clearing a buildplate clean message, followed by a power cycle (turning something on and off, not related to bicycles of any kind:P)

We were thinking about a status indicator, telling you not to switch the machine off, but preliminary work seems to indicate this will not work with our file system.

Edited December 11, 2017 by Guest

[robinmdh 100]

Oh, right and I forgot there is a bug that when you don't clear the "print finished, clean buildplate" message before a reboot it will come back as a "print FAILED, clean buildplate" message and after clicking OK on that, the print will indeed be reprinted. :(

Edited December 11, 2017 by Guest

[cjs 34]

@cjs, A minute or 2 should suffice.

There currently is turn off menu option and with the current hardware it is dubious. (yes, the software can turn off, but then everything is still powered on, the user must then still use the switch at the back; why would you want to do both?)

We were thinking about a status indicator, telling you not to switch the machine off, but preliminary work seems to indicate this will not work with our file system.

You wouldn't want to do both and therefore people would probably only use the switch. (Just remembered that this was some advice in the raspberry pi documentation at some point I think)

What about a standby(motors and oled display turned off until click wheel input) mode? To prevent oled burn in. Turning off the screen would also be nice while printing after x amount of time as I know UM2+ suffer from burn in. Or some kind of pixel shift to prevent burn in (like samsung does on their smartphones).

I do like the idea of an indicator. Maybe a static indicator, which gets displayed for a certain time (1 minute) after input ?

can you confirm then that this happens after clearing a buildplate clean message, followed by a power cycle (turning something on and off, not related to bicycles of any kind:P)

Yes I can confirm that this happened to me a couple of times with firmware 4.0. I think I also experienced it after a power cycle but not as often as it isn't the normal use case. Haven't printed that much with 4.1 and therefore don't know if it was fixed.

After confirming this message as well as the one after an aborted print.

Oh, right and I forgot there is a bug that when you don't clear the "print finished, clean buildplate" message before a reboot it will come back as a "print FAILED, clean buildplate" message and after clicking OK on that, the print will indeed be reprinted. :(

Oh :( Can we expect an update withe the fix soonish?

[kmanstudios 1,120]

I had something like that happen to me yesterday. It is covered in this thread.

Not sure if it is the same thing or not, but it sure sounded familiar.