jonwienke
jonwienke
There appears to be one minor bug in your script results, a duplicate Z move: G0 F15000 X10.32 Y-51.817 **Z1.45** G0 X9.008 Y-51.269 ;TYPE:PRIME-TOWER M135 T0 G92 E0 M104 S250...
Gotcha. I'm waiting on a print to finish, but once it's done I'll test your script and let you know how it goes.
OK, there is some kind of glitch in the first layer. The first nozzle change is supposed to happen BEFORE the prime tower is printed. T0 (orange) prints the innermost...
Below is a photo of the print before I aborted it. You can see the black infill is not centered within the tan outer walls of the top center model,...
I think I have a solution to the bug, but I'm not a Python programmer so I don't know how to write it with the correct syntax. if self.getSettingValueByKey("move_tool_changes"): for...
OK, I made a smaller test file and let it run, and discovered that EVERY relocated extruder change is screwing up. Travel happens normally going to and from the Prime...
I've checked all the mechanical stuff and it's fine. The issue is that the normal speed, acceleration, and jerk limits that are applied everywhere else are totally ignored during the...
The nozzle switch XY offsets are parameters set in the printer that the M135 macro checks when it runs. THey aren't in the gcode or x3g file. When I calibrated...
So it gets even weirder. I set up Octoprint on an extra Pi I had, configured the GPX plugin, sent it my test gcode...and got the EXACT SAME RESULTS. With...
T0 and T1 work as solo commands, at least from Octoprint's console.