Firmware 2.03 (Duet 2) and 1.24 (Duet 06/085) released
-
Another "maybe" bug.
I have duet 3d wifi on a delta printer, with the new function "M665 L260.0:260.0:260.0" to give the firmware the diagonal rod offsets, if I leave them the same as in the example everything works fine, now, if I change the values after calibrating with the hexagon I get (and thats what I got when I was running Marlin) L267.3:267.1:266.9, a 0.2mm difference between the rod pairs, my printer misses steps while homing (the second bump, but not in the first one) and misses steps while calibrating and printing.
I, then, proceed to experiment, the greater the difference, the more steps it misses.
So I'm now back to the L267.1 (the mean of the tree pairs) until this is fixed, it happens too to others in my printing community.Here I provide you my homedelta, config override and config in case you want to check them out.
2_1561532460509_homedelta.g 1_1561532460509_config-override.g 0_1561532460509_config.g
-
Thanks for your report - I've added it to my list to investigate.
The recommended way to handle scaling errors is not to adjust the rod lengths but to use M579.
-
Two things I've seen so far.
M280 to turn a servo in a macro sometimes doesn't run until the end of the macro, after any other moves etc. Putting M400's before/after fixes it. (It's not every macro that's affected, some run as expected, others don't turn the servo until the end, no rhyme or reason I can spot)
M116 behavior changed slightly, still looking at this. Probably only affects testing, but I'm not sure. Previously if no temp was set I could switch through tools and the M116 did nothing. Now it stalls and waits on something. I tried setting the temp to 30c on each tool. It does bring the temp up to 30c but never proceeds. I may need to set a standby temp for each tool and retest, still looking into it. Commenting out the M116 lets the swaps proceed as normal.
One other thing that may be as intended, but surprised me. I thought having a minima for Z set to -0.1 wouldn't affect anything other than letting me move down "into the bed" past Z=0. I homed X/Y/Z, then did a mesh probe and the mesh showed entirely "under the bed". Changing the minima to Z0 resolved that. It's likely I just misunderstood this functionality, but figured I'd note it. (the documentation seems to indicate this is expected behavior)
-
@kraegar said in Firmware 2.03 (Duet 2) and 1.24 (Duet 06/085) released:
M280 to turn a servo in a macro sometimes doesn't run until the end of the macro, after any other moves etc. Putting M400's before/after fixes it. (It's not every macro that's affected, some run as expected, others don't turn the servo until the end, no rhyme or reason I can spot)
Can you construct a macro that reproduces this reliably?
M116 behavior changed slightly, still looking at this. Probably only affects testing, but I'm not sure. Previously if no temp was set I could switch through tools and the M116 did nothing. Now it stalls and waits on something.
There has been no intentional change to M116. Can you reproduce it, preferably in a standalone macro?
One other thing that may be as intended, but surprised me. I thought having a minima for Z set to -0.1 wouldn't affect anything other than letting me move down "into the bed" past Z=0. I homed X/Y/Z, then did a mesh probe and the mesh showed entirely "under the bed". Changing the minima to Z0 resolved that. It's likely I just misunderstood this functionality, but figured I'd note it. (the documentation seems to indicate this is expected behavior)
No, it's not intentional behaviour. The only way that the M208 Zmin setting should affect the Z=0 position is if you use a Zmin homing switch, and after the G1 H1 Z-nnn move in homez.g you don't have a G92 Z command to set the actual Z position.
-
The method for my testing is simply a macro that loops through tool changes, "Test Tools Pickup".
So it loops through each tool in order. I'm not going to cover them all, but here's the summary so far:
The first issue hit is with M280 in tfree0.g (tpost0.g completes with no issue with either M116 or M280, weirdly). If I wrap M400's around the M280, tfree0.g completes fine.
The next issue happens during tpost1.g where it stalls out on the M116 line. I tried setting all of the active & standby temps to 30c before testing, and it still hangs on the M116 on tool 1.The macros in question are here (quickly cleaned up for readability):
https://www.dropbox.com/sh/oo610lsff1g3n85/AAA6O112JlaB--WkmdfMJla8a?dl=0Here are screenshots of the difference between M208 Z-0.2 vs. M208 Z0 for Zmin. No other changes. Steps to reproduce:
Home X/Y, Home Z using a microswitch on the X carriage. Run G29. -
This post is deleted! -
Another one. Not sure if it's any gcode, or just this file. 4 tool print. First 3 go fine. 4th tool it picks up, runs the cleaning routing, then goes to print, and the Z height drops to -3.30mm.
Here's the section of gcode:
G1 E24.67887 F2400.00000
G92 E0
G1 Z0.600 F7800.000
G91
G1 Z5 E-2 F1800
G90
T3
G92 E0
G1 E-2.00000 F2400.00000
G92 E0
G1 X150.900 Y99.100 F7800.000
G1 Z0.350
G1 E2.00000 F2400.00000
G1 F1800
G1 X150.900 Y85.900 E2.66248Since it's setting the working height to 0.350 in the gcode, I can't for the life of me figure why it's diving to -3.30mm. If it were an offset issue, it would display it was at the correct Z of 0.350
Dropping to 2.02 resolved this issue. (Though in 2.02 it's not running T0 to grab that tool at the start of my print, need to figure that out next I guess since I know others are on 2.02)
I can post my offset files and tool change scripts if that helps.
-
@kraegar, please post your config.g and tool change files. Did you read the bit in the upgrade notes about tool offsets being applied by default in the tfree and tpost files in 2.03, when they were not in 2.02?
-
Yes, I saw that bit. I'm using the offsetson.g / offsetsoff.g work around, regardless.
It's working fine for the other tools, and I'm not seeing any reason it would cause the active Z height to display as -3.30.
The config files + gcode file are all here, should be everything relevant: https://www.dropbox.com/sh/7z7txheqdhdvcjc/AADQY-h_WdGFe1kDW3i2lrYYa?dl=0
Dropping to 2.02 did fix the odd behavior with tool 3's printing at -3.30mm. (It's not coincidence that's the correct Z height of 0.35 minus the offset for the tool, I just can't see a reason it would happen)
-
@kraegar said in Firmware 2.03 (Duet 2) and 1.24 (Duet 06/085) released:
Yes, I saw that bit. I'm using the offsetson.g / offsetsoff.g work around, regardless.
It's working fine for the other tools, and I'm not seeing any reason it would cause the active Z height to display as -3.30.
The config files + gcode file are all here, should be everything relevant: https://www.dropbox.com/sh/7z7txheqdhdvcjc/AADQY-h_WdGFe1kDW3i2lrYYa?dl=0
Dropping to 2.02 did fix the odd behavior with tool 3's printing at -3.30mm. (It's not coincidence that's the correct Z height of 0.35 minus the offset for the tool, I just can't see a reason it would happen)
Firmware 2.04RC1 is available now. I suggest you try that, and if you think there is still a problem, start a new thread.
-
Upgrade from 1.22.6 to 1.24 has left the machine invisible on the browser on the .local address but visible on the IP address.
See: https://forum.duet3d.com/topic/11425/upgrade-from-1-22-6-to-1-24-has-goosed-local-addressing/7
