"M409" errors and other strange behaviour.

Exerqtor

I've been getting some strange "M409" and "M4" errors on my PanelDue "V3 & 3.4.0-pre1" , and some times the BLTouch (original V3.0) probe drops mid print and gets bent leading it's own set of issues. And then other times the tool gets unselected / set to standby without any apparent reason resulting in the print going on without anything etting extruded (ofc followed with a plethora of "Cannnot extrude filament without a tool selected" errors. And when i check the console in DWC before the extrusion errors start i can see that the text info texts i've added for tool / filament unloaded has been ran. Just like i've manually set the tool to standby with DWC or on the panel due. The board is a 1.03 with 3.4.0beta3 firmware, and only one tool.

And if i try to re-run the failed print with the same Gcode it some times works (still throwing the M409 etc faults), and finish the print without turning of the tool.

Help? lol

EDIT: Just to specify, if i search the gcode it's no "M409", "M4" or "T-1" commands anywhere (also no rouge "M98 P"deployprobe.g" commands either)

dc42

@exerqtor this sort of thing can happen when the PanelDue cable picks up severe interference, for example because it runs next to a stepper motor cable.

Exerqtor

@dc42 Yeah I've read something about that earlier, so i shortened the cable down too 20cm(ish), re-cripmed both ends laid it all by itself. Still didn't help.

I unplugged the PanelDue and I'm running the same job again. And it's allready gotten past the point of failure of the last try.

But can the mentioned interferance also cause the issues with deselecting tool and deploying the bltouch?

dc42

@exerqtor it's difficult to predict what effect corrupted commands received on the PanelDue port might have.

There is a checksum used to provide some degree protection against corruption of data sent by PanelDue to the Duet. But I've just found out that this doesn't work in recent (3.2 and 3.3) versions of RRF. It will be corrected in RRF 3.4beta4 which we hope to release later this week.

Aside from stepper motor cables running next to the PanelDue wires causing interference, another possible cause of corrupted commands is that the wires connecting the PanelDue to the Duet are long and thin. We specify that the resistance of the PanelDue cable must not exceed 0.1 ohms per conductor.

Exerqtor

@dc42 Yeah that might explain it, i've gotten checksum errors before but everything's been working as intended.
I'll invest in a shielded 4 core 0,2mm2 wire or something for when i do the next major upgrade.

Everything worked like a charm with the PanelDue disconnected so.