Duet3/pi DCS is unavailable after wiring 24V
-
@bearer nice; I'm getting a new error message indeed;
pi@duet3:~ $ apt list 2>/dev/null | grep duet duetcontrolserver/unstable,now 2.1.1 armhf [installed,automatic] duetruntime/unstable,now 2.1.1 armhf [installed,automatic] duetsd/unstable,now 1.0.6 all [installed,automatic] duetsoftwareframework/unstable,now 2.1.1 armhf [installed] duettools/unstable,now 2.1.1 armhf [installed,automatic] duetwebcontrol/unstable,now 2.1.5 all [installed,automatic] duetwebserver/unstable,now 2.1.0 armhf [installed,automatic] pi@duet3:~ $ sudo journalctl -u duetcontrolserver -e Apr 25 15:46:18 duet3 systemd[1]: duetcontrolserver.service: Succeeded. Apr 25 15:46:23 duet3 systemd[1]: duetcontrolserver.service: Service RestartSec=5s expired, scheduling restart. Apr 25 15:46:23 duet3 systemd[1]: duetcontrolserver.service: Scheduled restart job, restart counter is at 61. Apr 25 15:46:23 duet3 systemd[1]: Stopped Duet Control Server. Apr 25 15:46:23 duet3 systemd[1]: Started Duet Control Server. Apr 25 15:46:24 duet3 DuetControlServer[3286]: Duet Control Server v2.1.1 Apr 25 15:46:24 duet3 DuetControlServer[3286]: Written by Christian Hammacher for Duet3D Apr 25 15:46:24 duet3 DuetControlServer[3286]: Licensed under the terms of the GNU Public License Version 3 Apr 25 15:46:26 duet3 DuetControlServer[3286]: [info] Settings loaded Apr 25 15:46:26 duet3 DuetControlServer[3286]: [info] Environment initialized Apr 25 15:46:27 duet3 DuetControlServer[3286]: [fatal] Could not connect to Duet (Timeout while waiting for transfer ready pin)
I'll try the gpio test
-
@fractalengineer said in Duet3/pi flashing Diag LED after wiring 24V DCS is unavailable:
Apr 25 15:46:27 duet3 DuetControlServer[3286]: [fatal] Could not connect to Duet (Timeout while waiting for transfer ready pin)
That is suggesting no connection to the Duet, the gpio test could rule out the Pi, new cable could rule out the ribbon.
-
@bearer ok here's the test again with the gpio util:
pi@duet3:~ $ DY=22 CS=24 ; { > gpio -1 mode $CS out > gpio -1 mode $RDY in > gpio -1 write $CS 1 && echo "(Pin RDY/$RDY) `gpio -1 read $RDY` should equal `gpio -1 read $CS` (Pin CS/$CS)" > gpio -1 write $CS 0 && echo "(Pin RDY/$RDY) `gpio -1 read $RDY` should equal `gpio -1 read $CS` (Pin CS/$CS)" > { ~/spidev-test/spidev_test -v -s 8000000 -D /dev/spidev0.0 && echo RX should equal TX. ;} | tail -n3 | cut -b-100 ;} Usage: gpio mode pin mode Usage: gpio read pin (Pin RDY/) should equal 1 (Pin CS/24) Usage: gpio read pin (Pin RDY/) should equal 0 (Pin CS/24) TX | FF FF FF FF FF FF 40 00 00 00 00 95 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF F0 0D RX | FF FF FF FF FF FF 40 00 00 00 00 95 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF F0 0D RX should equal TX.
...And wow, here's with a jump on the ribbon...
pi@duet3:~ $ RDY=22 CS=24 ; { > gpio -1 mode $CS out > gpio -1 mode $RDY in > gpio -1 write $CS 1 && echo "(Pin RDY/$RDY) `gpio -1 read $RDY` should equal `gpio -1 read $CS` (Pin CS/$CS)" > gpio -1 write $CS 0 && echo "(Pin RDY/$RDY) `gpio -1 read $RDY` should equal `gpio -1 read $CS` (Pin CS/$CS)" > { ~/spidev-test/spidev_test -v -s 8000000 -D /dev/spidev0.0 && echo RX should equal TX. ;} | tail -n3 | cut -b-100 ;} (Pin RDY/22) 0 should equal 1 (Pin CS/24) (Pin RDY/22) 0 should equal 0 (Pin CS/24) TX | FF FF FF FF FF FF 40 00 00 00 00 95 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF F0 0D RX | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 RX should equal TX.
Guess we found the culprit
So can we try wiring using the duponts? what are the minimum wires required?
-
@fractalengineer said in Duet3/pi flashing Diag LED after wiring 24V DCS is unavailable:
(Pin RDY/22) 0 should equal 1 (Pin CS/24)
Now thats interesting.
I wasn't able to test if that can only mean the RDY pin isn't reading correctly, or if it could be the CS pin not being asserted correctly. But it is in line with the error from DCS.
I'd be surprised if DCS was blocking the CS pin but not the MISO/MOSI pins, but for good measure making sure DCS isn't running might be worth while.
Then you could attempt to actually measure the voltage, but the fact that it isn't working is sufficient to move on to the next Pi imo. Given the RDY pin is defined as an input it should be safe to jumper it straight to 3.3v and see if the value stays at 1. That would confirm if the problem is RDY or CS.As a last resort you can attempt to change the RDY pin. Its defined in
/opt/dsf/conf/config.json
. But you could change the definition (for the test), move the jumper and re-run the test before editing the file. Changing RDY from 22 to 26 will mean you have to use a custom cable, and connect 26 on the Pi to 22 on the Duet. And jumper 26 to 24 to test with (the only change is RDY=26)RDY=26 CS=24 ; { gpio -1 mode $CS out gpio -1 mode $RDY in gpio -1 write $CS 1 && echo "(Pin RDY/$RDY) `gpio -1 read $RDY` should equal `gpio -1 read $CS` (Pin CS/$CS)" gpio -1 write $CS 0 && echo "(Pin RDY/$RDY) `gpio -1 read $RDY` should equal `gpio -1 read $CS` (Pin CS/$CS)" { ~/spidev-test/spidev_test -v -s 8000000 -D /dev/spidev0.0 && echo RX should equal TX. ;} | tail -n3 | cut -b-100 ;}
Edit: oh damn, pins in config.json are broadcom gpios, which means you need to enter 7 in config.json to use physical pin2 26. Just to rule out differences between versions of rPi run
gpio readall | cut -b41-90 | grep "^| 26 " | cut -b35-38
to check that it outputs 7, or use whatever number it does output. -
damn I can't edit the previous post but I figured I messed up the mirroring of the pins on the ribbon; here's the actual result
pi@duet3:~ $ RDY=22 CS=24 ; { > gpio -1 mode $CS out > gpio -1 mode $RDY in > gpio -1 write $CS 1 && echo "(Pin RDY/$RDY) `gpio -1 read $RDY` should equal `gpio -1 read $CS` (Pin CS/$CS)" > gpio -1 write $CS 0 && echo "(Pin RDY/$RDY) `gpio -1 read $RDY` should equal `gpio -1 read $CS` (Pin CS/$CS)" > { ~/spidev-test/spidev_test -v -s 8000000 -D /dev/spidev0.0 && echo RX should equal TX. ;} | tail -n3 | cut -b-100 ;} (Pin RDY/22) 0 should equal 1 (Pin CS/24) (Pin RDY/22) 0 should equal 0 (Pin CS/24) TX | FF FF FF FF FF FF 40 00 00 00 00 95 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF F0 0D RX | FF FF FF FF FF FF 40 00 00 00 00 95 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF F0 0D RX should equal TX.
-
@fractalengineer said in Duet3/pi flashing Diag LED after wiring 24V DCS is unavailable:
here's the actual result
ah, i got hung on the "interesting" part, which stayed the same so no worries.
Its the RDY or CS pin that should get focus for now.
-
@fractalengineer said in Duet3/pi flashing Diag LED after wiring 24V DCS is unavailable:
So can we try wiring using the duponts? what are the minimum wires required?
you can, but if jumpering it directly on the pi doesn't work, new wires isn't going to help.
The pins are shown on the Duet3 wiring diagram, in the note. This does visualize it (I've only connected two of the 5 grounds, but it should suffice). Connect 1:1 from the Duet to the Pi taking care to correctly identifying pin 1.
-
@bearer Ok so the next steps would be:
1-Stopping DCS and rerunning the test
2-Jump RDY (22) to 3.3v
3-Change RDY pin
4-Swap to the other Rpi
5-Wire with all jumpersAm I correct?
Those are pretty heavy operations I'll try to hang there but I hope I won't mess anything
Here's 1-Stopping DCS and rerunning the test
pi@duet3:~ $ sudo systemctl stop duetwebserver pi@duet3:~ $ sudo systemctl stop duetcontrolserver pi@duet3:~ $ RDY=22 CS=24 ; { gpio -1 mode $RDY in > gpio -1 mode $CS out > gpio -1 mode $RDY in > gpio -1 write $CS 1 && echo "(Pin RDY/$RDY) `gpio -1 read $RDY` should equal `gpio -1 read $CS` (Pin CS/$CS)" > gpio -1 write $CS 0 && echo "(Pin RDY/$RDY) `gpio -1 read $RDY` should equal `gpio -1 read $CS` (Pin CS/$CS)" > { ~/spidev-test/spidev_test -v -s 8000000 -D /dev/spidev0.0 && echo RX should equal TX. ;} | tail -n3 | cut -b-100 ;} (Pin RDY/22) 0 should equal 1 (Pin CS/24) (Pin RDY/22) 0 should equal 0 (Pin CS/24) TX | FF FF FF FF FF FF 40 00 00 00 00 95 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF F0 0D RX | FF FF FF FF FF FF 40 00 00 00 00 95 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF F0 0D RX should equal TX.
-
Tbh, I'd start by just having jumpers on the other pi.
Then I'd move the jumpers to jump RDY(26) to CS(24) and run the gpio test again, targeting the correct RDY pin. edit: actually run the gpio test before and after changing the jumper, ignoring the output the first time (to ensure the pin is in input mode before connecting it)
If still no dice, then I'd wire RDY to 3.3v and run the gpio test again, targeting the correct RDY pin be it 22 or 26. (again run gpio test before making changes to ensure pin is input)
If all of that fails then no point in the rest.
If something succeeds then try with the duet and whatever combination of Pi and RDY pin gave the desired test result.
Also note I edited the post about editing config.json to reflect which pin number to enter if you get to that point.
-
@bearer thanks;
Ok so here's my wiring;
I wired both grounds and both +5v; is this about right?
-
@fractalengineer said in Duet3/pi flashing Diag LED after wiring 24V DCS is unavailable:
I wired both grounds and both +5v; is this about right?
Yes, they're just double up to reduce voltage drop.
It looks right as far as I can tell; but not easy to see if blue/purple was swapped on the way over. The rest I'm reasonable confident in.
Although I'd be very surprised to see it working if the gpio test didn't indicate RDY and CS had the same readings on each line.
-
Does the soldering of the 26-way connector look OK on the underside of the Duet?
-
Side note: DCS uses the driver that provides /dev/gpiochip because it allows faster reactions to pin level transitions than the standard sysfs GPIO driver. So I recommend using the tools from the gpiod package for GPIO troubleshooting (install via
apt-get install gpiod
). So by runninggpiodetect
you can see all the available GPIO lines. Once you shut down DCS, you can check the pin state by runninggpioget 0 25
and that should output1
. I'll install that package by default in the next DuetPi version. -
@chrishamm said in Duet3/pi flashing Diag LED after wiring 24V DCS is unavailable:
So I recommend using the tools from the gpiod package for GPIO troubleshooting
ah, thats why wiringpi wasn't a dependency any more. I'll work it into the instructions at a later time. thanks for the heads up.
So by running gpiodetect you can see all the available GPIO lines.
i think you meant
gpioinfo
but close enough. -
@bearer damn you caught it!
Thanks; ok so the problem still exists with the jumpers; not sure if relevant wired to duet but here's the test:
pi@duet3:~ $ RDY=22 CS=24 ; { gpio -1 mode $CS out; gpio -1 mode $RDY in; gpio -1 write $CS 1 && echo "(Pin RDY/$RDY) `gpio -1 read $RDY` should equal `gpio -1 read $CS` (Pin CS/$CS)"; gpio -1 write $CS 0 && echo "(Pin RDY/$RDY) `gpio -1 read $RDY` should equal `gpio -1 read $CS` (Pin CS/$CS)"; { ~/spidev-test/spidev_test -v -s 8000000 -D /dev/spidev0.0 && echo RX should equal TX. ;} | tail -n3 | cut -b-100 ;} (Pin RDY/22) 0 should equal 1 (Pin CS/24) (Pin RDY/22) 0 should equal 0 (Pin CS/24) TX | FF FF FF FF FF FF 40 00 00 00 00 95 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF F0 0D RX | 05 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 RX should equal TX.
@dc42 solderings look perfect; both on the duet and the pi
-
@fractalengineer said in Duet3/pi flashing Diag LED after wiring 24V DCS is unavailable:
not sure if relevant wired to duet but here's the test:
no its not, it'll only give the same readings if the pins are shorted; which is why I would wait with connecting the duet until testing with just jumpers show its working properly.
-
@bearer Ok here's the result moving RDY from 22 to 26:
24 is bridged to 26
pi@duet3:~ $ gpio -1 mode 26 in pi@duet3:~ $ RDY=26 CS=24 ; { > gpio -1 mode $CS out > gpio -1 mode $RDY in > gpio -1 write $CS 1 && echo "(Pin RDY/$RDY) `gpio -1 read $RDY` should equal `gpio -1 read $CS` (Pin CS/$CS)" > gpio -1 write $CS 0 && echo "(Pin RDY/$RDY) `gpio -1 read $RDY` should equal `gpio -1 read $CS` (Pin CS/$CS)" > { ~/spidev-test/spidev_test -v -s 8000000 -D /dev/spidev0.0 && echo RX should equal TX. ;} | tail -n3 | cut -b-100 ;} (Pin RDY/26) 1 should equal 1 (Pin CS/24) (Pin RDY/26) 0 should equal 0 (Pin CS/24) TX | FF FF FF FF FF FF 40 00 00 00 00 95 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF F0 0D RX | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 RX should equal TX.
-
Okay, pin 22 dead. progress.
Now back to editing config.json.
The physical pin numbers on the PI does not match the internal numbering in the CPU, config.json needs the internal numbering.
Run this mess of a command and check it outputs 7.
gpio readall | cut -b41-90 | grep "^| 26 " | cut -b35-38
then edit
/opt/dsf/conf/config.json
and find the line"TransferReadyPin": 25,
change it to
"TransferReadyPin": 7,
(or whatever number the previous gpio readall... command returned)
buy volcano insurance and try the duet making sure to wire pin 22 from the duet to pin 26 on the pi
edit: suddenly I have a concern about rebooting the pi in this configuration. do not reboot the pi with the modified wiring; I'll need a bit of time to test if its aproblem that the pin reverts to an output at boot. (or maybe its better to just pick anoter pin that defaults to input right of the bat. I picked 26 because it only meant moving the jumper one possition over.
Yeah, after consideration I'd use physical pin 18 instead.
gpio readall | cut -b41-90 | grep "^| 18 " | cut -b35-38
should return (internal pin number) 24, and that number goes into config.json after then wiring physical 18 on the pi to pin 22 on the Duet. Pardon the detour, making the path up as we go - on the bright side you've singel handedly made sure all future troubles have a path to follow and you've done it like a champ! -
Wow @bearer you absolutely killed it
Thank you everyone!
-
@fractalengineer said in Duet3/pi flashing Diag LED after wiring 24V DCS is unavailable:
you absolutely killed it
...again with the jokes, but technically you killed it, i fixed it, or put a band aid on it at least ...
volcano insurance ftw!