@engikeneer

Option 1 - assuming you're using one of the relay modules, wire the supply and control lines on the relay module to 5V, then wire the ground pin to PS_ON. This is how I do it on my Duet WiFi.

Thanks! That sounds like a plan! And PS_ON can handle being a ground?

On the neopixel header, I don't have D3 Mini, but believe you can take the neopixel supply from the Duet board if you are using an external 5v supply to power the board (the internal 5v regulator isn't powerful enough)

It's confusing because the Neopixel header has a "5v in" pin and not a "5v supply pin" like I would imagine. So I just assumed you run 5v to the LEDs from the PSU. But then what the heck is the second 5V_EXT_IN pin for? I don't think you power them from the board because I don't even see a 5v out pin that isn't attached to something else. There isn't really any documentation as far as I could find. If I had to guess I would say the second 5V_EXT_IN pin that's on the Neopixel header just goes unused but I have no way of confirming that right now. The only way it really makes sense in my head I guess is if that pin was really supposed to be 5v out and not in.

Update

I found the documentation! It wasn't linked from the other documentation so I had to search for it. Here is what it says:

Connect the LED strips to the 3-pin connector labelled NP_LED.

Connect the GND pin of the LED strip to the GND pin on the Duet NP_LED connector.
Connect the +5V pin of the LED strip either to the EXT_5V_IN pin of the NP_LED connector, or to an external +5V power supply.
Connect the data input line of the LED strip to the NEOPIXEL_DO pin of the Duet.
You will need to supply external 5V power to the adjacent 5V_IN connector, unless you connected the 5V line of your LED strip directly to an external 5V supply. The 5V regulator on the Duet 3 Mini is rated at 1A total and cannot be used to power LED strips.

The maximum supported number of Neopixel LEDs in a strip is 60.

So that pin can also put out 5v from the other 5v input. I guess the pin name is just confusing.

@JoergS5
I have the config file broken up into a bunch of M98 calls to keep things organized but it makes it a little hard to post.

All of the up-to-date config files can be found on my GitHub repo.

If it makes it easier I also wrote a python script to condense it all into a single file so let me know if you'd like me to post that.

---

@deckingman
I Just tried that and no change.

I'm at my wits end...

My Toolboard 1LC that I've had for a while and has worked through multiple rewires will not connect after rewiring the printer. It blinks rapidly indicating no CAN connection; CAN timeout error in console; Toolboard reset gives 4 blinks (no connection).

After trying pretty much everything I'm reaching out here. I have programming and PCB design experience so I know (for the most part) what I'm doing and I've been able to rule out some things.

As far as I can tell (see below) the CAN cable is electrically connected. The only things I can think of is either there's a decoupling cap or maybe inductor or something that was blown/shorted or I'm missing something really stupid. I haven't had the patience to go through each board probing components.

Please help!
Thanks in advance!

~ Neil

Thing I've tried

• M115 B121
• Firmware upgrade
  • to latest beta
• Firmware downgrade
  • to v3.4.6
• Verified CAN_H to CAN_H connection and vice versa
• Alternate cable
  • Power & CAN - self crimped - 110Ω termination.
• Alternate short cable
  • Power & CAN - self crimped - 110Ω termination.
• Toolboard double button reset
• PCB inspection
  • No visible flaws on either boards.
  • Fuses & crystals seem OK
