Duet3/pi DCS is unavailable after wiring 24V
-
A screw can still carry current unless isolated on both sides of the board or chassis (or even from the bore of a plated hole)
anyways, if you connect to the usb port (can use the pi for that, just provide the pi with power as well) what response do you get to
M122
and if you run
apt list 2>/dev/null | grep duet
in ssh on the pi it'll list the specific versions installed which may be relvant for some. -
@bearer Where would I enter M122 when DWC refuses to load?
For the versions command here's the return:
Thanks
-
@fractalengineer said in Duet3/pi flashing Diag LED after wiring 24V DCS is unavailable:
Where would I enter M122 when DWC refuses to load?
serial terminal? i tend to use screen as i have it installed anyway.
( you could trytimeout 1 cat /dev/ttyACM0 & echo -e "\nM122" > /dev/ttyACM0
)as you're running 1.2.4.0 stable, you should stick to the 3.0 version of the firmware.
this thread as some of the same problems (with respect to versions), with options for solutions if you read the whole tread.
-
@fractalengineer said in Duet3/pi flashing Diag LED after wiring 24V DCS is unavailable:
1-Powering duet over USB
2-Powering Duet through Pi on USBYour photo shows Duet power by VIN (which is good!). And I believe I see jumpers to power Pi from duet (which is good!). To eliminate variables, I'd stick to that for now. In particular DON"T power Duet from Pi, that is not a supported config.
You also have Duetsoftwareframework 1.2.4.0 installed. I can't quite figure out what firmware matches that (3.0 says it requires 1.3.something). I would do one of two things:
- bossa the board with the firmware in /opt/dsf/sd/sys/Duet3Firmware_MB6HC.bin
-or-
- Install DSF 1.2.5.0 and then do the same thing.
Me, personally, I'd go to 1.2.5.0
-
@bearer Thank you; that's an informative thread, unfortunately the Duet is currently running RRF 3.0 already; still no use.
Here's what the command @chrishamm mentioned returns:
pi@duet3:~ $ sudo journalctl -u duetcontrolserver -e Apr 12 13:32:35 duet3 systemd[1]: duetcontrolserver.service: Succeeded. Apr 12 13:32:40 duet3 systemd[1]: duetcontrolserver.service: Service RestartSec= Apr 12 13:32:40 duet3 systemd[1]: duetcontrolserver.service: Scheduled restart j Apr 12 13:32:40 duet3 systemd[1]: Stopped Duet Control Server. Apr 12 13:32:40 duet3 systemd[1]: Started Duet Control Server. Apr 12 13:32:41 duet3 DuetControlServer[1405]: Duet Control Server v1.2.4.0 Apr 12 13:32:41 duet3 DuetControlServer[1405]: Written by Christian Hammacher fo Apr 12 13:32:41 duet3 DuetControlServer[1405]: Licensed under the terms of the G Apr 12 13:32:43 duet3 DuetControlServer[1405]: [info] Settings loaded Apr 12 13:32:44 duet3 DuetControlServer[1405]: [info] Environment initialized Apr 12 13:32:45 duet3 DuetControlServer[1405]: [error] Duet is not available Apr 12 13:32:45 duet3 systemd[1]: duetcontrolserver.service: Succeeded. Apr 12 13:32:50 duet3 systemd[1]: duetcontrolserver.service: Service RestartSec= Apr 12 13:32:50 duet3 systemd[1]: duetcontrolserver.service: Scheduled restart j Apr 12 13:32:50 duet3 systemd[1]: Stopped Duet Control Server. Apr 12 13:32:50 duet3 systemd[1]: Started Duet Control Server. Apr 12 13:32:50 duet3 DuetControlServer[1445]: Duet Control Server v1.2.4.0 Apr 12 13:32:50 duet3 DuetControlServer[1445]: Written by Christian Hammacher fo Apr 12 13:32:50 duet3 DuetControlServer[1445]: Licensed under the terms of the G Apr 12 13:32:53 duet3 DuetControlServer[1445]: [info] Settings loaded Apr 12 13:32:54 duet3 DuetControlServer[1445]: [info] Environment initialized Apr 12 13:32:54 duet3 DuetControlServer[1445]: [error] Duet is not available Apr 12 13:32:54 duet3 systemd[1]: duetcontrolserver.service: Succeeded.
And thank you for your response @Danal ; I already Bossa the board to RRF3.0 but I will try to update DSF to 1.2.5
-
@Danal said in Duet3/pi flashing Diag LED after wiring 24V DCS is unavailable:
Your photo shows Duet power by VIN (which is good!).
No it shows the board powered by usb, albeit with VIN connected. And with nothing else connected a single USB power source isn't going to cause a problem and is easier to relay than the alternatives, while keeping the potential for damage to a minimum.
-
@bearer said in Duet3/pi flashing Diag LED after wiring 24V DCS is unavailable:
apt list 2>/dev/null | grep duet
Well observed; I forgot to mention but while always plugged in both VIN and USB, I never powered the Duet through both; either plugging USB to the laptop or turning on the PSU, never both.
-
@fractalengineer said in Duet3/pi flashing Diag LED after wiring 24V DCS is unavailable:
but I will try to update DSF to 1.2.5
please confirm the board is actuallt running RRF firmware by sending it
M122
orM115
first over a serial terminal.@fractalengineer said in Duet3/pi flashing Diag LED after wiring 24V DCS is unavailable:
I never powered the Duet through both; either plugging USB to the laptop or turning on the PSU, never both.
I support that, eliminates the risk of a ground loop, which is why I suggested using the Pi like I did.
-
@bearer said in Duet3/pi flashing Diag LED after wiring 24V DCS is unavailable:
please confirm the board is actuallt running RRF firmware by sending it M122or M115 first over a serial terminal.
@bearer said in Duet3/pi flashing Diag LED after wiring 24V DCS is unavailable:
( you could try
timeout 1 cat /dev/ttyACM0 & echo -e "\nM122" > /dev/ttyACM0
)I've only tested that command with ssh on a Pi against a Duet 2, but no reason it shouldn't work with a Duet 3 as well if you don't have a serial terminal installed (most arent very user friendly on the Pi)
-
@bearer thank you for sticking with me
Ok so I downloaded and configured YAT to use as a terminal according to this guide: https://duet3d.dozuki.com/Guide/1.)+Getting+Connected+to+your+Duet/7
It seems to be connecting to it, but every time I enter one of both M122 or M115, the interface disconnects and reconnects.
Likewise, your command doesn't seem to be working on mine either
pi@duet3:~ $ timeout 1 cat /dev/ttyACM0 & echo -e "\nM122" > /dev/ttyACM0 [1] 4220 -bash: /dev/ttyACM0: Permission denied pi@duet3:~ $ cat: /dev/ttyACM0: No such file or directory [1]+ Exit 1 timeout 1 cat /dev/ttyACM0
-
@fractalengineer said in Duet3/pi flashing Diag LED after wiring 24V DCS is unavailable:
bash: /dev/ttyACM0: Permission denied
which image are you running on the Pi, pretty sure the default has the pi in the dialout group to allow permissions. the other alternative is the file isn't there.
sudo solves permisions, and
lsusb
shows us if the duet is detected by the Pi. -
@bearer I tried with sudo prefix as well; same result
The image is the Duet Pi from the Getting Started guide
I also updates all packages according to the thread you mentioned earlier; everything is now running those versions:
pi@duet3:~ $ apt list 2>/dev/null | grep duet duetcontrolserver/unstable 1.3.1 armhf [upgradable from: 1.2.4.0] duetruntime/unstable 1.3.1 armhf [upgradable from: 1.2.4.0] duetsd/unstable 1.0.6 all [upgradable from: 1.0.5] duetsoftwareframework/unstable 1.3.1 armhf [upgradable from: 1.2.4.0] duettools/unstable 1.3.1 armhf [upgradable from: 1.2.4.0] duetwebcontrol/unstable 2.1.1 all [upgradable from: 2.0.7-1] duetwebserver/unstable 1.3.1 armhf [upgradable from: 1.2.3.1]
The code recommended the unstable releases...
Lastly here's the
lsusb
result:pi@duet3:~ $ lsusb Bus 001 Device 004: ID 0424:7800 Standard Microsystems Corp. Bus 001 Device 003: ID 0424:2514 Standard Microsystems Corp. USB 2.0 Hub Bus 001 Device 002: ID 0424:2514 Standard Microsystems Corp. USB 2.0 Hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
I just redownloaded a duetpi image; I'm keen to reflash everything from scratch.
However the DIAG LED blinking without the PI connected tells me the issue might come from the Duet board rather than the Rpi?
-
@fractalengineer said in Duet3/pi flashing Diag LED after wiring 24V DCS is unavailable:
The code recommended the unstable releases...
it has its challenges, which is why i linked to the previous thread.
anyways, Pi isn't detecting the Duet.
Don't suppose its any different on your computer in Device Manager?
-
@bearer said in Duet3/pi flashing Diag LED after wiring 24V DCS is unavailable:
anyways, Pi isn't detecting the Duet.
and it should show up as one of these two entries, for either running RRF or in the bootloader.
Bus 001 Device 004: ID 1d50:60ee OpenMoko, Inc. Bus 001 Device 008: ID 03eb:6124 Atmel Corp. at91sam SAMBA bootloader
-
@bearer I see; well my windows is showing just fine:
I can connect to it via YAT just fine; just any command I send disconnects it
-
@fractalengineer said in Duet3/pi flashing Diag LED after wiring 24V DCS is unavailable:
I can connect to it via YAT just fine; just any command I send disconnects it
can you open that device properties and look at the hardware id?
(this is why i prefer using the pi:)
-
@bearer sure there it is
-
Looks like the Duet 3 vid and pid. Can you check out which driver it uses and/or update to the one Duet3d provides?
-
@bearer wow ok we are getting somewhere; thank you for your excellent insights
I updated the drivers with the ones provided on the RRF github, now YAT is working and commands are responding.
A first M115 showed that the board was indeed in 3.01 RC6; Bossa'd back to 3.0, here's what
M115
andM122
returns finallyM115 FIRMWARE_NAME: RepRapFirmware for Duet 3 MB6HC v0.6 or 1.0 FIRMWARE_VERSION: 3.0 ELECTRONICS: Duet 3 MB6HC FIRMWARE_DATE: 2020-01-03b3 ok M122 === Diagnostics === RepRapFirmware for Duet 3 MB6HC v0.6 or 1.0 version 3.0 running on Duet 3 MB6HC Board ID: 08DJM-956L2-G43S4-6J9F6-3S86T-KA5LD Used output buffers: 1 of 32 (1 max) === RTOS === Static ram: 152720 Dynamic ram: 148504 of which 0 recycled Exception stack ram used: 280 Never used ram: 91712 Tasks: NETWORK(ready,1984) HEAT(blocked,1456) CanReceiv(suspended,3808) CanSender(suspended,1476) CanClock(blocked,1424) TMC(suspended,252) MAIN(running,4656) IDLE(ready,160) Owned mutexes: === Platform === Last reset 00:00:30 ago, cause: reset button Last software reset at 2020-04-04 15:59, reason: User, spinning module LinuxInterface, available RAM 79620 bytes (slot 0) Software reset code 0x0010 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0440f000 BFAR 0x00000000 SP 0xffffffff Task 0x4e49414d Error status: 0 Free file entries: 10 SD card 0 not detected, interface speed: 37.5MBytes/sec SD card longest block write time: 0.0ms, max retries 0 MCU temperature: min 37.5, current 40.9, max 41.0 Supply voltage: min 0.3, current 0.3, max 0.4, under voltage events: 0, over voltage events: 0, power good: no 12V rail voltage: min 0.2, current 0.3, max 0.3, under voltage events: 0 Driver 0: ok, reads 0, writes 0 timeouts 0, SG min/max 0/0 Driver 1: ok, reads 0, writes 0 timeouts 0, SG min/max 0/0 Driver 2: ok, reads 0, writes 0 timeouts 0, SG min/max 0/0 Driver 3: ok, reads 0, writes 0 timeouts 0, SG min/max 0/0 Driver 4: ok, reads 0, writes 0 timeouts 0, SG min/max 0/0 Driver 5: ok, reads 0, writes 0 timeouts 0, SG min/max 0/0 Date/time: 1970-01-01 00:00:00 Slowest loop: 0.22ms; fastest: 0.08ms === Move === Hiccups: 0(0), FreeDm: 375, MinFreeDm: 375, MaxWait: 0ms Bed compensation in use: none, comp offset 0.000 === MainDDARing === Scheduled moves: 0, completed moves: 0, StepErrors: 0, LaErrors: 0, Underruns: 0, 0 === AuxDDARing === Scheduled moves: 0, completed moves: 0, StepErrors: 0, LaErrors: 0, Underruns: 0, 0 === Heat === Bed heaters = -1 -1 -1 -1 -1 -1 -1 -1 -1, chamberHeaters = -1 -1 -1 -1 === GCodes === Segments left: 0 Stack records: 1 allocated, 1 in use Movement lock held by null http is idle in state(s) 0 telnet is idle in state(s) 0 file is idle in state(s) 0 serial is ready with "M122" in state(s) 0 aux is idle in state(s) 0 daemon* is idle in state(s) 0 0, running macro queue is idle in state(s) 0 lcd is idle in state(s) 0 spi is idle in state(s) 0 autopause is idle in state(s) 0 Code queue is empty. === Network === Slowest loop: 0.15ms; fastest: 0.01ms Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) Telnet(0) HTTP sessions: 0 of 8 - Ethernet - State: 0 Error counts: 0 0 0 0 0 Socket states: 0 0 0 0 0 0 0 0 === CAN === Messages sent 0, longest wait 0ms for type 0 === Linux interface === State: 0, failed transfers: 0 Last transfer: 30316ms ago RX/TX seq numbers: 0/1 SPI underruns 0, overruns 0 Number of disconnects: 0 Buffer RX/TX: 0/0-0 ok
-
Curious, did it affect the blinking led?