Quick question about boot order with an RPi and Duet 3
-
@ChrisP said in Quick question about boot order with an RPi and Duet 3:
I don't think the service waits for the desktop to load before starting.
No, it doesn't explicitly wait but it'll still be contending for the resources to start (and its not just the desktop). How big an impact I don't know, I tend to use the light image for all things pi and didn't time it, 10 seconds was just a stab in the dark, and 5 seconds an estimate for a faster SBC with SSD or something.
Maybe it could be worth looking into moving DCS up on the start priority, it wouldn't technically have to wait for networking to start, only storage really. DWS/DWC could start later.
-
@deckingman said in Quick question about boot order with an RPi and Duet 3:
Does anything get screwed up if power to the Duet board is interrupted in that case?
check out dc42 @ https://forum.duet3d.com/post/148283 and the rest of the thread. (tl;dr theoretical possiibilty)
edit: to ensure that's not a problem you could consider trying https://forum.duet3d.com/post/148888 but its not tested
is there any downside (apart from using a small amount of electricity) in keeping the RPi permanently powered and just switching off the 24V to the Duet boards when not in use?
the main wear would be flash writes (and possible cooling fan). but when the system is idle neither should be necessary, so not a huge factor.
-
Never trusted thermostatic fans for similar reasons. Corrupt SD = blocked hotend. Best thing would be to adjust the firmware so one fan connector defaults to on until the config is successfully read in. That would have the downside of not being able to take anything on that specific pin that was dangerous if on, such as heater or laser...
-
@DocTrucker said in Quick question about boot order with an RPi and Duet 3:
Best thing would be to adjust the firmware so one fan connector defaults to on untilthe config is successfully read in.
or like the Duet2, lacking pull downs; as such one could try removing some..
-
Forgot the main point of replying! I thought the Slice engineering hotends were designed to be ok in a fan failure, but clearly not. Or is that just due to the rest of your hotend setup?
Running 3 P3Steel with Duet 2. Duet 3 on the shelf looking for a suitable machine. One first generation Duet in a Logo/Turtle style robot!
-
@bearer said in Quick question about boot order with an RPi and Duet 3:
or like the Duet2, lacking pull downs; as such one could try removing some..
I've lost you a little there!
Running 3 P3Steel with Duet 2. Duet 3 on the shelf looking for a suitable machine. One first generation Duet in a Logo/Turtle style robot!
-
@DocTrucker The Slice Engineering claim is valid where there is forward movement of the filament. They have printed for many days with no fans - even without the copper heat sinks and just using the thin tubes - and with PLA which is the worse filament in this respect. BUT, (and it's a big BUT) if filament does not move forward and is static, then the filament itself will effectively bridge the heat break. That's just simply physics so no matter how effective a heat break is, you can still get heat creep through the filament itself if it is static.
-
@deckingman Is this with the Toolboar or the expansion board? Looks like the toolboard doesn't have pull downs on the output fets as such it should be possible to behave more like the Duet2?
-
@DocTrucker said in Quick question about boot order with an RPi and Duet 3:
@bearer said in Quick question about boot order with an RPi and Duet 3:
or like the Duet2, lacking pull downs; as such one could try removing some..
I've lost you a little there!
Duet2 Fan 1 will spin until the firmware loads and drives the pin low, the other outputs have pull down resistors to ensure outputs stay off until the firmware is running.
-
@DocTrucker Ref the always on fan thing - I think I'll do what I mentioned above. That is, connect the positive side of the fan(s) to a fan header, but connect the negative side to gnd on the input terminal or some other convenient non-PWM switched gnd point. Given that PWM switches the negative side then connecting the negative side of the fans to permanent gnd should make them always on should it not?
Edit. So the fans will run whenever DC voltage is present - no waiting for config.g or anything else to get read.
-
@deckingman yes, taking from a 12V regulated source straight to ground would be fine. I know wiring heaters in series isn't a great move but what about pairing up the fans and running from 24V?
At the end of the day if one fan has gone you've had a bad day, you may as well make it worse!
I concede Plan A - regulated 12V - is better. 
Running 3 P3Steel with Duet 2. Duet 3 on the shelf looking for a suitable machine. One first generation Duet in a Logo/Turtle style robot!
-
@bearer Thanks for the links. tl:dr but they seem to be related to powering the RPI from the Duet or vice versa, or powering over USB. But in my case, I have a completely separate 5V supply. The gnd side of all DC supplies are connected together and also connected to chassis earth. There is only one connection to mains and the earth side of that too is connected to chassis earth. Not my field of expertise by any means but I don't think there is much likelhood of ground loops? Yes? No?.
-
@deckingman said in Quick question about boot order with an RPi and Duet 3:
@bearer Thanks for the links. tl:dr but they seem to be related to powering the RPI from the Duet or vice versa, or powering over USB. But in my case, I have a completely separate 5V supply. The gnd side of all DC supplies are connected together and also connected to chassis earth. There is only one connection to mains and the earth side of that too is connected to chassis earth. Not my field of expertise by any means but I don't think there is much likelhood of ground loops? Yes? No?.
the point dc42 made was having a powered rPi with a unpowered Duet could theoretically cause damage to the rPi's SPI circutry.
the link to the isolator was a proposed solution to remedy that - getting full galvanic isolation as a side effect.
(but you'd still run the risk of ground loops with your setup IF say the 5v GND connection were to get interrupted; as is the case with all ground loops, they're contingent on a fault)
-
@DocTrucker said in Quick question about boot order with an RPi and Duet 3:
@deckingman .............. I know wiring heaters in series isn't a great move but what about pairing up the fans and running from 24V?......................
Ohh man. I did that - with the exception of wiring the fans in series
. That is to say, I forgot to move a jumper on one of expansion boards and put 24V on two expensive, near silent, Sunon Maglev fans. They didn't even attempt to turn - just gave a discrete "pop". Still waiting for the replacements to arrive.......... -
@bearer said in Quick question about boot order with an RPi and Duet 3:
the point dc42 made was having a powered rPi with a unpowered Duet could theoretically cause damage to the rPi's SPI circutry.
the link to the isolator was a proposed solution to remedy that - getting full galvanic isolation as a side effect.
Ahh, OK. Thanks. Sounds like that's best avoided then...
-
@deckingman said in Quick question about boot order with an RPi and Duet 3:
Sounds like that's best avoided then...
It is easily avoided by powering both from the same (5v) supply through the ribbon cable; direction doesn't matter, both will always be powered together. (just make sure to set the jumpers correctly)
I had other reasons for wanting to try full isolation.
-
If the pi and the duet are both powered from an external 5V supply then no problem? In this instance I think I'd be inclinded to have a single posative feed to the pi, let it ground through the ribbon, and disconnect the posative feed to the pi via the ribbon. You get past the 3A limit to the pi problem then. And no ground loops.
I'd need to recheck the schematics for the Duet3 but on the Duet2, v0.8.5, and v0.6 all ground terminals were connected on the boards. With that in mind the easiest way to deal with multiple PSUs is to chain the negatives on the PSUs and only connect one negative to each control board with a big thick wire of a higher rating than the PSU can kick out before dropping to short circuit protection. For the seperate supplies take the posatives to the board.
What I'd need to look at further is how ground loops are avoided with the ancillary boards. Could you end up with a fault current going down the CAN control wire, or are they isolated?
Running 3 P3Steel with Duet 2. Duet 3 on the shelf looking for a suitable machine. One first generation Duet in a Logo/Turtle style robot!
-
The issue with an unpowered Duet and a powered Pi is only if the Duet's USB is connected to a Pi USB. In normal operation, you don't need that connection. I have them connected via a USB cable that has the power wires cut so only data flows and only because I've been testing RRF and DSF releases. I've been running for 8 months now with leaving the SBC powered on and powering the Duet on and off with absolutely no issues.
There has been a recent change in the behavior of things when the Duet is reset. Until recently, if you reset the Duet either by M999 or by hard reset on the Duet, it would read config.g and restart just as quickly as if it were in standalone mode. The recent change on the SBC side was to also restart the DuetControlServer to resolve any "sync" issues. This can add 5 seconds to the restart time. You can disable the new behavior in the DCS's config.json file however.
-
@DocTrucker said in Quick question about boot order with an RPi and Duet 3:
You get past the 3A limit to the pi problem then.
is the problem real? i mean micro usb which is the (normal) alternative is rated for mere 1.8A even if Raspberry Pi supplies
But yes, you could split the power pins out of the Ribbon cable and power the boards from the same ext 5v supply. Dealers choice on using the SBC header or 5V_EXT header to power the Duet I guess.
CAN bus isn't necessarily isolated, but its also not necessarily ground referenced so I don't think I'll comment more on that
-
Can we go back to 24 seconds? (By the way, I get that same time, roughly). Is this a real problem?
Data point 1: The cooling fan on the smart effector in my delta causes false triggers of the probe. I turn that fan off while probing. At the beginning of every print job. And, yes, the hotend is hot (for accurate probing) and has filament in it. For much longer than 24 seconds. No issues, ever.
The finned heat sink in most hot ends is physically large enough to have some amount of thermal inertia. I'd seriously doubt that its temperature changes more than a trivial amount with the fan off for 20 or 30 seconds.
Is there some hot end config or use case that I'm missing?
Yes? No? Thoughts?
Delta / Kossel printer fanatic
