Hi there, thanks for the nice reply,
i don't believe the usb stick is broken, my colleagues use it as well without problems.
Also i made a mistake in the last post, CREO is the other program my colleagues and me are using for modeling. I only sliced in cura.
I'm not sure how this code could help me but i will attach those files (for some reason i can't upload ufp files. and i was unsure which log file is the right one so i send a lot). i usually use ufp.
I still wonder what could have changed since it worked fine in November and earlier.
failed print.3mf process_data.log sensor_data.log dmesg.log flow_ptcr-Ultimaker.log process_data.log sensor_data.log flow_ptcr-Ultimaker.log
Edited by SandervGRemoved ~30 attachments
Recommended Posts
robinmdh 106
the TL;DR is sent me logs and a sample and I might be able to find out more.
long version:
Thinking out loud(in text) here...
The first thing that comes to mind is a corrupted/broken usb stick, that can cause similar problems, but you're printing via Ethernet...
Try to use the UFP format, if you're not already that will likely detect corruption since it's a zip container.
I assume you don't mean you use Cura to design, so are you slicing in some other program or designing your input in some other program? I assume blender and some other CAD tool? you tried OBJ output as well... (from the other cad tool as well?)
Not really most of everything is passed trough and if Cura generated the output so it should be good for our printer. The only bit of code that can go wrong is this.
This is the only part that exception you got can come from.
- The readline reads either plain text (in the case of a .gcode file) or reads from a zip stream (in case it reads from a .ufp file). the reading from the zip stream could fail, IO could fail for instance if a USB stick is removed during printing.
- The line has to be valid utf-8, this is where file corruption usually goes wrong.
- The timeEstimation and _parseMetaData could cause errors, they do assume the lines that start with:
That there is a integer following the first 2 and a float following the last, if that is not the case it will break there...
obviously the abort is not set so.
You could send me the logs of the print, you can dump the logs to usb via maintenance -> diagnostics -> dump logs to usb. Maybe include a sample failing ufp or gcode file, if printing from USB please also include the file read back from the usb stick.
Link to post
Share on other sites