@droftarts
Found it, it was a wobbly CAN bus connection off the mini5+. I wound a new set of wires and replaced the CAN circuit with a new cabling. Thanks.

Heh, yes, it is working as expected. I did a full reload of everything and now everything is working.

I do like the resident bootloader (permanent) that resides in the Mini5+, reminds me of a project that I did 15 years ago. Nice work!

73 TomW

@droftarts
Found it, it was a wobbly CAN bus connection off the mini5+. I wound a new set of wires and replaced the CAN circuit with a new cabling. Thanks.

@dc42 I looked at CAN many years ago and thought it was overkill for work at the time. Nice, continous stream coverstation between toolboard & host, anytime someone blinks... heh

@droftarts
Hmm, yeah, I've been putting this off. I was deep into another project when I got the duet toolboard installed. Haha, the wiring is a bit "edgy", time to redo it.

If you know anything about the firmware interactions between the toolboard and the duet mini; How does the tool board signal back that the sensor (probe) has been seen? Is that a CAN packet / exchange?

Yes, the ghost is back inside my Duet 3 mini-5+, with RPi-5 nvme, and RatRig Vcore3 400, BL Touch probe. Firmware on both mini-5+ and toolboard are v3.5.3.
I've watched it do it, watched it carefully. Running a G29 bed mesh, I can see it:

1. move to new position.
2. Probe twice
3. hesitate (shudder?)
4. Lights inside the Probe blink
5. DWC declares "Error: M280: Probe already triggered before probing move started"

Okay, wtf just happened? Something balked at movement or the motion shuddered or stumbled?

I've torn down the hotend and re-torqued screws, no damaged parts. New belts and all pulleys have been recently replaced. Frame nuts re-torqued..

Why did the probe behave that way, or did it? Is this a software / trigger edge / debounce signal problem? Or did the probe somehow fault (blink) while indicating a failure. Or did the RepRap software tell the probe to blink like crazy?

Who's on Second?

What happened?

@Notepad All new wiring on the 1LC to BL Touch circuit (new connector ends, etc.). I even tried moving the probe back on to the mainboard:

M558 P5 C"!io2.in" H6 F240 T6000 A5 S0.03 

No, I did not attempt the R-delay on the mainboard. This had been an original setup for me, io2, until I got the 1LC toolboards. I was reaching the point of getting out my pocket scope and look at the supply line noise. BTDT

I'm happy that the error went away, suddenly. The only other time I've seen this was while working at a company next to a laser crystal manufacture (read: elecric furnaces). End of the month, our development computers, mysterously, stopped working (no bootup). Doh! Took us a while to figure that out.

@gloomyandy This has been a working setup for a couple of years. I was running 3.4.3 (I don't think that I'd still was using the -rc candidate). All was well, installed the toolboard 1LC and that was working well.

Now I'm gob-smacked (as the Brits say), it stopped doing the error and I cannot force the error! This is where I've narrowed the problem down to:

M558 P9 C"20.io0.in" H5 F300 T6000 A5 R0.3 S0.02

I did not assign the "R" delay with v3.4.3, the bl touch probe worked flawlessly. Only since I had upgraded the Duet 3 Mini 5+ software that this slowly appeared more frequently (as in 1 in 20 probes of the mesh), completely at random. Sometimes it was the first probe for home (G28).

After reading the net, I added the R parameter, slowed my probe speed down, and IT DID NOT WORK. I played and played, probably a few powerups, and suddenly the M280 error went away. It's gone!

All is working and tested with a few hundred bed probes. Go figure, I ask for help and a few minutes later the problem disappears?

This has been happening for a month or so. I finally decided that a maintainence teardown was needed: disassemble linear bearings, lubricate all, replace wiring cables, etc.. I also replaced many parts of the hotend assembly.

This is a RatRig Vcore3 400mm, Duet 3 mini 5+, toolboard 1LC, raspberry pi 5 w/NVME bootup, versions are all at 3.5.3, raspberry is 12 (bookworm).

I've tried a new toolboard, a new touch probe, replaced wiring, checked connectors (pulled on/off several times to wipe), switch probe wiring from toolboard to mainboard io2. Nothing, nada, zip.

I cannot get rid of this intermitent error. BTW, yes, I played with the hex adjustment.

Please help, this has been a good machine until lately.

Heh, yes, it is working as expected. I did a full reload of everything and now everything is working.

I do like the resident bootloader (permanent) that resides in the Mini5+, reminds me of a project that I did 15 years ago. Nice work!

73 TomW

nm, I borked the duet3 binary, lost contact with the mini5+, looks like I'll have to a fresh installation.. <sigh>

@jay_s_uk

It appears that there was no change.

10/25/2023, 1:06:53 PM	m115 b20
Duet TOOL1LC rev 1.1 or later firmware version 3.4.6 (2023-07-21 14:17:33)
10/25/2023, 1:06:22 PM	m997 b20
Board 20 starting firmware update
10/25/2023, 1:02:12 PM	m115 b20
Duet TOOL1LC rev 1.1 or later firmware version 3.4.6 (2023-07-21 14:17:33)

I was confused by the instructions here to upload a toolchain file, see section: "Updating the firmware"? I did download a Duet3Firmware_TOOL1LC.bin, and placed it into ./opt/dsf/sd/firmware/

Then I puzzled my way through: Updating the bootloader on Duet 3 expansion and tool boards.

Maybe I should wipe everything and start over?