RepRapFirmware 3.01-RC6 released

ChrisP

@bearer said in RepRapFirmware 3.01-RC6 released:

@ChrisP said in RepRapFirmware 3.01-RC6 released:

Is there a was that I can issue M122 and grab the result from the Pi as when the crashed happen

log in using ssh and do echo M122 | sudo /opt/dsf/bin/CodeConsole should work if DuetControlServer is still running, if that is not the case, you'll need to connect to the Duets micro USB port and use it as a serial console.

Don't know why I didn't think of the USB console - this is how I always debug 0.6 and Duet 2s... duh! Interestingly, the service dump mentioned a depreciated firmware, so here's the M122 log that I hope shows this isn't the case...

4/4/2020, 12:36:36 PM	M122
=== Diagnostics ===
RepRapFirmware for Duet 3 MB6HC version 3.01-RC6 running on Duet 3 MB6HC v0.6 or 1.0
Board ID: 08DJM-956L2-G43S8-6J1FJ-3SD6M-9S3GF
Used output buffers: 1 of 40 (10 max)
=== RTOS ===
Static ram: 154084
Dynamic ram: 160852 of which 24 recycled
Exception stack ram used: 216
Never used ram: 78040
Tasks: NETWORK(ready,2084) HEAT(blocked,1196) CanReceiv(suspended,3820) CanSender(suspended,1488) CanClock(blocked,1436) TMC(blocked,216) MAIN(running,4736) IDLE(ready,76)
Owned mutexes:
=== Platform ===
Last reset 00:04:26 ago, cause: software
Last software reset at 2020-04-04 12:30, reason: User, spinning module LinuxInterface, available RAM 77332 bytes (slot 1)
Software reset code 0x0010 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0444a000 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 44.2, current 44.9, max 45.0
Supply voltage: min 11.9, current 12.0, max 12.1, under voltage events: 0, over voltage events: 0, power good: yes
12V rail voltage: min 11.1, current 11.3, max 11.3, under voltage events: 0
Driver 0: standstill, reads 7684, writes 14 timeouts 0, SG min/max 0/0
Driver 1: standstill, reads 7684, writes 14 timeouts 0, SG min/max 0/0
Driver 2: standstill, reads 7685, writes 14 timeouts 0, SG min/max 0/0
Driver 3: standstill, reads 7686, writes 13 timeouts 0, SG min/max 0/0
Driver 4: standstill, reads 7687, writes 12 timeouts 0, SG min/max 0/0
Driver 5: standstill, reads 7688, writes 12 timeouts 0, SG min/max 0/0
Date/time: 2020-04-04 12:36:38
Slowest loop: 3.61ms; fastest: 0.21ms
=== 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  CDDA state: -1
=== AuxDDARing ===
Scheduled moves: 0, completed moves: 0, StepErrors: 0, LaErrors: 0, Underruns: 0, 0  CDDA state: -1
=== Heat ===
Bed heaters = 0 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1, chamberHeaters = -1 -1 -1 -1
=== GCodes ===
Segments left: 0
Movement lock held by null
HTTP* is ready with "M122" in state(s) 0
Telnet is idle in state(s) 0
File is idle in state(s) 0
USB is idle in state(s) 0
Aux is idle in state(s) 0
Trigger* is idle in state(s) 0
Queue is idle in state(s) 0
LCD is idle in state(s) 0
SBC is idle in state(s) 0
Daemon* is idle in state(s) 0
Autopause is idle in state(s) 0
Code queue is empty.
=== Network ===
Slowest loop: 0.47ms; 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: disabled
Error counts: 0 0 0 0 0
Socket states: 0 0 0 0 0 0 0 0
=== CAN ===
Messages sent 1018, longest wait 0ms for type 0
=== Linux interface ===
State: 0, failed transfers: 1
Last transfer: 16ms ago
RX/TX seq numbers: 8175/8176
SPI underruns 0, overruns 0
Number of disconnects: 0
Buffer RX/TX: 0/0-0
=== Duet Control Server ===
Duet Control Server v1.3.0.0
Code buffer space: 4096
Configured SPI speed: 8000000 Hz
Full transfers per second: 31.72

A Former User

@ChrisP said in RepRapFirmware 3.01-RC6 released:

this is how I always debug 0.6 and Duet 2s

easy to loose sight of the trees in the forrest i guess

timeout 1 cat /dev/ttyACM0 & echo -e "\nM122" > /dev/ttyACM0

should get you the M122 from serial as a one line copy/paste if you should need it (as opposed to installing the less than user friendly console based serial terminals available for the pi)

chrishamm

Thanks but this M122 output doesn't show anything unusual either. Btw, you can keep a log session going when you start a print by running sudo journalctl -u duetcontrolserver -f. This way, all the events from DCS are sent to your console window.

ChrisP

@bearer said in RepRapFirmware 3.01-RC6 released:

@ChrisP said in RepRapFirmware 3.01-RC6 released:

this is how I always debug 0.6 and Duet 2s

easy to loose sight of the trees in the forrest i guess

