@T3P3Tony Thanks Tony, much appreciated!

Hello,

We are using the Duet 3 Mini 5+ Ethernet and need advice on the best connection mode to use with a Raspberry Pi 5. So far, we’ve identified three potential approaches:

Direct USB Mode

• Minimal components required.
• USB connection to the Duet.
• No SD card needed.
• G-code is sent to and executed on the Duet.

Standalone Mode

• Duet operates from an SD card.
• DuetWebControl available.
• Macros and configuration files are stored on the SD card.
• USB connection and G-code execution work similarly to Direct USB Mode.

SBC Mode

• Serial connection between the Pi and Duet.
• Some processing tasks are offloaded to the Raspberry Pi.
• Macros and configuration files are stored on the Pi.
• G-code execution is similar to other modes but requires selecting the serial port.

Questions and Considerations:
We have some restrictions, requirements, and open questions that need addressing:

• SD Card Reliability and Security
  Concern: SD cards could fail, potentially disabling the machine and requiring professional servicing (which we want to avoid).
  Security Concern: Someone might access the SD card, read stored information, or modify settings, which is unacceptable.
• Connection Reliability
  Which connection type (serial or USB) is more reliable for communication?
• SBC Mode and Raspberry Pi Performance
  We already run multiple tasks on the Raspberry Pi.
  How much computing power does SBC mode require? Could it overload the Pi?
• Error Handling and Machine Status Updates
  In SBC mode, the browser interface allows monitoring of machine status and receiving error notifications.
  Are these features (status updates, error notifications) still available in Direct USB Mode or Standalone Mode?
  Is there a way to receive error/machine status notifications proactively, or must we request updates through G-codes?
• Custom Machine Configuration in Direct USB Mode
  How are machine configuration settings saved?
  Is custom firmware compilation required in this mode?
• Ribbon Cable Pin Usage
  We need additional UART and SPI connections from the Raspberry Pi, but the standard ribbon cable blocks all GPIO pins.
  Which pins are used by the ribbon cable?
  Are other UART and SPI connections still available for use?
• Object Model Features
  Are any object model features missing when using Direct USB Mode?

Would you be able to answer our questions and make a suggestion, which mode of operation is most suitable?
Although it would be helpful to understand our whole setup, I can unfortunately not disclose much more information, as we are an industrial customer and information is confidential. We do have an NDA with Duet3d, but I could see on the website that technical support is only given in the forum. Would you be able to also provide individual technical support to us, perhaps in a TEAMS meeting?

Best Regards

@droftarts Thanks for the note and your help. That is good news for me.

I must have confused it, and used io1.out. Or, I only turned it on and off so far, so I might not have noticed the missing PWM. But I will also need the PWM functionality in the future.

Have a good day
Tobi

Hi!

I was wondering what the out_6_buff is on the mini 5+. Can I use this as a regular PWM output on out6? Is there a connection to the fan headers above it?
I would like to use it with the NLDD-1400H LED driver. Basically PWM-controlling that input. So far I used the io0.out for that, but I am running out of those and just need one more.

Cheers
Tobi

@droftarts Hi Ian, thanks for your reply.

So it is what I expected. A costly learning experience, but now I know to be extra careful with the connections. I will still be able to use it in standalone mode on another project, I just need to learn now how to set everything up without SBC.

Have a good day!
Tobias

@droftarts I put the ribbon cable on that way:

Once I realized the issue, I removed it and plugged it in the right way. I removed everything else from the duet, so nothing apart from power and ribbon cable is connected there right now:

The duet is mounted on standoffs, there is nothing behind it. The solder points look flawless and there is not metal pieces there:

Cheers
Tobi

@droftarts Thanks for your reply. The Board is in SBC mode and has no SD card inserted.
See response to M122:

SENDING:M122
=== Diagnostics ===
RepRapFirmware for Duet 3 Mini 5+ version 3.5.1 (2024-04-19 14:41:25) running on Duet 3 Mini5plus Ethernet (SBC mode)
Board ID: KPLT0-NT8LU-F65J0-409NA-KR03Z-Z9GFM
Used output buffers: 1 of 40 (1 max)
=== RTOS ===
Static ram: 103232
Dynamic ram: 103360 of which 12 recycled
Never used RAM 34812, free system stack 156 words
Tasks: SBC(2,nWait 7,0.0%,970) HEAT(3,nWait 6,0.0%,372) Move(4,nWait 6,0.0%,355) CanReceiv(6,nWait 1,0.0%,940) CanSender(5,nWait 7,0.0%,336) CanClock(7,delaying,0.0%,334) TMC(4,nWait 6,0.0%,122) MAIN(1,running,98.9%,856) IDLE(0,ready,0.3%,30) AIN(4,delaying,0.8%,265), total 100.0%
Owned mutexes: USB(MAIN)
=== Platform ===
Last reset 00:00:35 ago, cause: power up
Last software reset at 2024-05-02 15:04, reason: User, Gcodes spinning, available RAM 42120, slot 0
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00000000 BFAR 0xe000ed38 SP 0x00000000 Task SBC Freestk 0 n/a
Error status: 0x00
Error status: 0x00

