Restart DuetControlServer (SBC)

Phaedrux

To be honest I'm not sure about the 3.3 and 5v pins. Try without if you're short on jumper wires.

BeosDoc

I'll try the jumpers first. Then I'll try the changes to that file.

BeosDoc

First part. I replaced the ribbon cable with very short, 9cm (ribbon is 20cm), and brand new jumpers. Initial boot worked. After that it still had the status of Off.

FYI: You do need pin 17 (3.3V) hooked up. Without it, it didn't see it at all.

For future reference Duet 3 > rPi you need pins 17, 19, 21, 22, 23, 24, 26 (not sure about 26) and one of the grounds (like 20 and/or 25

Now for the second part with the file

BeosDoc

@gloomyandy said in Restart DuetControlServer (SBC):

Given that the main purpose of the SBC is to talk to the Duet I'm not sure it really makes sense to disable the service in this way. If you are happy making changes to the rPi config files (worse case you just reinstall everything), you can tell systemd not to disable a service in this situation by adding the following line:
StartLimitIntervalSec=0

to the [unit] part of the service control file. In this case that file is:
/etc/systemd/system/multi-user.target.wants/duetcontrolserver.service

I modified the file /etc/systemd/system/sysinit.target.wants/duetcontrolserver.service

I tried it several times and it didn't see it

BeosDoc

@Phaedrux said in Restart DuetControlServer (SBC):

I've asked christian to take a look at this. Regardless, the Duet and Pi should be making a connection so the retry shouldn't come into play. Seems like either a bad cable or damaged pins.

If it was a bad cable or damaged pins, then it probably wouldn't work at all or there would be lots of comm errors. If I reboot the pi or restart DuetControlServer it works find, I've done several prints.

gloomyandy

@BeosDoc Are you getting any

systemd[1]: duetcontrolserver.service: Start request repeated too quickly.

messages now in your syslog file? Are you rebooting the rPi to test this?

chrishamm

@gloomyandy Thanks for pointing out this limitation, I'll check if I can integrate your change in the next software version. The automatic fail detection wasn't an issue in earlier DSF versions because that always had a restart delay of 5 seconds.

@BeosDoc What I find odd about your report is that you do get occasional transfers (albeit with bad checksums) so I'm wondering if there is something wrong with the SPI peripheral either on the Pi or the Duet. Can you run the spidev_test procedure as described here? I'll update the docs with better troubleshooting instructions soon.

dc42

@BeosDoc said in Restart DuetControlServer (SBC):

First part. I replaced the ribbon cable with very short, 9cm (ribbon is 20cm), and brand new jumpers. Initial boot worked. After that it still had the status of Off.

FYI: You do need pin 17 (3.3V) hooked up. Without it, it didn't see it at all.

For future reference Duet 3 > rPi you need pins 17, 19, 21, 22, 23, 24, 26 (not sure about 26) and one of the grounds (like 20 and/or 25

To clarify: using Duet 3 MB6HC version 1.01 and later, or a Duet 3 Mini, you do need the 3.3v pin because it feeds the voltage translation buffer. You do not need the 5V pin.

It's better to connect more than one ground, especially the ground pins close to the SPI pins.

BeosDoc

@gloomyandy said in Restart DuetControlServer (SBC):

@BeosDoc Are you getting any
systemd[1]: duetcontrolserver.service: Start request repeated too quickly.

messages now in your syslog file? Are you rebooting the rPi to test this?

Actually I don't see any of those messages since I made the change to that file. The last time it appeared was 18:22 on Mar 1 which is before I made the change. I did a reboot of pi after I changed /etc/systemd/system/sysinit.target.wants/duetcontrolserver.service but not since then and I even did a print last night. The pi has it's own separate power supply and stays on (several reasons: powering off pi without proper shutdown could cause some corruption, don't want to wait for it to boot )

gloomyandy

@BeosDoc Well that's a good sign then and possibly removes one potential source of the problem you are seeing.

BeosDoc

@chrishamm said in Restart DuetControlServer (SBC):

@BeosDoc What I find odd about your report is that you do get occasional transfers (albeit with bad checksums) so I'm wondering if there is something wrong with the SPI peripheral either on the Pi or the Duet. Can you run the spidev_test procedure as described here? I'll update the docs with better troubleshooting instructions soon.

Here's the results:

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 0 (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.
pi@duet3:~ $

SPI should be working, I've done several prints. Also, this isn't a good test, it shows that it's working but 32 bytes isn't long enough to see if there is any errors during a long transmission .

Is there a SPI test for the Duet 3?