DCS Crash with 3.01-R10 / DWC 2.1.5 / DSF 2.1.1
-
@jay_s_uk said in DCS Crash with 3.01-R10 / DWC 2.1.5 / DSF 2.1.1:
Timeout while waiting for transfer ready pin
that would imply DCS is blaming the duet; but not a guarantee DCS isnt at fault still i guess
-
@bearer
The pi has been rebooted and as soon as I try and do something, I lose all connection to the pi. I can't even SSH into it.
Cutting power and gets it back up and running again.First time round, the first thing I tried to do was run my tool unlock macro and the same thing happened again
-
Spoke too soon. The whole thing has died again.
Owns various duet boards and is the main wiki maintainer for the Teamgloomy LPC/STM32 port of RRF. Assume I'm running whatever the latest beta/stable build is
-
Back down at RC9 but my CPU fan is still not working correctly - really don't want to go back to RC7 but can't handle the constant noise.
I KNOW this fan can work correctly - has done so since RC1 .... why can't I see fan 2 on the dashboard ? (doesn't even appear in the display filter)
Has something changed in gcode ????
M308 S2 Y"mcu-temp" A"CPU" M950 F2 C"!out4" A"MCU" Q32000 L5 M106 P2 T40:45 H2 ; set Duet cooling fan -
@Garfield said in DCS Crash with 3.01-R10 / DWC 2.1.5 / DSF 2.1.1:
More hassle than I'm in the mood for
you could probably ssh in, stop DuetControlServer service and run it in the foreground to try and capture any relevant debugging info. installing and using screen would pervent DCS from being terminated if the ssh session is terminated.
sudo apt install -y screenand then runsudo systemctl stop duetcontrolserverfollowed bysudo screen /opt/dsf/bin/DuetControlServer -l debug -
At the time you couldn't ssh - the RPi wasn't responsive at all, if you had an SSH session open it just stopped responding.
I will try the screen though - what does that offer? - a non DWC web gui ?
-
@jay_s_uk said in DCS Crash with 3.01-R10 / DWC 2.1.5 / DSF 2.1.1:
Spoke too soon.
if you've got access to console/ssh could you also run something like top and see if it spots something to suggest DCS get stuck in a loop?
-
@Garfield said in DCS Crash with 3.01-R10 / DWC 2.1.5 / DSF 2.1.1:
I will try the screen though - what does that offer?
its a terminal multiplexer / window manager or sometihng like so. it achieves that dcs will keep running if you have a network glitch. if you run dcs in the foreground and ssh stops all the processes in that shell are terminated - with screen they can keep running.
-
First message
[warn] RepRapFirmware got a bad header checksum
and then [screen is terminating]
-
@Garfield said in DCS Crash with 3.01-R10 / DWC 2.1.5 / DSF 2.1.1:
[warn] RepRapFirmware got a bad header checksum
I was getting those when I very first setup my D3 & Pi. Firmly re-seating the ribbon cable on both ends cleared them up.
-
@bearer said in DCS Crash with 3.01-R10 / DWC 2.1.5 / DSF 2.1.1:
@jay_s_uk said in DCS Crash with 3.01-R10 / DWC 2.1.5 / DSF 2.1.1:
Spoke too soon.
if you've got access to console/ssh could you also run something like top and see if it spots something to suggest DCS get stuck in a loop?
Terminal dies as soon as the web connection does.
I'll try and run DCS through the session and see what it spits out. It'll be later on though as I'm on bedtime duty now. -
the only thing I could think of that with respect to DCS to complaining about the RDY pin is basically an interrupt storm which can grind the Pi to a halt. not sure if relevant though.
-
Well this sucks - it's just done the same thing with RC9 ..... I had screen running at the time and it reported nothing ....
[debug] Assigning filament Prusament PETG to extruder drive 0 [debug] Requesting update of key boards, seq 0 -> 0 [debug] Requesting update of key directories, seq 0 -> 0 [debug] Requesting update of key fans, seq 0 -> 7 [debug] Requesting update of key heat, seq 0 -> 7 [debug] Requesting update of key inputs, seq 0 -> 0 [debug] Requesting update of key job, seq 0 -> 2 [debug] Requesting update of key move, seq 0 -> 30 [debug] Requesting update of key network, seq 0 -> 3 [debug] Requesting update of key sensors, seq 0 -> 4 [debug] Requesting update of key spindles, seq 0 -> 0 [debug] Requesting update of key state, seq 0 -> 1 [debug] Requesting update of key tools, seq 0 -> 5 [debug] Requesting update of key volumes, seq 0 -> 0 [debug] IPC#2: Got new UNIX connection, checking mode... [debug] IPC#2: Subscription processor registered in Patch mode [debug] IPC#3: Got new UNIX connection, checking mode... [debug] Updated key boards [debug] IPC#3: Command processor added [debug] IPC#3: Received command AddUserSession [debug] Updated key directories [debug] Updated key fans [debug] Updated key heat [debug] Updated key inputs [debug] Updated key job [debug] Updated key move [debug] Updated key network [debug] IPC#4: Got new UNIX connection, checking mode... [debug] IPC#4: Command processor added [debug] IPC#4: Received command ResolvePath [debug] IPC#5: Got new UNIX connection, checking mode... [debug] IPC#5: Command processor added [debug] IPC#4: Connection closed [debug] IPC#5: Received command ResolvePath [debug] IPC#6: Got new UNIX connection, checking mode... [debug] IPC#5: Connection closed [debug] IPC#7: Got new UNIX connection, checking mode... [debug] IPC#6: Command processor added [debug] IPC#6: Received command ResolvePath [debug] IPC#7: Command processor added [debug] IPC#7: Received command ResolvePath [debug] IPC#6: Connection closed [debug] IPC#7: Connection closed [debug] Updated key sensors [debug] IPC#8: Got new UNIX connection, checking mode... [debug] IPC#8: Command processor added [debug] IPC#8: Received command ResolvePath [debug] IPC#8: Connection closed [debug] Updated key state [debug] Updated key tools [debug] Updated key volumes [debug] IPC#9: Got new UNIX connection, checking mode... [debug] IPC#10: Got new UNIX connection, checking mode... [debug] IPC#11: Got new UNIX connection, checking mode... [debug] IPC#10: Command processor added [debug] IPC#9: Command processor added [debug] IPC#11: Command processor added [debug] IPC#9: Received command ResolvePath [debug] IPC#10: Received command ResolvePath [debug] IPC#11: Received command ResolvePath [debug] Requesting update of key job, seq 2 -> 3 [debug] Requesting update of key move, seq 30 -> 31 [debug] IPC#9: Connection closed [debug] IPC#11: Connection closed [debug] IPC#10: Connection closed [debug] Updated key job [debug] Updated key move [debug] IPC#12: Got new UNIX connection, checking mode... [debug] IPC#12: Subscription processor registered in Patch mode [debug] IPC#13: Got new UNIX connection, checking mode... [debug] IPC#13: Command processor added [debug] IPC#13: Received command ResolvePathI feel the need for a compatibility matrix for the 3 main components - which versions of RRF work wich versions of DWC.
I'd like to help the team figure this out but I haven't a clue where to start and I need the printer at least 'functional' even if there are known issues. Right now it isn't even functional.
I'm using a 4 Gig RPi 4 if it is worth anything (yes I know its OTT) ...
-
@Garfield said in DCS Crash with 3.01-R10 / DWC 2.1.5 / DSF 2.1.1:
Well this sucks - it's just done the same thing with RC9 ..... I had screen running at the time and it reported nothing ....
unfortunate, but still probably still helpfull for chrishamm. what happened to the ssh session timed out after a while or was it terminated immediately?
-
Terminated immediately ...
-
@bearer said in DCS Crash with 3.01-R10 / DWC 2.1.5 / DSF 2.1.1:
@Garfield said in DCS Crash with 3.01-R10 / DWC 2.1.5 / DSF 2.1.1:
I will try the screen though - what does that offer?
its a terminal multiplexer / window manager or sometihng like so. it achieves that dcs will keep running if you have a network glitch. if you run dcs in the foreground and ssh stops all the processes in that shell are terminated - with screen they can keep running.
It's not a network glitch. When it happens it tends to take out the entire Pi. Completely. So using screen isn't going to help. I've managed to get the network to stay up about 3 or 4 times out of 40 or so crashes, in which case screen isn't needed as you can still issue commands.... everything just takes an age to respond. But yeh, as soon as the SSH connection goes a power cycle is the only fix.
@Garfield said in DCS Crash with 3.01-R10 / DWC 2.1.5 / DSF 2.1.1:
Well this sucks - it's just done the same thing with RC9 ..... I had screen running at the time and it reported nothing ....
That sucks. It's only been RC10 that I've had this issue on. To the extent that the first time it happened I went and checked to see if my router had died.
-
@Garfield said in DCS Crash with 3.01-R10 / DWC 2.1.5 / DSF 2.1.1:
Terminated immediately ...
t
hats interesting; it means the cpu is able to relatively cleanly terminate the session as opposed to just freezing; although it doesn't help you.see below for correction. -
I wonder if something didn't uninstall or get overwritten in the 'downgrade' process. I never used RC9, I came straight from RC6
-
@ChrisP said in DCS Crash with 3.01-R10 / DWC 2.1.5 / DSF 2.1.1:
So using screen isn't going to help.
mostly a precaution to avoid terminating the process if the session is interrupted for other reasons.
-
@bearer I should say that there is no disconnect - just zero repsonse - no messages, it just stops ... I use a commercial tool (Secure CRT 8.7) and it still thinks it is connected but hitting enter just causes an on screen line feed.
