I've been trying to justify using rPi with Duet3 myself, and its not the cost :-). If you want wifi, you can always use a router in bridge mode and plug Duet3 into it.
Using rPi I see as have a few concerns: It's adds another possible point of failure. Maybe needing additional cooling, not to mention the extra space needed in the box for the board. What about power? rPi is a computer and should be shutdown properly. If you turn the power supply off you also cut power to rPi, or you have it setup another separate power supply to keep it running. Or you have to do a lot of rigging to have the rPi shut down properly then shutting off the noisy power supply.
It's nice that it's easier to update the system. If you have a spare rPi laying around doing nothing, then maybe or you want to experiment. You can always add one later on down the road. I don't foresee anything coming down the pike, as a plugin, for a long time. So far I haven't even seen anyone with a great idea for a plugin and I can't think of any except maybe display the model that's in the stl file(s).

Great, thank you. I have some toolboards coming and needed to know if I had to order different heaters or not.

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

Quick question about the toolboard with 24V supplied to the board. I know the fans are 12V, but is the heater voltage at 24V or 12V?

Thanks

@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 )

Apt update and apt upgrade upgraded the Duet 3 6HC main board firmware. It didn't upgrade DWC or the toolboards.

@dc42
Will there be support for ringing frequencies for multiple tools in the future or just load a corresponding script when changing tools, if possible?

Thank you for your time

Would you need a separate accelerometer data for each tool (on a CoreXY tool changer system)? Tools could be different, but usually are the same.

If so is, is the plans to add a per tool ringing frequencies in future versions?

I'm trying to determine if I should just replace one toolboard with V1.1 or mount an accelerometer to the X carriage.

I wonder if anybody has tested to see how much weight difference does there need to be before it effects the ringing frequencies.

Glad ringing using an accelerometer is being added. Didn't want to switch to Klipper

Thanks
Mitch

@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?

@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 )

@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 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

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

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

@Phaedrux said in Restart DuetControlServer (SBC):

@BeosDoc said in Restart DuetControlServer (SBC):

Reseated the ribbon cable...no difference.

Do you have another ribbon cable to test with or possibly make some jumper cables?

No other ribbon cable, just the one supplied with your board and I have reseated it. I have short jumper wires I can use. I want to verify the required pins: 19,21,22,23,34 and 20 for ground. Is pin 17 (3.3V) and/or Pin 2/4 (5v) required? SBC has it's own power supply and the duet no jumpers on 5V -> SBC and also SBC ->5V