my second raspberry has just passed away

A Former User

This post is deleted!

spllg

@bearer

using a serial terminal on the Pi? minicom, screen, echo, cat, socat lots of options but less user friendly on the console. (there are probaly more user friendly graphical alternatives, that could also be used with VcXsrv or even VNC etc)

pronterface, octoprint, ..

my question should have read: how to electrically interface usb interface?

A Former User

@spllg said in my second raspberry has just passed away:

pronterface, octoprint, ..

Why on earth would you be running the Duet 3 with a raspberry pi + DSF and use ether of those?

for pronterface ditch the Pi. for octoprint ditch DSF and run octoprint on the Pi.

@spllg said in my second raspberry has just passed away:

how to electrically interface usb interface?

but if you must you can use socat and virtual serial ports.

spllg

@bearer

would probably be best to open JP1 in either case though.

is JP1 the same as 'Internal 5V enable'?

A Former User

@spllg said in my second raspberry has just passed away:

is JP1 the same as 'Internal 5V enable'?

yes.

there are diodes to prevent feeding VBUS into the 5v regulator, but given the feedback is outside of those diodes you could risk the internal regulator outputting a voltage higher than 5v if VBUS drops below 5v? ~~which would not self regulate if the JP4 / 5V->SBC jumper is not fitted.~~

spllg

@bearer

Why on earth would you be running the Duet 3 with a raspberry pi + DSF and use ether of those?

because i do not feel comfortable with dsf

but if you must you can use socat and virtual serial ports.

if i connect the duet to the raspberry by using a standard usb cable 5v and ground will be connected between the two devices - a configuration (as mentioned by you) might have the potential to kill a raspberry.

You guys discussed this a little above, and then moved on. This absolutely will not work (as Dave pointed out). The fact that it does work for @spllg would seem to be the key to whatever is killing these.

A Former User

@spllg said in my second raspberry has just passed away:

if i connect the duet to the raspberry by using a standard usb cable 5v and ground will be connected between the two devices - a configuration (as mentioned by you) might have the potential to kill a raspberry.

this is already connected through the ribbon cable (if that is installed?)

and there is no reason supplying power from the usb cable should have any other risk than through the ribbon cable; but both scenarios would probably be better off disabling the internal 5v regulator on the duet.

spllg

@bearer yes - but what if i want to access the duet using the usb interface? there would be a double connection.

but both scenarios would probably be better off disabling the internal 5v regulator on the duet.

how to disable 'internal 5v regulator'? by removing the 'Internal 5V enable' jumper?

this already has been removed as stated in

spllg 20 Apr 2020, 10:36

i am powering the duet 5v from the rpi via usb (internal 5v enable, 5v->sbc and sbc->5v are open)

(the comma ',' in the paranthes should read 'and')

dc42

A possible problem I can see with powering the Duet from the Pi via USB is that the Pi may decide to shut off the USB power to the Duet, if that happens, then the Pi will be powered but the Duet won't be. This will cause current to flow from the SPI pins of the Pi to the Duet. There are current-limiting resistors in that interface, but they are only 100 ohms in order to allow a high SPI speed. It could be that the Pi is trying to feed too much current into those lines.

Better to power the Pi from the Duet directly or vice versa using the jumpers provided.

dc42

@bearer said in my second raspberry has just passed away:

The default 5V power configuration is Internal 5V enable - jumpered, 5V->SBC jumpered (the Duet is powering the SBC) , SBC->5V* not jumpered. If you want the SBC to provide 5V to the Duet then remove the jumper from 5V->SBC and from Internal 5v En. Place a jumper on SBC-5V*. NOTE this bypasses the 5V protection and a fault on the SBC may damage the Duet.

Does indeed seem to be a typo. SBC->5V(JP5) only connects the 5V_EXT and 5V_INT; you still need the 5V->SBC(JP4) jumper to get the powe from the Pi header and to 5V_EXT. Open JP1; close JP4 and JP5 or use the VBUS/5V_EXT_INPUT input to retain the diode protection?

I confirm that to power the Duet 5V from the Pi, you need to have both SBC->5V and 5V->SBC jumpers in place.

