Closed AndyEveritt closed 4 months ago
I've been trying to reproduce this on my toolchanger running with 2 1LC toolboards but using an stm32H743 mainboard. All boards running the latest 3.5 build as of yesterday (27/3/2024). I ran the test file (without filament) up to about the 20% point which involved 10 tool changes. During that process I did not see any CAN-FD problems. I had to delete the startup code as it did not match my setup. I had the active temperature of both tools set to 220 and the standby temperature set to 210 for the first 4 tool changes, so there was a short delay each time while the tool came up to temperature. After that I modified the standby temperature to be 220 so there was no delay for the final 6 tool changes. I did not run a G29 probe sequence but loaded an existing mesh. I've now tried this a couple of times with the same results.
Not sure why I did not see the problem, happy to try other things if anyone has any suggestions.
For completeness my toolchanger has 4 tools tool 0 is connected directly to the mainboard, tool 1 uses a Fly RRF36 toolboard, tools 2 and 2 use !LC toolboards. I also have a prototype Fly SHT32 toolboard as part of the toolhead that is used to control the tool locking mechanism and a SZP type probe. So four CAN-FD toolboards in total.
A couple of notes the test file temperature settings look a little odd as they set active and standby temps for tools 0 and 1, but the print uses tools 2 and 3.
Edited to add: I checked the M122 output of all three boards after running the above test, no CAN errors reported by any of the boards.
M568 P0 S200 R180 A1
M568 P1 S200 R180 A1
var delay = 5
while iterations < 10
T0
G4 S{var.delay}
G1 X105 Y105 E5 F2000
G4 S{var.delay}
G1 X100 Y100 E5 F2000
G4 S{var.delay}
G1 X105 Y105 E5 F2000
T1
G4 S{var.delay}
G1 X105 Y105 E5 F2000
G4 S{var.delay}
G1 X100 Y100 E5 F2000
G4 S{var.delay}
G1 X105 Y105 E5 F2000
echo "Test finished"
This test script causes the issue.
However removing the XY movements stops the issue from occurring:
M568 P0 S200 R180 A1
M568 P1 S200 R180 A1
var delay = 5
while iterations < 10
T0
G4 S{var.delay}
G1 E5 F1414
G4 S{var.delay}
G1 E5 F1414
G4 S{var.delay}
G1 E5 F1414
T1
G4 S{var.delay}
G1 E5 F1414
G4 S{var.delay}
G1 E5 F1414
G4 S{var.delay}
G1 E5 F1414
echo "Test finished"
Issue does NOT occur if the extrude moves are removed from the print file (still extrudes in the tpost/tfree scripts) and the XY moves are added back:
M568 P0 S200 R180 A1
M568 P1 S200 R180 A1
var delay = 5
while iterations < 10
T0
G4 S{var.delay}
G1 X105 Y105 F2000
G4 S{var.delay}
G1 X100 Y100 F2000
G4 S{var.delay}
G1 X105 Y105 F2000
T1
G4 S{var.delay}
G1 X105 Y105 F2000
G4 S{var.delay}
G1 X100 Y100 F2000
G4 S{var.delay}
G1 X105 Y105 F2000
echo "Test finished"
Issue does not occur in 3.4.6-rc1 but does occur in 3.5.0 (tested rc2, rc3, rc4)
Issue occurs when removing the delays
M568 P0 S200 R180 A1
M568 P1 S200 R180 A1
while iterations < 10
T0
G1 X105 Y105 E5 F2000
G1 X100 Y100 E5 F2000
G1 X105 Y105 E5 F2000
T1
G1 X105 Y105 E5 F2000
G1 X100 Y100 E5 F2000
G1 X105 Y105 E5 F2000
echo "Test finished"
Fixed in 3.5.0-rc.4. Problem was that when filament monitors were returning live data they were sending it too frequently.
Duet Forum Discussion Thread
NA
Which Duet products are you using?
Firmware Version
3.5.0-rc3+8
Duet Web Control Version
3.5.0-rc3+8
Are you using a Single Board Computer (RaspberryPi) with your Duet?
Please upload the results of sending M122 in the gcode console.
Please upload the content of your config.g file.
Please upload the content of any other releveant macro files.
No response
Details specific to your printer.
E3D Toolchanger
Links to additional info.
No response
What happened?
Setting the temperature is an example of a command to a TB that fails due to this issue.