Duet 2 Ethernet and SBC
-
@gloomyandy said in Duet 2 Ethernet and SBC:
@smoki3 "Warning: Lost connection to Duet" may mean that the firmware has stopped responding. Are you getting any sort of firmware reset/crash?
Sometimes it crashes sometimes it hangs forever until I do a manual reset.
-
@smoki3 It is unusual for the firmware to hang (the watchdog timer usually catches those and causes a timeout). But if you are getting resets then the output from M122 may tell you more about the cause and the stack trace may allow you (with the use of a map file) to track down where the reset happened. If you are building your own firmware you should have (or be able to generate) a map file. Doesn't always work out but a lot of times it helps!
-
@gloomyandy I assume that there a some communication issues between the firmware and the rpi. So messages get lost and the raspberry wait for a confirmation from the firmware.
Lets see if wilriker find something. As he also mentioned before in this thread he also assume that this is a firmware issue.
-
@smoki3 Fair enough, but you might still want to save the output from m122 after any resets (and perhaps make them available to wilriker). I look after the LPC/STM port and that information is very useful when trying to track down what is going on.
-
@smoki3 said in Duet 2 Ethernet and SBC:
We try to debug it. As you read this thread completely... This was the reason for starting of this thread. It never was about the hardware/pcb design
I seen now for the first time you mentioned "toolchanger" so I assume you are using DUEX. I have not noticed in the thread you are using DUEX, sorry. I understood it's a limitation of duet+sbc, that duex will not be supported. (as for the pcb part, that I apologize for, it should really be moved into some separate topic)
-
@arhi said in Duet 2 Ethernet and SBC:
I seen now for the first time you mentioned "toolchanger" so I assume you are using DUEX. I have not noticed in the thread you are using DUEX, sorry. I understood it's a limitation of duet+sbc, that duex will not be supported. (as for the pcb part, that I apologize for, it should really be moved into some separate topic)
This is just an intermediate limitation we are currently trying to resolve. It works on my setup but it does not work for @smoki3 and we try to find out why.
Manuel
Duet 3 6HC (v0.6) with RPi 4B on a custom Cartesian
with probably always latest firmware/DWC (incl. betas or self-compiled)
My Tool Collection -
@wilriker said in Duet 2 Ethernet and SBC:
This is just an intermediate limitation
awesome, I understood there's a problem making it permanent.
-
@wilriker Have you gotten this to work in a machine yet?
-
@jlipavsky79 Unfortunately I did not get to it yet. Will test in the course of this week.
-
So after receiving the boards from JLCPCB($36.37) to avoid turning your hairs gray troubleshooting, check for lifted pads on the buffer ICs. I happened to have 1 board out of 10 where the TFR pin was not soldered.
-
@MarMed only one pad on 6pin ic ? can you share pic?
-
@arhi these photos were taken before I knew the issue, and I already soldered the pad, so I apologize for the poor photo quality.
-
weird, I would not expect pad lifting on something like this... anyhow, it's easy fix, good to know ppl need to check the pcb's
-
After a few releases today I tried 3.2beta4 on my tool changer again because I saw a lot of commits regarding the SBC. It seems to work now. I will now wire everything a do a test print.
UPDATE: Test print was fine
-
-
@smoki3 said in Duet 2 Ethernet and SBC:
UPDATE: Test print was fine
That's great news!
@bearer said in Duet 2 Ethernet and SBC:
with the duex? thats awesome!
I had an (air) print running just fine with DueX5 a while back also but @smoki3 never got to finish the homing sequence with stallGuard. Glad that's working now.
-
Since this post is getting rather long, let me summarize briefly and post a few bits that I haven't found here yet:
@deadwood83 has made a nice PCB nice PCB here with PCB and schematic sources in EasyEDA. It fits nicely on a Duet 2 WiFi and DuetEthernet without desoldering the existing WiFi module.
The pins on the PCB are mostly self-explanatory to hook them up to a Raspberry Pi:
- GND to GND / multiple physical pins
- SCK to GPIO11 / SPI0 SCLK / Physical Pin 23
- MOS to GPIO10 / SPI0 MOSI / Physical Pin 19
- MISO to GPIO9 / SPI0 MISO / Physical Pin 21
- 3V3 to 3V3/Physical Pin 1 or 17
- RDY to GPIO25 (TransferReadPin) / Physical Pin 22
- CS to GPIO8 / SPI0 CE0 / Physical Pin 24
(see this for a Raspberry Pi pin out table to double check)
-
Has anyone got tips on connecting optimally?
Currently I'm using a 4 core and a 2 core shielded cables, to connect up, with the shield as ground. Still have to drop the SPI speed to 2MHz though.
When I'm able, I'll rearrange things to reduce the cable length further (about 15cm currently). I've tried to route other wires (steppers etc) away from the Comms cable.
-
I successfully connected (default settings) with a piece of 25cm ethernet cable (without the shield mesh - just the twisted pairs + outer insulation) soldered to pin headers on both sides. I paid no attention to the twisted pairs and just chose a good color mapping that worked nicely with the physical world.
I haven't run any prints yet, but DSF is working and M122 shows no SPI errors, and plenty of successful transfers after 30min idling. Jogging the axis works via PanelDue and DWC perfectly.
A snippet of my
M122:=== Diagnostics === RepRapFirmware for Duet 2 SBC version 3.2.2 running on Duet 2 1.02 or later + SBC (SBC mode) === RTOS === Static ram: 17008 Dynamic ram: 60600 of which 72 recycled Never used RAM 34400, free system stack 160 words === Platform === Last reset 00:16:35 ago, cause: power up === SBC interface === State: 4, failed transfers: 0 Last transfer: 5ms ago RX/TX seq numbers: 34553/34553 SPI underruns 0, overruns 0 Number of disconnects: 0, IAP RAM available 0x0dad4 Buffer RX/TX: 0/0-0 === Duet Control Server === Duet Control Server v3.2.2 Code buffer space: 4096 Configured SPI speed: 8000000 Hz Full transfers per second: 35.44 Maximum length of RX/TX data transfers: 2560/512 -
I had run quite a lot of successful prints previously on 3.2.
Switched to 3.3 beta today to do some testing and found prints stopping after a layer or two, and logs complaining about SPI. I think I read that 3.3 is more vocal about SPI errors, so just making sure hardware is good before looking at software, especially when it's beta.
