my second raspberry has just passed away

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.

spllg

@dc42 thanks for your answer - going to wait for 3.01 stable. (have you got any idea when it will be released?)

please allow another question: i'm using cura and can upload gcode to the duet rpi.
i found a cura plugin (Duet RepRapFirmware Integration) and installed it but it does not work. the plugin wants to access http://<rpi-hostname>/rr_connect?password=&time=2020-04-23.. but rr_connect does not exist on <rpi-hostname> - ERROR 404: Not Found.
(how) can i enable http://<rpi-hostname>/rr_connect?

dc42

The plugins for Cura and S3D and the upload support in PrusaSlicer are designed for the upload interface provided by Duets in standalone mode. DSF on the Pi supports a different upload interface. I think there is an experimental version of one of the plugins that supports both interfaces.

spllg

@dc42 thanks for your reply. i cloned from https://github.com/Kriechi/Cura-DuetRRFPlugin/ . this seems to work fine.

btw1: how is it possible to activate/use simulation mode in dsf?

btw2: could you please tell me where to find a network printing plugin for s3d?

dc42

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

@dc42 thanks for your reply. i cloned from https://github.com/Kriechi/Cura-DuetRRFPlugin/ . this seems to work fine.

btw1: how is it possible to activate/use simulation mode in dsf?

Simulation mode is available in the RRDF/DSF release candidate, available on the unstable package feed.

btw2: could you please tell me where to find a network printing plugin for s3d?

I don't think there is a S3D plugin that supports upload to Duet with attached SBC yet, but according to https://forum.duet3d.com/topic/15492/duetrff-cura-plugin-duet-3/25 there is now one for Cura.

A Former User

IIRC the last time I looked at S3D it was a script that runs ~~wget~~ curl?

if so we could "easily" replace with ssh/scp command to achieve the same with DSF

edit:
in Duet wifi S3D:

Yep, Got it

This works:
curl -F "file=@[output_filepath]" "http://192.168.x.x/rr_upload?name=0%3A%2Fgcodes%2F[output_filename].gcode"
curl "http://192.168.x.x/rr_gcode?gcode=M32 0%3A%2Fgcodes%2F[output_filename].gcode"

Many thanks !!

assuming windows and putty with public key authentication set up on the pi*

"%PROGRAMFILES%\PuTTY\pscp.exe" -i "%USERPROFILE%\.ssh\id_rsa.ppk" [output_filepath] pi@duet3:/opt/dsf/sd/gcode/[output_filename].gcode

and

curl -s -d 'M32 "[output_filename].gcode"' http://duet3/machine/code

@gtj0 said simplified things a little removing the need to run ssh, just scp. (As such I guess one could install an ftp server to remove the need to use scp and just rely on curl, but each to his own i guess)

~~"%PROGRAMFILES%\PuTTY\plink.exe" -no-antispoof -i "%USERPROFILE%\.ssh\id_rsa.ppk" pi@duet3 "echo M32 [output_filename].gcode | sudo /opt/dsf/bin/CodeConsole"~~

~~this also means you need to add a NOPASSW entry to run CodeConsole as root without a password. should probaly be wrapped as shells script to ensure only M32 and a valid file is passed as well.~~

I can't try those, but should get you started and we can help trouble shoot.

*) ideally the key should be dedicated to S3D uploads and limited to only allow the specific commands and scp. can probably get around to a more thorough guide next week

spllg

@dc42

Simulation mode is available in the RRDF/DSF release candidate, available on the unstable package feed.

will wait for release 3.01

I don't think there is a S3D plugin that supports upload to Duet with attached SBC yet

so i'm going to wait until one is available before buying s3d

according to https://forum.duet3d.com/topic/15492/duetrff-cura-plugin-duet-3/25 there is now one for Cura.

i guess, that's the one which is working at my site.

spllg

@bearer thanks - i did have not yet decided to buy s2d (which seems to be better than cura).