timeout 1 cat /dev/ttyACM0 & echo -e "\nM122" > /dev/ttyACM0

should get you the M122 from serial as a one line copy/paste if you should need it (as opposed to installing the less than user friendly console based serial terminals available for the pi)

100%
Yeh, I've got Termite on a Windows PC, so I can avoid conole based serial terminals

@chrishamm said in RepRapFirmware 3.01-RC6 released:

Thanks but this M122 output doesn't show anything unusual either. Btw, you can keep a log session going when you start a print by running sudo journalctl -u duetcontrolserver -f. This way, all the events from DCS are sent to your console window.
Cool!

The print has now got past where it did last time, annoyingly.
If it is was just the PanelDue causing the issue this time, is it any use to you if I plug it back in to force crashes and post the logs, or not? Or do we just accept that eh PannelDUe is currently dead for this release?

edit: I've noticed that the Layer Chart remains blank during printing...?

droftarts

@chrishamm @dc42 see https://forum.duet3d.com/post/143464 earlier in thread. Says layer time is still wrong. Saw it was supposed to be fixed in 3.01-RC6 release notes. Any suggestions?

@Marco-Bona The only thing I can think of is to clear browser cache?

Ian

chrishamm

I've just released DWC 2.1.1 (see https://forum.duet3d.com/topic/15342/duet-web-control-2-1-1-released) and DSF 1.3.1 (see https://forum.duet3d.com/topic/15343/dsf-1-3-1-unstable-released). Please use the corresponding threads for DWC and DSF-related support and this one only for issues involving the firmware.

dc42

@droftarts said in RepRapFirmware 3.01-RC6 released:

@chrishamm @dc42 see https://forum.duet3d.com/post/143464 earlier in thread. Says layer time is still wrong. Saw it was supposed to be fixed in 3.01-RC6 release notes. Any suggestions?

@Marco-Bona The only thing I can think of is to clear browser cache?

Ian

The issue I thought we were talking about is this one https://forum.duet3d.com/post/142804 whereby the firmware behaves as if the first layer (and the whole print) started when the printer was powered up. I believe that is fixed. Is there another issue with layer times?

wilriker

For everyone having unexplainable problems using SBC ( @chas2706 might fall under that) AND using my Exec On MCode tool please see: https://forum.duet3d.com/post/143593

ChrisP

Im assuming this is a firmware related issue rather that a DSF issue, but I'm not sure.

I've noticed that on powerup, the printer clearly isn't parsing filaments.csv properly as it forgets what filament is loaded. The csv file is there and has the correct information, but the web interface shows no filament is loaded and M701 returns "No filament loaded in the selected tool".

I'm currently running 3.01-RC6 with DSF 1.3.1

edit: loading filament sitll fails to show it on the web interface, but M701 reports correctly

gruen

I have upgrade from a fresh raspberry image to RC6. Now I would print, upload works then
Failed to connect to duet3.
DCS is not startet.

Apr 05 12:29:59 Duet3 DuetControlServer[2388]: Duet Control Server v1.3.1
Apr 05 12:29:59 Duet3 DuetControlServer[2388]: Written by Christian Hammacher for Duet3D
Apr 05 12:29:59 Duet3 DuetControlServer[2388]: Licensed under the terms of the GNU Public License Version 3
Apr 05 12:30:00 Duet3 DuetControlServer[2388]: [info] Settings loaded
Apr 05 12:30:00 Duet3 DuetControlServer[2388]: [info] Environment initialized
Apr 05 12:30:00 Duet3 DuetControlServer[2388]: [warn] Bad data checksum (expected 0x31c7, got 0xe55f)
Apr 05 12:30:00 Duet3 DuetControlServer[2388]: [warn] Bad data checksum (expected 0x31c7, got 0xe55f)
Apr 05 12:30:00 Duet3 DuetControlServer[2388]: [warn] Bad data checksum (expected 0x31c7, got 0xe55f)
Apr 05 12:30:00 Duet3 DuetControlServer[2388]: [warn] Restarting transfer because the number of maximum retries has been exceeded
Apr 05 12:30:00 Duet3 DuetControlServer[2388]: [error] Duet is not available
Apr 05 12:30:00 Duet3 systemd[1]: duetcontrolserver.service: Succeeded.
Apr 05 12:30:06 Duet3 systemd[1]: duetcontrolserver.service: Service RestartSec=5s expired, scheduling restart.
Apr 05 12:30:06 Duet3 systemd[1]: duetcontrolserver.service: Scheduled restart job, restart counter is at 75.
Apr 05 12:30:06 Duet3 systemd[1]: Stopped Duet Control Server.
Apr 05 12:30:06 Duet3 systemd[1]: Started Duet Control Server.
Apr 05 12:30:06 Duet3 DuetControlServer[2405]: Duet Control Server v1.3.1
Apr 05 12:30:06 Duet3 DuetControlServer[2405]: Written by Christian Hammacher for Duet3D
Apr 05 12:30:06 Duet3 DuetControlServer[2405]: Licensed under the terms of the GNU Public License Version 3
Apr 05 12:30:07 Duet3 DuetControlServer[2405]: [info] Settings loaded
Apr 05 12:30:07 Duet3 DuetControlServer[2405]: [info] Environment initialized
Apr 05 12:30:07 Duet3 DuetControlServer[2405]: [warn] Bad data checksum (expected 0x31c7, got 0xe55f)
Apr 05 12:30:07 Duet3 DuetControlServer[2405]: [warn] Bad data checksum (expected 0x31c7, got 0xe55f)
Apr 05 12:30:07 Duet3 DuetControlServer[2405]: [warn] Bad data checksum (expected 0x31c7, got 0xe55f)
Apr 05 12:30:07 Duet3 DuetControlServer[2405]: [warn] Restarting transfer because the number of maximum retries has been exceeded
Apr 05 12:30:07 Duet3 DuetControlServer[2405]: [error] Duet is not available
Apr 05 12:30:07 Duet3 systemd[1]: duetcontrolserver.service: Succeeded.
Apr 05 12:30:13 Duet3 systemd[1]: duetcontrolserver.service: Service RestartSec=5s expired, scheduling restart.
Apr 05 12:30:13 Duet3 systemd[1]: duetcontrolserver.service: Scheduled restart job, restart counter is at 76.
Apr 05 12:30:13 Duet3 systemd[1]: Stopped Duet Control Server.
Apr 05 12:30:13 Duet3 systemd[1]: Started Duet Control Server.
Apr 05 12:30:13 Duet3 DuetControlServer[2418]: Duet Control Server v1.3.1
Apr 05 12:30:13 Duet3 DuetControlServer[2418]: Written by Christian Hammacher for Duet3D
Apr 05 12:30:13 Duet3 DuetControlServer[2418]: Licensed under the terms of the GNU Public License Version 3

