Duet 2 Ethernet and SBC
-
modified duet
I hate removing connectors from 4 layer boards but this was rather easy
not a lot of thermal mass on the prc clone, obviously 1oz copper -
@arhi said in Duet 2 Ethernet and SBC:
I hate removing connectors from 4 layer boards but this was rather easy
That corner of the real deal is also the easiest to work with, not a lot of ground planes and heavy traces. But yeah, 1oz "helps"'D
-
This post is deleted! -
@bearer yup, I have some exp. desoldering from 4 layer 2oz and I had to preheat the board not to destroy the holes... this came out like it was a 2layer board
... anyhow, the adapter, as is, if one wanna use the probe and panel connectors operation like this is necesary .. and is def not for everyone (100000% kills your varanty )the "bottom add adapter" by @deadwood83 is probbly much better solution, I like this for me as I don't have any wires and it holds my sbc in place but not sure this approach is the best, I think his approach is much better.
-
@dc42 do you know if something like this is planed?
-
I've been having comms issues since installing one of @deadwood83's boards. It will connect fine in DWC, but every so often it will reset the controller. Looking at the log, it keeps getting bad checksum errors. I don't believe my wiring is to blame, but it could be. Any ideas?
The thick white cable + yellow wire comprise the connection to the pi. It is a bit of cat5 cable with connectors crimped on.
P.S.- Measuring the cable length, it's about 200mm. Maybe that could be the issue?
P.P.S- I do not have a duex. Just the duet.
-
More info:
- Letting the printer sit idle (heaters off, motors off) produces almost no errors.
- Letting the printer sit idle (heaters on, motors off) produces more errors.
- Running a simulation has no effect.
Scoping the SPI pins, the waves look to be well-formed. A little bit of jitter, but otherwise good.
Overall, it seems pretty random to me.
-
@SAtech I tested (with my "pcb-link" so no wires) so far only the simulation as I have no motors nor heaters attached to that duet board yet. If you run a long simulation, does it pass ok? you don't see any errors?
... === SBC interface === State: 0, failed transfers: 0 Last transfer: 20ms ago RX/TX seq numbers: 4497/4498 SPI underruns 0, overruns 0 Number of disconnects: 0 Buffer RX/TX: 0/0-0 -
@arhi Simulation seems to work. However, if I have the heaters on, it will give a few errors:
=== SBC interface === State: 0, failed transfers: 2 Last transfer: 11ms ago RX/TX seq numbers: 27937/27939 SPI underruns 0, overruns 0 Number of disconnects: 0 Buffer RX/TX: 0/0-0 === Duet Control Server === Duet Control Server v3.2.0-beta2 Code buffer space: 4096 Configured SPI speed: 4000000 Hz Full transfers per second: 28.70In the DCS log, it gives a few more than that, mostly bad checksum errors and disconnects.
When I try to print, that's when I get problems. When and how it errors out can vary. Sometimes it just stops, sometimes it causes erratic behavior (mis-probes the bed, halts in the middle of a move):=== SBC interface === State: 0, failed transfers: 3 Last transfer: 8ms ago RX/TX seq numbers: 34957/34958 SPI underruns 0, overruns 3 Number of disconnects: 0 Buffer RX/TX: 0/0-0 === Duet Control Server === Duet Control Server v3.2.0-beta2 Code buffer space: 4096 Configured SPI speed: 4000000 Hz Full transfers per second: 31.21In this instance, it got through the homing procedure and tried to probe the bed. It only probed one point, but three times, and then stopped.
DCS log:[warn] Bad header checksum (expected 0x2001, got 0xfb88) [warn] Bad header checksum (expected 0x2001, got 0xfb88) [warn] Bad header checksum (expected 0x2001, got 0xfb88) [warn] Note: RepRapFirmware didn't receive valid data either (code 0x00004000) [warn] Restarting transfer because the number of maximum retries has been exceeded [debug] Cancelled M83 ; use relative distances for extrusion [debug] Cancelled G92 E0 ; set extruder to zero [info] Aborted macro file bed.g [warn] File: ==> Cancelling unfinished starting code: G32 ; home axes, calibrate bed leadscrews, and load saved mesh heightmap [warn] Controller has been reset -
@SAtech I can't determine this from the image: do you have a direct ground connection between your RPi and your VIN PSU? I found that the ground pin on the Duet network header is not sufficient for this purpose.
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 I do. I have two PSUs, one 24v and one 5v. All the grounds are connected in star topology, and the red/black connector on the pi is connected to 5v and ground.
-
It seems like it must be something software related, since I can't see any reason why it shouldn't work.
Just so I'm not crazy:
-
@SAtech said in Duet 2 Ethernet and SBC:
It seems like it must be something software related, since I can't see any reason why it shouldn't work.
that signal looks decent.
it is probably sw related but sw detects error in CRC (good that there is CRC checking for packets) and that is hardly sw related, in my, limited, experience that is usually transport line issue when hw spi is used on both sides (and I doubt anyone is bit banging the 8 MHz spi
)few questions
- did you try reducing the SPI speed ? dropping from 8 MHz to 1 MHz ?
- did you try the "drill" test ? (start a long running simulation, take a drill, one that connect to mains outlet, not those battery powered ones, turn on a drill and bring it close to the wires) do you see increase in errors?
- the utp cable you are using, its not shielded? did you maybe tried shielded cable?
-
I was playing bit more, since via's are free I stiched it up a bit, I moved the SBC connector 10mm up so now the front of the both pcb's (duet and rpi) are in line, sbc is not sticking up messing up with case) and also since the "extended" part of the connector is not used I made a via-cut so you can snap off that part of the pcb and solder on shorter connector.
signal pats are not crossed anywhere (that's why 3v is routed all the way around) so return current should flow easy trough the ground plain and this should work at super high speeds without any issues .. and 8 MHz should be a brieze ... when I order the boards I'll do the "electrical drill test" but I believe this is rather resilient like this
-
@arhi said in Duet 2 Ethernet and SBC:
I made a via-cut so you can snap off that part of the pcb
lemme know if jlcpcb accepts that without insisting on a paneling fee for multiple designs?
-
@bearer I hope they do but even without those few via-s it is easy to cut off that part of the board
... I won't be ordering it yet, waiting for more testing with existing pcb (too slow for now, I'm still one-handed) ...I was also thinking about making another change - to add 2 female pinheaders over the paneldue and probe connectors so one can just "cut the plastic" of the connector and press the board on to the duet hitting both ethernet port and the paneldue and mode ports, and then add those 2 connectors on this board so they are accessible from the top .. but will see .. maybe just a more comples cutout
-
Well it seems that by twisting MOSI, MISO, and SCK with ground has basically solved my issue. I am now getting NO errors, and I can print successfully. Seems there was significant crosstalk in the lines.
The only thing that is a little troublesome is sometimes the movement is quite jerky. Like in a long travel move it will just stop for a few ms and resume, as if the duet is choking on step generation. I don't think this is happening, but that's how I can best describe it.
-
@arhi said in Duet 2 Ethernet and SBC:
and 8 MHz should be a brieze ...
Just as a benchmark: the maximum the Duet can achieve reliably is around 27MHz.
-
@SAtech said in Duet 2 Ethernet and SBC:
as if the duet is choking on step generation
should show up in
M122? -
@SAtech said in Duet 2 Ethernet and SBC:
The only thing that is a little troublesome is sometimes the movement is quite jerky. Like in a long travel move it will just stop for a few ms and resume, as if the duet is choking on step generation. I don't think this is happening, but that's how I can best describe it.
If that persists please open a new thread (since this one is getting very long and a bit hijacked
) and include your config.gas well as theM122output that @bearer mentioned and a sample GCode file.