MCU revision 3, ADC conversions started 35579, completed 35578, timed out 0, errs 0
MCU temperature: min 16.1, current 19.6, max 19.8
Supply voltage: min 0.3, current 0.8, max 0.8, under voltage events: 0, over voltage events: 0, power good: no
Heap OK, handles allocated/used 0/0, heap memory allocated/used/recyclable 0/0/0, gc cycles 0
Events: 0 queued, 0 completed
Driver 0: ok, SG min n/a, read errors 0, write errors 0, ifcnt 0, reads 0, writes 0, timeouts 0, DMA errors 0, CC errors 0
Driver 1: ok, SG min n/a, read errors 0, write errors 0, ifcnt 0, reads 0, writes 0, timeouts 0, DMA errors 0, CC errors 0
Driver 2: ok, SG min n/a, read errors 0, write errors 0, ifcnt 0, reads 0, writes 0, timeouts 0, DMA errors 0, CC errors 0
Driver 3: ok, SG min n/a, read errors 0, write errors 0, ifcnt 0, reads 0, writes 0, timeouts 0, DMA errors 0, CC errors 0
Driver 4: ok, SG min n/a, read errors 0, write errors 0, ifcnt 0, reads 0, writes 0, timeouts 0, DMA errors 0, CC errors 0
Driver 5: ok, SG min n/a, read errors 0, write errors 0, ifcnt 0, reads 0, writes 0, timeouts 0, DMA errors 0, CC errors 0
Driver 6: ok, SG min n/a, read errors 0, write errors 0, ifcnt 0, reads 0, writes 0, timeouts 0, DMA errors 0, CC errors 0
Date/time: 1970-01-01 00:00:00
Cache data hit count 84872674
Slowest loop: 0.25ms; fastest: 0.00ms
=== 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, max steps late 0, min interval 0, bad calcs 0, ebfmin 0.00, ebfmax 0.00
no step interrupt scheduled
Moves shaped first try 0, on retry 0, too short 0, wrong shape 0, maybepossible 0
=== 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 -1 -1 -1 -1, chamber heaters -1 -1 -1 -1, ordering errs 0
=== GCodes ===
Movement locks held by null, null
HTTP is idle in state(s) 0
Telnet is idle in state(s) 0
File is idle in state(s) 0
USB is ready with "M122" 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 0x0000000
Code queue 0 is empty
Q1 segments left 0, axes/extruders owned 0x0000000
Code queue 1 is empty
=== CAN ===
Messages queued 178, received 0, lost 0, errs 170972, boc 0
Longest wait 0ms for reply type 0, peak Tx sync delay 0, free buffers 26 (min 26), ts 178/0/0
Tx timeouts 0,0,177,0,0,0 last cancelled message type 30 dest 127
=== SBC interface ===
Transfer state: 0, failed transfers: 0, checksum errors: 0
RX/TX seq numbers: 0/1
SPI underruns 0, overruns 0
State: 0, disconnects: 0, timeouts: 0 total, 0 by SBC, IAP RAM available 0x0d90c
Buffer RX/TX: 0/0-0, open files: 0

Tobi

Hi.

I have trouble connecting to my duet in sbc mode.
It is a duet 3 mini 5+, and a raspberry pi 4. I installed everything according to the documentation, both the newest firmware on the board and on the pi. Unfortunately I keep getting the error "Could not connect to Duet: timeout while waiting for transfer ready pin". I tried connecting a different pi, which works with my other 6hc board and this one shows the same error.

In fact, I can take any of my two pis and connect them to my 6hc board and it works just fine, while they will both not work on my duet 3 mini 5+.
I also exchanged ribbon cables. No difference. They work with the 6hc but not the mini.

Funny thing is, that it all used to work fine two weeks ago, and now it does not anymore.
Any ideas? Is it possible that the board is broken?
I am not entirely sure, but I might have put the ribbon cable on with an offset of one pin, while the pi was already powered on (the duet was not). I immediately unplugged it and connected it the wrong way. Could this damage anything permanently?

I can still connect to the duet mini via pronterface and updated the firmware this way, I can also send commands. Only the SBC mode does not work...

Cheers
Tobi