• Multimeter testing
  • Continuity & resistance
  • Tested cable as well as at the connector header solder joints (only on the Toolboard end since I didn't feel like unmounting the mainboard yet).

Specs & Diagnostics

Printer:

• RatRig V-Core 3.1

Hardware:

• Duet 3 Mini 5+ - V1.0
• Duet 3 Toolboard 1LC - V1.0

M122:

Note: Motors not hooked up to mainboard and nothing hooked up to Toolboard.

=== Diagnostics ===
RepRapFirmware for Duet 3 Mini 5+ version 3.5.0-beta.4 (2023-06-08 23:40:14) running on Duet 3 Mini5plus WiFi (SBC mode)
Board ID: 524WM-Y296U-D65J0-40KM8-MB03Z-HJSAK
Used output buffers: 1 of 40 (17 max)
Error in macro line 6 while starting up: M569: Response timeout: CAN addr 121, req type 6018, RID=0
=== RTOS ===
Static ram: 102996
Dynamic ram: 109084 of which 24 recycled
Never used RAM 27096, free system stack 208 words
Tasks: SBC(2,ready,1.5%,381) HEAT(3,nWait,0.0%,331) Move(4,nWait,0.0%,358) CanReceiv(6,nWait,0.0%,939) CanSender(5,nWait,0.0%,337) CanClock(7,delaying,0.0%,342) TMC(4,nWait,1.2%,116) MAIN(2,running,94.9%,792) IDLE(0,ready,1.6%,29) AIN(4,delaying,0.8%,266), total 100.0%
Owned mutexes: HTTP(MAIN)
=== Platform ===
Last reset 00:22:33 ago, cause: software
Last software reset at 2023-08-06 02:00, reason: User, Expansion spinning, available RAM 28924, slot 2
Software reset code 0x6012 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00487000 BFAR 0xe000ed38 SP 0x00000000 Task SBC Freestk 0 n/a
Error status: 0x00
MCU revision 3, ADC conversions started 1354002, completed 1354000, timed out 0, errs 0
MCU temperature: min 28.8, current 29.5, max 30.8
Supply voltage: min 24.0, current 24.1, max 24.1, under voltage events: 0, over voltage events: 0, power good: yes
Heap OK, handles allocated/used 99/28, heap memory allocated/used/recyclable 2048/1044/500, gc cycles 0
Events: 0 queued, 0 completed
Driver 0: standstill, SG min 0, read errors 0, write errors 1, ifcnt 42, reads 57525, writes 10, timeouts 0, DMA errors 0, CC errors 0
Driver 1: standstill, SG min 0, read errors 0, write errors 1, ifcnt 58, reads 57520, writes 14, timeouts 0, DMA errors 0, CC errors 0
Driver 2: standstill, SG min 0, read errors 0, write errors 1, ifcnt 58, reads 57520, writes 14, timeouts 0, DMA errors 0, CC errors 0
Driver 3: standstill, SG min 0, read errors 0, write errors 1, ifcnt 58, reads 57520, writes 14, timeouts 0, DMA errors 0, CC errors 0
Driver 4: standstill, SG min 0, read errors 0, write errors 1, ifcnt 58, reads 57520, writes 14, timeouts 0, DMA errors 0, CC errors 0
Driver 5: standstill, SG min 0, read errors 0, write errors 1, ifcnt 58, reads 57520, writes 14, timeouts 0, DMA errors 0, CC errors 0
Driver 6: standstill, SG min 0, read errors 0, write errors 1, ifcnt 42, reads 57524, writes 10, timeouts 0, DMA errors 0, CC errors 0
Date/time: 2023-08-09 23:13:56
Cache data hit count 2827400447
Slowest loop: 3.84ms; fastest: 0.12ms
=== Storage ===
Free file entries: 20
SD card 0 not detected, interface speed: 0.0MBytes/sec
SD card longest read time 0.0ms, write time 0.0ms, max retries 0
=== Move ===
DMs created 83, segments created 0, maxWait 0ms, bed compensation in use: none, height map offset 0.000, ebfmin 0.00, ebfmax 0.00
no step interrupt scheduled
=== DDARing 0 ===
Scheduled moves 0, completed 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== DDARing 1 ===
Scheduled moves 0, completed 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== Heat ===
Bed heaters 0 -1 -1 -1, chamber heaters -1 -1 -1 -1, ordering errs 0
=== GCodes ===
Movement locks held by null, null
HTTP* is doing "M122" in state(s) 0
Telnet is idle in state(s) 0
File is idle in state(s) 0
USB is idle in state(s) 0
Aux is idle in state(s) 0
Trigger* is idle in state(s) 0
Queue is idle in state(s) 0
LCD is idle in state(s) 0
SBC is idle in state(s) 0
Daemon is idle in state(s) 0
Aux2 is idle in state(s) 0
Autopause is idle in state(s) 0
File2 is idle in state(s) 0
Queue2 is idle in state(s) 0
Q0 segments left 0, axes/extruders owned 0x0000803
Code queue 0 is empty
Q1 segments left 0, axes/extruders owned 0x0000000
Code queue 1 is empty
=== CAN ===
Messages queued 12108, received 0, lost 0, boc 0
Longest wait 0ms for reply type 0, peak Tx sync delay 0, free buffers 18 (min 17), ts 6770/0/0
Tx timeouts 0,0,6769,16,0,5320 last cancelled message type 4514 dest 127
=== SBC interface ===
Transfer state: 5, failed transfers: 0, checksum errors: 0
RX/TX seq numbers: 57485/57485
SPI underruns 0, overruns 0
State: 5, disconnects: 0, timeouts: 0 total, 0 by SBC, IAP RAM available 0x0d484
Buffer RX/TX: 0/0-0, open files: 0
=== Duet Control Server ===
Duet Control Server version 3.5.0-beta.4 (2023-06-09 10:49:49)
Code buffer space: 4096
Configured SPI speed: 8000000Hz, TfrRdy pin glitches: 0
Full transfers per second: 42.59, max time between full transfers: 4967.0ms, max pin wait times: 2358.8ms/17.3ms
Codes per second: 0.19
Maximum length of RX/TX data transfers: 4431/804

@t3p3tony I found it finally!

What I was looking for was:

con.perform_command(evaluate_expression(CodeChannel.SBC, expression)) 

based on dsf.commands.basecommands.evaluate_expression. Since RRF expressions aren't automatically resolved as they are intercepted you have to do it yourself.

It just wasn't immediately clear.

Using dsf-python is there a way to resolve expressions passed to codes that are intercepted?

I was expecting a method like resolve_expression() but I didn't see anything like that.

@dc42 As always, thanks for your help!

@dc42 can I just tie it to 24V- on the supply side or would it have to be something like the frame?

Hello!

I'm currently wiring up my new RatRig VC3 and I bought a shielded 24 AWG 4 conductor TPU cable for the Toolboard 1LC on the printhead.

My question is:

Where should I terminate the drain wire?

I'm using a 4-pin Molex Nano-Fit connector at both ends of the cable. Would it be sufficient to connect the drain to the 24V ground that heads to the Toolboard (ie just on the printer end)? Or both sides? Frame? Connecting to the cable V- would be ideal since the cable would still be detachable.

I don't have a lot of experience with shielding and EMI so the help is appreciated.

Thanks for your help in advance!

Specs:
Cable
Connector

I have the exact same problem and for the life of me I can't figure it out.

I'm running a Duet 3 Mini 5+ in SBC mode. Also have the BLTouch connected to a Toolboard 1LC.

I've checked the wiring and everything and it all seems fine. Diving faster seems to help a little bit but doesn't solve the problem.

From what I can tell it's the combination of 2 factors that causes the problem to happen:

1. The BLTouch will go into error mode of it sits triggered for too long. Something like more than 750ms or around there. As far as I can tell this behaviour is intended.

2. At least with my setup, when probing and the BLTouch is triggered there seems to be a random amount of time before the printer reacts to the trigger. Sometimes it's almost right away and sometimes it's a little bit of a pause.

When the printer pauses long enough after a probe trigger, the delay causes the probe to go into error mode.

I don't have any idea how to fix it but this is at least my working theory so far. It's possible it may have something to do with SBC mode. Our printers both have that in common. Maybe the presence of the SBC/Pi introduces a slight delay in between commands and/or reactions.

@dc42 should be able to tell us if a delay does exist in SBC mode and if, per my theory, that could pose a problem for the BLTouch in some specific setups.

Do you have any pics of the implementation or is this purely theoretical?

A description of how it works for those of us whom are less adept at reading schematics would also be helpful.

P.S.
I don't think your ZIP upload worked. Maybe use GitHub?

@sheski3

I wired a CR-10s Pro V2 with dual Z steppers the way @dc42 mentioned and it works great! I also took off the z-sync belt and just align the gantry with G31.

This link might help:
https://duet3d.dozuki.com/Wiki/Bed_levelling_using_multiple_independent_Z_motors