SeanTapscott

Thanks for the reply. Been double checking my root partition, and it has remained at 64%.

It should be mentioned that I did upgrade to the latest firmware version, and I'm not convinced that the problem isn't still going to occur. Did some kind of file system management cleanup utility stop working in the latest firmware version that is causing the root partition to fill up? Mine was at 57% earlier, now it is at 59%, so it may be climbing, or it may be normal, not enough data yet. root@ultimakersystem-ccbdd3001d4c:~# df -h Filesystem Size Used Avail Use% Mounted on /dev/mmcblk1p2 941M 474M 336M 59% / devtmpfs 471M 0 471M 0% /dev tmp

I posted this in another topic, and I'll share it here as well.

Be comfortable with linux, have the printer in dev mode already. If you don't have either, contact your reseller. More info: Realistically, if you don't understand this, you shouldn't touch it. Super dangerous if you don't know what you're doing. Not to say that you shouldn't play with Linux, but not with computers/devices that you care about.

I found a way to unfreeze and update the firmware without reflashing the whole thing. If you're getting just a "Print Failed" screen after a firmware update, you can clear the frozen screen by stopping and then starting the griffin.hmi.service through systemctl stop and start. Then I was able to move the wheel down to finish the upgrade to 5.2 without a painful microSD flashing. For further information, the root partition was full, which is what caused it to randomly stop responding, but was able to still print, just not respond or update logs. This was apparently re

I can't see a way to dump logs to usb when the screen doesn't work. Is there another way to find the logs through SSH?

This just happened to me last night as well. The printer became "offline" or "unable to connect" in the print queue interface during a print, then became unresponsive when the print was done. The wheel could be clicked, and would make a sound, but that screen wouldn't clear, even after restarting the printer. This did occur after a firmware upgrade.

No, I'm saying the Sharpest Corner Z-Seam feature could be more intelligent with how it chooses where to start the layer.

Hi YellowShark, Yeah, the whole initial problem occurred with a square because the existing algorithm for finding the sharpest corner doesnt' account for distance. So it will chase down that 0.01mm difference between the corners' sharpness angles. Which is why I suggested an improved algorithm with a weighted decision making that also accounts for the distance required for getting to that sharpest corner. Without it, it combs or retracts like crazy to find that 90d corner on the other side of the model rather than the 85d corner that is 3mm away. The poin

Thanks for the reply, Smartavionics. I find user-defined z-seams to also be difficult and sometimes unreliable unless you're dealing with a vertical-faced object and you place the seam on a consistent corner in the model. I welcome any advice you may have about using it. For that feature, sometimes I have to guess or count little squares to figure out where Cura believes (155,105) is on the build plate. The sharpest corner is a really awesome idea, and I think we could iterate it a bit further to make it even better at making decisions. Thank you again.

If you print a square with identical corners, Cura struggles to find the sharpest one, and will normally retract and move between corners adding a lot of time and a lot of silliness to the pathways. Sharpest pathway should be a bit less "ONLY THE SHARPEST ONE WILL WORK" and perhaps instead look for the closest sharpest corner within limits. If there is only a 0.01mm difference or less between different corners, just choose the closest. SUGGESTION If I were going to write pseudocde, I would analyze all the sharpest corners and put them in an array/list/dictionary along wit

Finally figured it out. Ok, figured this out. If you go back to his original API post, you'll find there's a typo in the Swagger API documentation. To set the temperature, you need to send a CURL -X PUT to http://192.168.1.15/.../extru.../1/hotend/temperature/target \ -H 'Accept: application/json' \ -H 'Authorization: Digest username="e7070a69184a88fa7155b53703c026de", realm="Jedi-API", nonce="ee9219554d47256f6fcda62f006908ea", uri="/api/v1/printer/heads/0/extruders/1/hotend/temperature/target", algorithm="MD5", qop=auth, nc=00000001, cnonce="iCCymccp", response="b1c26cba5c37a

Did some more testing, can move the head up and down and all kinds of positions, but cannot change the temperature.

Can we submit the temperature API setting PUT "Method Not Allowed" as a bug? This feature increases accessibility to the printer, and is awesome, but it fails to actually work when required. Specifically, I'm trying to enact it during a pause, and I confirmed that the API Post method does not work when printing either.

Are there any other workarounds? API Put method on the hotends doesn't seem to be allowed, which is immensely frustrating.