EDIT: I have updated the documentation.

spllg

@dc42 ok - so the jumpers '5v -> sbc' and 'sbc -> 5v' must be set and i should not try to access the duet using it's usb port - right?

A Former User

@spllg said in my second raspberry has just passed away:

should not try to access the duet using it's usb port - right?

disconnect the ribbon cable if you feel the need to try usb, to alleviate dc42s concern about the spi signals.

A Former User

@dc42 said in my second raspberry has just passed away:

A possible problem I can see with powering the Duet from the Pi via USB is that the Pi may decide to shut off the USB power to the Duet, if that happens, then the Pi will be powered but the Duet won't be.

not sure if it applies to all versions of the Pi, but some do seem to turn off USB power when powering off and rebooting.

dc42

@spllg said in my second raspberry has just passed away:

@dc42 ok - so the jumpers '5v -> sbc' and 'sbc -> 5v' must be set and i should not try to access the duet using it's usb port - right?

Accessing the Duet using its USB port will be safe provided that you have the jumpers in place so that the Duet is not dependent on USB power. But you shouldn't normally need to use the USB connection, because everything except for flashing firmware using Bossa can be done over the SPI connection.

Make sure that all PSUs powering the Duet, Pi or anything connected to the Pi that have mains ground connections are plugged into the same mains distribution block.

Whilst I have come up with a possible explanation for why the Pi might get damaged when powering the Duet form USB, it may not be the correct explanation for the failure of your 2 boards. Are you using the official Pi PSU?

spllg

@dc42 yes, i'm using the official pi psu.

btw: using the duet3 in standalone mode seems to have network issues.

i could not upload a gcode file (23m) - the upload was interrupted an the text 'network problems' (or something like this) was displayed in the lower left corner. when i repeated the upload it worked fine.
the connection was lost when the machine was printing and i had no chance to reconnect. waited for the print to finish and had to reboot the duet. this happened twice.

dc42

@spllg said in my second raspberry has just passed away:

btw: using the duet3 in standalone mode seems to have network issues.

i could not upload a gcode file (23m) - the upload was interrupted an the text 'network problems' (or something like this) was displayed in the lower left corner. when i repeated the upload it worked fine.

the connection was lost when the machine was printing and i had no chance to reconnect. waited for the print to finish and had to reboot the duet. this happened twice.

Which firmware version? The RRF 3.0beta releases had an issue in the network stack, which was fixed before the 3.0 stable release.

spllg

@dc42 m115 returns 'FIRMWARE_NAME: RepRapFirmware for Duet 3 MB6HC v0.6 or 1.0 FIRMWARE_VERSION: 3.01-RC2 ELECTRONICS: Duet 3 MB6HC FIRMWARE_DATE: 2020-02-18b1'

dc42

@spllg said in my second raspberry has just passed away:

@dc42 m115 returns 'FIRMWARE_NAME: RepRapFirmware for Duet 3 MB6HC v0.6 or 1.0 FIRMWARE_VERSION: 3.01-RC2 ELECTRONICS: Duet 3 MB6HC FIRMWARE_DATE: 2020-02-18b1'

Thanks, I suggest you upgrade to 3.01-RC9 and see if the network issues persist.

spllg

i have received a new rpi, installed it and the printer works using this rpi.

q.: is it necessary to upgrade dwc on rpi?

if yes: how to do it.

currently running
ii duetcontrolserver 1.2.4.0 armhf Control server application for Duet 3 series
ii duetruntime 1.2.4.0 armhf .NET Core runtime libraries for the Duet software framework
ii duetsd 1.0.5 all Virtual SD card directory for the Duet software framework
ii duetsoftwareframework 1.2.4.0 armhf Meta package for the full Duet software framework
ii duettools 1.2.4.0 armhf Optional tools (code examples)
ii duetwebcontrol 2.0.7-1 all Official web interface for Duet electronics
ii duetwebserver 1.2.3.1 armhf Optional web server for Duet 3 series

dc42

You can either switch to the unstable package feed and upgrade to the latest DSF, DWC and RRF release candidates, or wait for the 3.01 stable release.