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
CR10 (well modified), RR V-Core 3 400mm
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
@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>
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?
@jay_s_uk said in Toolboard 1LC: some things work other won't:
@TomW what firmware version are you running on the mainboard?
What's your wiring like between the two?
TIA
The Duet3 Mini5+ has an SBC (RPi3 running Raspbian GNU/Linux 10 (buster)).
Duet3 is:
10/25/2023, 12:12:35 PM m115
FIRMWARE_NAME: RepRapFirmware for Duet 3 Mini 5+ FIRMWARE_VERSION: 3.5.0-rc.1 ELECTRONICS: Duet 3 Mini5plus WiFi FIRMWARE_DATE: 2023-08-31 16:16:56
and Toolboard:
10/25/2023, 12:13:24 PM m115 b20
Duet TOOL1LC rev 1.1 or later firmware version 3.4.6 (2023-07-21 14:17:33)
Toolboard wiring is 18ga onto 24v supply over a 1.5 meter length. The CAN bus is wired using 22AWG pair that I've twisted about 1 turn per inch.
This may be helpful?
10/25/2023, 12:18:17 PM m122 b20
Diagnostics for board 20:
Duet TOOL1LC rev 1.1 or later firmware version 3.4.6 (2023-07-21 14:17:33)
Bootloader ID: SAMC21 bootloader version 2.8 (2023-07-25)
All averaging filters OK
Never used RAM 2596, free system stack 88 words
Tasks: Move(notifyWait,0.1%,155) HEAT(notifyWait,29.3%,95) CanAsync(notifyWait,0.0%,65) CanRecv(notifyWait,0.8%,76) CanClock(notifyWait,1.2%,65) ACCEL(notifyWait,0.0%,61) TMC(delaying,210.1%,57) MAIN(running,143.0%,351) IDLE(ready,0.0%,26) AIN(delaying,341.1%,142), total 725.6%
Last reset 17:45:08 ago, cause: software
Last software reset data not available
Driver 0: pos 0, 657.7 steps/mm,standstill, SG min 0, read errors 0, write errors 1, ifcnt 38, reads 38029, writes 14, timeouts 5, DMA errors 0, CC errors 0, failedOp 0x6f, steps req 0 done 0
Moves scheduled 0, completed 0, in progress 0, hiccups 0, step errors 0, maxPrep 0, maxOverdue 0, maxInc 0, mcErrs 0, gcmErrs 0
Peak sync jitter -5/11, peak Rx sync delay 219, resyncs 0/0, no step interrupt scheduled
VIN voltage: min 24.2, current 24.2, max 24.2
MCU temperature: min 31.9C, current 34.2C, max 36.3C
Last sensors broadcast 0x00000002 found 1 241 ticks ago, 0 ordering errs, loop time 1
CAN messages queued 1278079, send timeouts 0, received 575145, lost 0, free buffers 37, min 37, error reg 110000
dup 0, oos 0/0/0/0, bm 0, wbm 0, rxMotionDelay 0
Accelerometer: LIS3DH, status: 00
I2C bus errors 0, naks 3, other errors 0
I have run an M303 against the toolboard, with expected results. I can control fans, pin-test-cycle the BLT pin (M280 P"20.io0.out" S120 I1) and it does the 10cycle pin-drop okay. What doesn't work is inputs of any kind, endstop or BLT.
<sigh> Nice board..
I have some problems commissioning the board though. I can get fans and the hotend working properly, but the stepper motor remains de-energized and the endstops don't work, but first the details: v1.3 toolboard and duet3 mini5+.
M574 X1 S1 P"0.io1.in"
Works just fine:
10/24/2023, 4:20:14 PM m574
Endstop configuration:
X: low end switch connected to pin io1.in
Y: low end switch connected to pin io0.in
Z: low end Z probe
M574 X1 S1 P"121.io2.in"
will result in this error:
10/24/2023, 3:47:54 PM m574 x1 s1 p"121.io2.in"
Error: M574: Response timeout: CAN addr 121, req type 6057, RID=19
and then M119 reports no endstop found:
10/24/2023, 4:07:31 PM m119
Endstops - X: no endstop, Y: not stopped, Z: not stopped, Z probe: at min stop
and, is verified as such with:
10/24/2023, 4:13:14 PM m574
Endstop configuration:
X: none
Y: low end switch connected to pin io0.in
Z: low end Z probe```
And the toolboard is there... M122 B121
10/24/2023, 4:17:14 PM m122 b121
Diagnostics for board 121:
Duet TOOL1LC rev 1.1 or later firmware version 3.4.6 (2023-07-21 14:17:33)
Bootloader ID: SAMC21 bootloader version 2.8 (2023-07-25)
All averaging filters OK
Never used RAM 2596, free system stack 88 words
Tasks: Move(notifyWait,0.0%,155) HEAT(notifyWait,0.4%,111) CanAsync(notifyWait,0.0%,65) CanRecv(notifyWait,0.0%,76) CanClock(notifyWait,0.0%,65) ACCEL(notifyWait,0.0%,61) TMC(notifyWait,3.0%,57) MAIN(running,91.7%,351) IDLE(ready,0.0%,26) AIN(delaying,4.9%,142), total 100.0%
Last reset 00:04:18 ago, cause: software
Last software reset data not available
Driver 0: pos 0, 657.7 steps/mm,standstill, SG min 0, read errors 0, write errors 1, ifcnt 24, reads 63917, writes 14, timeouts 0, DMA errors 0, CC errors 0, steps req 0 done 0
Moves scheduled 0, completed 0, in progress 0, hiccups 0, step errors 0, maxPrep 0, maxOverdue 0, maxInc 0, mcErrs 0, gcmErrs 0
Peak sync jitter -3/10, peak Rx sync delay 214, resyncs 0/0, no step interrupt scheduled
VIN voltage: min 24.2, current 24.2, max 24.2
MCU temperature: min 37.5C, current 38.0C, max 38.0C
Last sensors broadcast 0x00000002 found 1 224 ticks ago, 0 ordering errs, loop time 1
CAN messages queued 5130, send timeouts 0, received 2328, lost 0, free buffers 37, min 37, error reg 110000
dup 0, oos 0/0/0/0, bm 0, wbm 0, rxMotionDelay 0
Accelerometer: LIS3DH, status: 00
I2C bus errors 0, naks 3, other errors 0de_text
Did I miss setting something, or a jumper?
TomW
@alankilian If you want to trigger those inputs, wire in a CMOS IC such as the 74LV14 inverting buffer. It runs from a +5v supply and will invert your signal, while safely driving the GPIO input on the MPU.
If you don't want the signal inverted, then cascade two gates, serially. Be sure that you tie any unused input pins (there are 6 of them) to either GND or the +5V (this keeps the gate from oscillating and burning itself out).
enjoy!
M600 is now properly processed within the gcode stream.
I write code and know how hard it is write for another audience. It is hard to write "down to" someone less familiar with the given task. Yes, it is confusing.