SeanTapscott

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.

Thanks for the response. Sadly, I did not put it in developer mode before printing, and so can't seem to connect via SSH. Probably need to be like serially connected.

I'm trying to save a print by sending an API call to change the extruder temperature. A bad pause caused the temperature to be set to 0, and it will not return back to the default printing temperature. It tries to print at 0 C, which is cold extrusion, so I'm surprised it is letting me do that. I'm trying to use the API documentation and digest authentication to accomplish this, but all I've been able to do is change the LED, and when I run the curl command through the API interface, it returns a 405 Method Not Allowed. Is it even possible to modify extruder temperature during a print? In other news, the forum has really garbled your python code posted here, removing a lot of the end of lines. I'm trying to repair them, but since Python is an indent-based language, it is quickly becoming hectic and error-prone. Do you have your class library and example in an easier format that retains the EOLs? api = Ultimaker3("10.180.1.209", "Test script")api.loadAuth("auth.data") # Get all the system data system = api.get("api/v1/system").json()print(system["name"]) # Change the system name result = api.put("api/v1/system/name", data="MyUltimaker3")print(result.json()) # Set the target hotend temperature to 100C, and then back to 0. print(api.get("api/v1/printer/heads/0/extruders/0/hotend/temperature").json())result = api.put("api/v1/printer/heads/0/extruders/0/hotend/temperature/target", data=100.0).json()print(api.get("api/v1/printer/heads/0/extruders/0/hotend/temperature").json())result = api.put("api/v1/printer/heads/0/extruders/0/hotend/temperature/target", data=0.0).json()print(api.get("api/v1/printer/heads/0/extruders/0/hotend/temperature").json()) # Change the LEDs api.put("api/v1/printer/led", data={"brightness": 50.0, "saturation": 20.0, "hue": 100.0}) # Start a print job. result = api.post("api/v1/print_job", files={"file": ("UM3_Box_20x20x10.gcode", open("UM3_Box_20x20x10.gcode", "rb"))})print(result.content) # Pause the print api.put("api/v1/print_job/state", data={"target": "pause"}) # Resume the print api.put("api/v1/print_job/state", data={"target": "print"}) # Abort the print api.put("api/v1/print_job/state", data={"target": "abort"}) ## This program is free software: you can redistribute it and/or modify# it under the terms of the GNU Affero General Public License as# published by the Free Software Foundation, either version 3 of the# License, or (at your option) any later version.# # This program is distributed in the hope that it will be useful,# but WITHOUT ANY WARRANTY; without even the implied warranty of# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the# GNU Affero General Public License for more details.# # You should have received a copy of the GNU Affero General Public License# along with this program. If not, see . import requests import json import os import time # Ultimaker 3 API access class. # Allows for access of the Ultimaker 3 API with authentication. # Uses the python requests library to do the actual http requests, which does most of the work for us. At the end there is where the EOLs become more difficult to repair. Many thanks, Sean