Power cycle doesn't work!

chas2706

@wilriker said in RepRapFirmware 3.01-RC6 released:

For everyone having unexplainable problems using SBC ( @chas2706 might fall under that) AND using my Exec On MCode tool please see: https://forum.duet3d.com/post/143593

Thanks for the info.
I use your Exec On MCode so I definitely fall into that category.

gruen

I'm back on RC5.

gtj0

If you're having issues with connections between the DSF and the Duet3, check this out...
https://forum.duet3d.com/post/143792

gruen

I'm waiting for RC7.

dc42

@gruen said in RepRapFirmware 3.01-RC6 released:

I'm waiting for RC7.

There are no plans for a RRF 3.01-RC7 release, because there are no known bugs in 3.01-RC6 known yet other than the limitations described in the whatsnew-rrf3 file.

tobias_munich

RC6 works for me in standalone mode and is stable.
SBC mode is still unstable.
think the reason is still the current version of the duet framework.

jmjcoke

I have tried, sudo service duetcontrolserver restart and I still have Drive is unmounted. Any help on how I can goto RC5 from here, I cannot seem to get duetframework to anything but 1.3.1.

tobias_munich

@jmjcoke the problem is not RC6, it’s the Duetframework.
if you run RC6 in stand-alone mode you shoudnt have issues.

SpoonUnit

Successfully setup and printed with RC6. Only issue is that my kill switch isn't working. It's setup with this, to invoke trigger2.g:

M581 P"duex.e2stop" S1 T2 C0

Trigger 2 is working if I invoke with M98, and M999 (the only command in the trigger) also does it's job. I've tried all 4 permutations of the command that seem to make sense:

M581 P"duex.e2stop" S1 T2 C0
M581 P"duex.e2stop" S0 T2 C0
M581 P"!duex.e2stop" S1 T2 C0
M581 P"!duex.e2stop" S0 T2 C0

None of them result in activation of the trigger when the button is pressed.

The command executes fine from the console, and worked as intended with RC1. I can't see any reference in the notes for each release between RC1 and RC6 for this, but could have missed something.

Is there a way to simply report on the state of a given pin?

This output doesn't give me confidence it's been made available, but I never needed to investigate to this depth previously, so I'm not sure what the output in RC1 was:

M409 K"sensors.endstops" F"v"

{"key":"sensors.endstops","flags":"v","result":[{"triggered":false,"type":"inputPin"},{"triggered":false,"type":"inputPin"},null,{"triggered":false,"type":"motorStallAny"}]}

I'm not sure where else in the object model to look. Could this be it?

M409 K"inputs[5]" F"v"

{"key":"inputs[5]","flags":"v","result":{"axesRelative":false,"compatibility":"RepRapFirmware","distanceUnit":"mm","drivesRelative":false,"feedRate":50.0,"inMacro":false,"lineNumber":0,"name":"Trigger","stackDepth":0,"state":"idle","volumetric":false}}

If so, I don't see any key there for the value.

Any help appreciated.

deckingman

@SpoonUnit Something did change with M581. I'm on a phone right now so not easy for me to say exactly what. IIRC you need to add an M950 with a (I think) J parameter.