DCS Crash with 3.01-R10 / DWC 2.1.5 / DSF 2.1.1

A Former User

@Garfield said in DCS Crash with 3.01-R10 / DWC 2.1.5 / DSF 2.1.1:

I'm not happy connecting a USB and 24V pwr with the problems I've seen reported with grounding.

this is why I prefer to use usb form the pi, which is supplied from the duet. they all share a common ground and common supply to start with so odds of a ground loop should be as low as they get unless something is really wrong with the wiring (in which case the pi probably wouldn't work in the first place)

and i'll always be a sucker for a bash shell etc:)

and yes, bossa will only work with a usb cable, regardless of pi or computer.

ChrisP

@Garfield said in DCS Crash with 3.01-R10 / DWC 2.1.5 / DSF 2.1.1:

You're kidding - why ?

Why would I execute something on the command line of a Pi if I connected a PC anyway - I could just run BOSSA on the PC and be done ....

Not logical ...

Because BOSSA is a separate program made by others specifically for managing the flash on microcontroller such as the one on the Duets.

Your comment about why would you use command line if you could use the PC is precisely my comment above. Though as @bearer suggested, to some extent it comes down to what's easier for you in terms of what's available and what you're comfortable doing. While I'm not an expert on Linux, I'm comfortable with using command line, but I imagine most users would be more comfortable using a gui on a PC.
Anyway, if you don't have a flashing diag LED, I believe you option is only BOSSA and for that you'll need a USB cable and a PC/Pi platform of your choice. Tbh, since you've got this far, the quickest way is likely to be just running the command @bearer posted

(I think we've also drifted off topic too. Oops)

Garfield

OK - instruction really needs to be a little clearer.

If I read this correctly you can't do this using the 'ribbon' cable but must switch the RPi to connect to a USB port, this means I can leave 24 DC into the Duet and feed the Pi via the USB. Might be worth clarifying that the Ribbon should or should not be disconnected

A:
Use a data capable USB cable from any port on the Pi to the Duet.
Power the Duet from the RPi USB (the Pi must have its own power supply)

OR

B:
Power the Duet with VIN
RPi powered and connected via USB

Do one or the other; do not power both ways. I'd say that B is the preferred option unless you;re going to lift the common off VIN or you are sure that your PSU common is earth isolated

ChrisP

Yup, you shouldn't have to change your power arrangements - you don't have to unplug the ribbon cable. I assume you're powering the Pi from the D3 currently?

Garfield

I am indeed powering the Pi from the D3.

I don't think that were so far off topic if my disaster helps others who may encounter similar 'fatal' crashes.

Garfield

@bearer : 10 out of 10

This command needs to go in doczuki !!

wget https://pastebin.com/raw/Wa1kYf3G -O - | tr -d "\r" | bash

back up and to the point I was at before - can't stay connected, continuous connect / disconnect

Garfield

pr 27 11:15:05 duet3 DuetControlServer[3136]: [info] Application has shut down
Apr 27 11:15:05 duet3 systemd[1]: duetcontrolserver.service: Succeeded.
Apr 27 11:15:10 duet3 systemd[1]: duetcontrolserver.service: Service RestartSec=5s expired, scheduling restart.
Apr 27 11:15:10 duet3 systemd[1]: duetcontrolserver.service: Scheduled restart job, restart counter is at 57.
Apr 27 11:15:10 duet3 systemd[1]: Stopped Duet Control Server.
Apr 27 11:15:10 duet3 systemd[1]: Started Duet Control Server.
Apr 27 11:15:11 duet3 DuetControlServer[3175]: Duet Control Server v2.1.1
Apr 27 11:15:11 duet3 DuetControlServer[3175]: Written by Christian Hammacher for Duet3D
Apr 27 11:15:11 duet3 DuetControlServer[3175]: Licensed under the terms of the GNU Public License Version 3
Apr 27 11:15:11 duet3 DuetControlServer[3175]: [info] Settings loaded
Apr 27 11:15:11 duet3 DuetControlServer[3175]: [info] Environment initialized
Apr 27 11:15:11 duet3 DuetControlServer[3175]: [info] Connection to Duet established
Apr 27 11:15:11 duet3 DuetControlServer[3175]: [info] IPC socket created at /var/run/dsf/dcs.sock
Apr 27 11:15:12 duet3 DuetControlServer[3175]: [fatal] Abnormal program termination
Apr 27 11:15:12 duet3 DuetControlServer[3175]: [fatal] Update task faulted
Apr 27 11:15:12 duet3 DuetControlServer[3175]:    System.ArgumentException: Property set method not found.
Apr 27 11:15:12 duet3 DuetControlServer[3175]:    at System.Reflection.RuntimePropertyInfo.SetValue(Object obj, Object value, BindingFlags invokeAttr, Binder binder, Object[] index, CultureInfo culture)
Apr 27 11:15:12 duet3 DuetControlServer[3175]:    at System.Reflection.RuntimePropertyInfo.SetValue(Object obj, Object value, Object[] index)
Apr 27 11:15:12 duet3 DuetControlServer[3175]:    at System.Reflection.PropertyInfo.SetValue(Object obj, Object value)
Apr 27 11:15:12 duet3 DuetControlServer[3175]:    at DuetAPI.Machine.ModelObject.UpdateFromJson(JsonElement jsonElement, Boolean ignoreSbcProperties) in /home/christian/duet/DuetSoftwareFramework/src/DuetAPI/Machine/Base/ModelObject.cs:line 237
Apr 27 11:15:12 duet3 DuetControlServer[3175]:    at DuetAPI.Machine.FilamentMonitor.UpdateFromJson(JsonElement jsonElement, Boolean ignoreSbcProperties) in /home/christian/duet/DuetSoftwareFramework/src/DuetAPI/Machine/Sensors/FilamentMonitors/FilamentMon
Apr 27 11:15:12 duet3 DuetControlServer[3175]:    at DuetAPI.Machine.ModelObject.UpdateFromJson(JsonElement jsonElement) in /home/christian/duet/DuetSoftwareFramework/src/DuetAPI/Machine/Base/ModelObject.cs:line 209
Apr 27 11:15:12 duet3 DuetControlServer[3175]:    at DuetAPI.Machine.FilamentMonitor.UpdateFromJson(JsonElement jsonElement, Boolean ignoreSbcProperties) in /home/christian/duet/DuetSoftwareFramework/src/DuetAPI/Machine/Sensors/FilamentMonitors/FilamentMon
Apr 27 11:15:12 duet3 DuetControlServer[3175]:    at DuetAPI.Machine.ModelCollectionHelper.UpdateFromJson(IList list, Type itemType, JsonElement jsonElement, Boolean ignoreSbcProperties) in /home/christian/duet/DuetSoftwareFramework/src/DuetAPI/Machine/Bas
Apr 27 11:15:12 duet3 DuetControlServer[3175]:    at DuetAPI.Machine.ModelObject.UpdateFromJson(JsonElement jsonElement, Boolean ignoreSbcProperties) in /home/christian/duet/DuetSoftwareFramework/src/DuetAPI/Machine/Base/ModelObject.cs:line 264
Apr 27 11:15:12 duet3 DuetControlServer[3175]:    at DuetAPI.Machine.MachineModel.UpdateFromFirmwareModel(String key, JsonElement jsonElement) in /home/christian/duet/DuetSoftwareFramework/src/DuetAPI/Machine/MachineModel.cs:line 149
Apr 27 11:15:12 duet3 DuetControlServer[3175]:    at DuetControlServer.Model.Updater.Run() in /home/christian/duet/DuetSoftwareFramework/src/DuetControlServer/Model/Updater.cs:line 182
Apr 27 11:15:12 duet3 DuetControlServer[3175]: [fatal] Update task faulted
Apr 27 11:15:12 duet3 DuetControlServer[3175]:    System.ArgumentException: Property set method not found.
Apr 27 11:15:12 duet3 DuetControlServer[3175]:    at System.Reflection.RuntimePropertyInfo.SetValue(Object obj, Object value, BindingFlags invokeAttr, Binder binder, Object[] index, CultureInfo culture)
Apr 27 11:15:12 duet3 DuetControlServer[3175]:    at System.Reflection.RuntimePropertyInfo.SetValue(Object obj, Object value, Object[] index)
Apr 27 11:15:12 duet3 DuetControlServer[3175]:    at System.Reflection.PropertyInfo.SetValue(Object obj, Object value)
Apr 27 11:15:12 duet3 DuetControlServer[3175]:    at DuetAPI.Machine.ModelObject.UpdateFromJson(JsonElement jsonElement, Boolean ignoreSbcProperties) in /home/christian/duet/DuetSoftwareFramework/src/DuetAPI/Machine/Base/ModelObject.cs:line 237
Apr 27 11:15:12 duet3 DuetControlServer[3175]:    at DuetAPI.Machine.FilamentMonitor.UpdateFromJson(JsonElement jsonElement, Boolean ignoreSbcProperties) in /home/christian/duet/DuetSoftwareFramework/src/DuetAPI/Machine/Sensors/FilamentMonitors/FilamentMon
Apr 27 11:15:12 duet3 DuetControlServer[3175]:    at DuetAPI.Machine.ModelObject.UpdateFromJson(JsonElement jsonElement) in /home/christian/duet/DuetSoftwareFramework/src/DuetAPI/Machine/Base/ModelObject.cs:line 209
Apr 27 11:15:12 duet3 DuetControlServer[3175]:    at DuetAPI.Machine.FilamentMonitor.UpdateFromJson(JsonElement jsonElement, Boolean ignoreSbcProperties) in /home/christian/duet/DuetSoftwareFramework/src/DuetAPI/Machine/Sensors/FilamentMonitors/FilamentMon
Apr 27 11:15:12 duet3 DuetControlServer[3175]:    at DuetAPI.Machine.ModelCollectionHelper.UpdateFromJson(IList list, Type itemType, JsonElement jsonElement, Boolean ignoreSbcProperties) in /home/christian/duet/DuetSoftwareFramework/src/DuetAPI/Machine/Bas
Apr 27 11:15:12 duet3 DuetControlServer[3175]:    at DuetAPI.Machine.ModelObject.UpdateFromJson(JsonElement jsonElement, Boolean ignoreSbcProperties) in /home/christian/duet/DuetSoftwareFramework/src/DuetAPI/Machine/Base/ModelObject.cs:line 264
Apr 27 11:15:12 duet3 DuetControlServer[3175]:    at DuetAPI.Machine.MachineModel.UpdateFromFirmwareModel(String key, JsonElement jsonElement) in /home/christian/duet/DuetSoftwareFramework/src/DuetAPI/Machine/MachineModel.cs:line 149
Apr 27 11:15:12 duet3 DuetControlServer[3175]:    at DuetControlServer.Model.Updater.Run() in /home/christian/duet/DuetSoftwareFramework/src/DuetControlServer/Model/Updater.cs:line 182
Apr 27 11:15:12 duet3 DuetControlServer[3175]: [info] Application has shut down
Apr 27 11:15:12 duet3 systemd[1]: duetcontrolserver.service: Succeeded.

SSH connections are stable though ...

A Former User

@Garfield it needs to evolve a little, but it has a sibling that will identify and flash any duet 2 wifi/ethernet/maestro or duet 3 with the correct firmware in any state as long as usb is working. that might be proposed for the doczuki/wiki when polished.

anyways, glad you found it helpful in the end, the goal is in the end to take the guesswork out of the flashing when necessary.

Garfield

spoke too soon - ssh eventually dies .... so we are back on topic - same issue as we started with ...

ChrisP

@Garfield said in DCS Crash with 3.01-R10 / DWC 2.1.5 / DSF 2.1.1:

.... so we are back on topic - same issue as we started with ...

Excellent... ish

Is the log you posted above what you see when DCS crashes? I still haven't managed to get anything interesting in the logs.

Garfield

Yup - thats the crash log ...

Danal

I'm the one that leans toward bossa from the Pi. However, I'm just an end-user that's trying to dig another end user out of a hole. If someone else, prefers windows, great!

I prefer the Pi for two reasons:

It does avoid ground loops, to a somewhat greater extent than a separate computer.
Windows bossa works quite a bit of the time... and other times, windows gets really weird about USB ports.

Again, I'm just making suggestions, if someone prefers one tool over another, fantastic, use that!

gtj0

@Garfield @ChrisP Have you tried my suggestion above to remove the two CPUScheduling lines from /lib/systemd/system/duetcontrolserver.service and rebooting?

Danal

Data point: I have not changed the CPU scheduling and I am now about 14 hours into a print, with no issues.

Running DuetLapse on the same Pi. (Which I was not doing the other day).

I don't know what changed, if anything, from the point where I couldn't get it to run for 15 minutes at a time.

Garfield

I've not tried the scheduling - can't get DCS to start and stay running, first time it came up and was fine - until I threw my .g files at it and then BOOM ....

I need to get the whole thing back to RC6 and stable but right now it is all turned off (day job - that and run out of patience for now).

Could really do with that 'version compatibility' matrix ....

gtj0

@Danal When your print is done it's be helpful if you could test without DuetLapse and see if you can reproduce the issue, then try removing the CPUScheduling lines.

gtj0

@Garfield Understood. If you do get a chance, try removing those 2 lines.

A Former User

@Garfield said in DCS Crash with 3.01-R10 / DWC 2.1.5 / DSF 2.1.1:

back to RC6

Could really do with that 'version compatibility' matrix ....

@bearer said in DCS Crash with 3.01-R10 / DWC 2.1.5 / DSF 2.1.1:

RRF3.01-RC10     duetsoftwareframework 2.1.1      reprapfirmware 2.1.1-1
RRF3.01-RC9      duetsoftwareframework 2.1.0      reprapfirmware 2.1.0-1
RRF3.01-RC8      duetsoftwareframework 2.0.0      reprapfirmware 2.0.0-1
RRF3.01-RC7      duetsoftwareframework 1.3.2      reprapfirmware 1.3.2-1
RRF3.01-RC6      duetsoftwareframework 1.3.1      reprapfirmware 1.3.1-1
RRF3.01-RC6      duetsoftwareframework 1.3.0      reprapfirmware 1.3.0-1
RRF3.01-RC4      duetsoftwareframework 1.2.5.0    reprapfirmware 1.2.5.0-1
RRF3.0           duetsoftwareframework 1.2.4.0    reprapfirmware 1.2.4.0-1
RRF3.0           duetsoftwareframework 1.2.3.1    reprapfirmware 1.2.3.1-1
RRF3.0           duetsoftwareframework 1.2.3.0    reprapfirmware 1.2.3.0-1
RRF3.0           duetsoftwareframework 1.2.2.1    reprapfirmware 1.2.2.1-1
RRF3.0RC2+1      duetsoftwareframework 1.2.2.0    reprapfirmware 1.2.2.0-1
RRF3.0RC1        duetsoftwareframework 1.2.1.0    reprapfirmware 1.2.1.0-1
RRF3.0RC1        duetsoftwareframework 1.2.0.0    reprapfirmware 1.2.0.0-1
RRF3.0beta11     duetsoftwareframework 1.1.0.5    reprapfirmware 1.1.0.5-1
RRF3.0beta11     duetsoftwareframework 1.1.0.4    reprapfirmware 1.1.0.4-1
RRF3.0beta10+2   duetsoftwareframework 1.1.0.3    reprapfirmware 1.1.0.3-1
RRF3.0beta10+2   duetsoftwareframework 1.1.0.2    reprapfirmware 1.1.0.2-1
RRF3.0beta10+2   duetsoftwareframework 1.1.0.1    reprapfirmware 1.1.0.1-1
RRF3.0beta10+2   duetsoftwareframework 1.1.0.0    reprapfirmware 1.1.0.0-1
RRF3.0beta10+1   duetsoftwareframework 1.0.4.1    reprapfirmware 1.0.4.1-1

depcheck()
{
  local NODE=$1
  local VER=$2
  local pattern="\ ([a-z]*)\ \([0-9]+\ ([0-9\.]+-?[0-9]{0,2})\)"
  local IFS=$'\n'
  s=$(apt-cache showpkg $NODE |  grep "^$VER - ." )
  for package in $(echo $s | grep -Eo  $pattern)
  do
    [[ $package =~ $pattern ]]
    [ "${BASH_REMATCH[1]}" == "${BASH_REMATCH[2]}" ] || echo -en "  ${BASH_REMATCH[1]}=${BASH_REMATCH[2]} $EOL"
    [ "${BASH_REMATCH[1]}" == "duetcontrolserver" ] && depcheck ${BASH_REMATCH[1]} ${BASH_REMATCH[2]}
  done
}

[ $# -gt 0 ] && {
V=$1
PARENT=duetsoftwareframework
[ $# -gt 1 ] && PARENT=$2
EOL=""
[ -t 1 ] && EOL="\\ \n"
echo  -en "sudo apt install $EOL"
depcheck $PARENT $V
[ -t 1 ] && EOL="\n"
echo  -en "  $PARENT=$V $EOL"
} ||  echo $0 version ;

save as dsfdep.sh and run like bash dsfdep.sh 1.3.1 to restore to 3.01-RC6
copy and paste the suggest command and hope for the best (or put in backticks if braver than most)

pi@raspberrypi:~ $ bash dsfdep.sh 1.3.1
sudo apt install \
  duetcontrolserver=1.3.1 \
  duetruntime=1.3.1 \
  duetsd=1.0.6 \
  duettools=1.3.1 \
  duetwebserver=1.3.1 \
  duetwebcontrol=2.1.1 \
  reprapfirmware=1.3.1-1 \
  duetsoftwareframework=1.3.1

Danal

@gtj0 said in DCS Crash with 3.01-R10 / DWC 2.1.5 / DSF 2.1.1:

@Danal When your print is done it's be helpful if you could test without DuetLapse and see if you can reproduce the issue, then try removing the CPUScheduling lines.

Will do.

May do a different print, this one is running MUCH longer than I anticipated. It is a toolchanger multi-material, and "estimators" do not (yet) account for the time spent changing tools. There are 1045 changes in this print.

Danal

@Garfield said in DCS Crash with 3.01-R10 / DWC 2.1.5 / DSF 2.1.1:

Could really do with that 'version compatibility' matrix ....

I'm working on a script that generates one. No promises as to when... lots of learning and research on my part.

In fact, if anyone else is working on one, I'll stop.