Duet 2 Ethernet and SBC
-
@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.
-
@resam Is anyone ordering a batch of these boards and doesn't need all 10 of them? Please PM me if you want to sell one. I'm in the US. Thanks!
-
FYI - I found adding a simple ferrite core to the cabling from the Duet to the Pi has silenced the SPI errors.
I have a ~10CM run with shielded cables, but I guess it's still noisy there, but that core appears to have reduced the noise enough to bump the frequency back to 4MHz. Haven't tried the full 8MHz yet as I want to get some prints finished before I do anymore testing.
-
@keyz182 Could you post details of the type of core you used and perhaps a picture of how you have it installed?
-
@gloomyandy can't get to the back of the printer right now. As for which ones, I litterally typed "ferrite core" into Amazon and bought the first ones that came up. Just clipped them straight onto the cable. I did have to trim the insulation a bit as it was a bit too fat ( I have a pair of 4core shielded cables, so trimmed the outer insulation). If you have loose cables, they should just fit, all of them through the one core.
It came to mind as I had to do the same with my Paneldue. It's got maybe a meter of cable to it, and it was very intermittent without the core
-
@keyz182 Thanks! So I guess it was one of those clip on versions rather than a ferrite ring? Assume you just passed the wires through once?
-
@gloomyandy yup, the clip ons, and just the once.
-
I have ordered some boards from @deadwood83 at JLCPCB.
If you are from Germany and need one, feel free to contact me: https://forum.duet3d.com/topic/22545/3x-duet-2-ethernet-sbc-adapter-to-sell-germany-only
