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 tmpfs 504M 0 504M 0% /dev/shm tmpfs 504M 1.4M 502M 1% /run tmpfs 5.0M 0 5.0M 0% /run/lock tmpfs 504M 0 504M 0% /sys/fs/cgroup tmpfs 504M 0 504M 0% /var/lib/apt tmpfs 504M 0 504M 0% /var/cache/apt tmpfs 504M 4.4M 499M 1% /tmp /dev/mmcblk1p3 2.7G 39M 2.4G 2% /var/spool/cluster /dev/sda1 29G 4.1G 25G 15% /media/usb0 root@ultimakersystem-ccbdd3001d4c:~# Are we supposed to be using that /var/spool/cluster for the root, or is that reserved for print files?

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 related to my daughter accidentally updating the firmware to the step-up firmware before 5.2, and then I didn't perform the second firmware update to 5.2. My df -h is now back to 57% in use on the root / partition. Some logs that shows some of the 100% in use messages I was receiving. root@ultimakersystem-ccbdd3001d4c:~# journalctl -fu griffin.printer -- Logs begin at Sat 2019-03-23 01:36:37 UTC. -- Mar 31 18:36:06 ultimakersystem-ccbdd3001d4c python3[356]: Traceback (most recent call last): Mar 31 18:36:06 ultimakersystem-ccbdd3001d4c python3[356]: File "/usr/share/griffin/griffin/preferences/registryFile.py", line 129, in __save Mar 31 18:36:06 ultimakersystem-ccbdd3001d4c python3[356]: with open(temp_filename, "w") as f: Mar 31 18:36:06 ultimakersystem-ccbdd3001d4c python3[356]: OSError: [Errno 28] No space left on device: '/var/lib/griffin/printer_hotend_0_preferences.json.new' Mar 31 18:36:06 ultimakersystem-ccbdd3001d4c python3[356]: 2019-03-31 18:36:06,388 INFO registryFile Saving preferences to /var/lib/griffin/printer_hotend_1_preferences.json Mar 31 18:36:06 ultimakersystem-ccbdd3001d4c python3[356]: 2019-03-31 18:36:06,390 ERROR registryFile Error writing preferences /var/lib/griffin/printer_hotend_1_preferences.json Mar 31 18:36:06 ultimakersystem-ccbdd3001d4c python3[356]: Traceback (most recent call last): Mar 31 18:36:06 ultimakersystem-ccbdd3001d4c python3[356]: File "/usr/share/griffin/griffin/preferences/registryFile.py", line 129, in __save Mar 31 18:36:06 ultimakersystem-ccbdd3001d4c python3[356]: with open(temp_filename, "w") as f: Mar 31 18:36:06 ultimakersystem-ccbdd3001d4c python3[356]: OSError: [Errno 28] No space left on device: '/var/lib/griffin/printer_hotend_1_preferences.json.new'

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 point of confusion was probably the hypothetical which I used to illustrate how an improved weighted decision algorithm would function. Didn't use a square in that hypothetical. I probably should've added a TLDR.

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 with their distance from the current point. Then we need to set/analyze the optimum ratio between sharpest corner and distance we'll have to travel to get there. HYPOTHETICAL: If you have three corners, one is 90d and 50mm away, second is 100d, 10mm away, third is 80d, 100mm away, which do you choose as sharpest? Sharpest is 80d, but at 75mm away, is also farthest. At this point, I would start looking at benefits of the sharpest corner, and you'd have to weigh each of the decisions based upon your preference for distance or sharpness. Myself, I'd prefer short and sharp in a supply/demand style of curve intersection. 60% preference on shortness (Less distance travelled, less time, better/no retraction). 40% preference on sharpness.(hidden z-seams... other benefits?) Normalize data to percentages of max values. 100d/x for degree normalization. Inverted because lower degrees are better. 100m/y for distance normalization. Inverted because lower distances are better. Corner 90d, 50mm, (1.11, 0.5) ## 0.4*1.11 = 0.444 ## 0.6*0.5 = 0.3 Total = 0.744 weight Corner 100d, 10mm (1 , 10) ## 0.4*1 = 0.4 ## 0.6*10 = 6 Total = 6.4 weight Corner 80d, 100mm (1.25, 1) ## 0.4*1.25 = 0.5 ## 0.6*1 = 0.6 Total = 1.1 weight CONCLUSION You can see that the best corner to start the layer from would be the 100d, 10mm one in this algorithm. I would set the preference weights to be user-adjustable in the Cura interface under the Sharpest Corner preference.

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="b1c26cba5c37a19c14731816024e269a"' \ -H 'Content-Type: application/json' \ -H 'Postman-Token: da5f6c8b-f68a-4fa8-94b6-9dd0eccc123c' \ -H 'cache-control: no-cache' \ -d 200 Need to add /target to the end of the API call, and only pass in a number value, with no text.

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.