RepRapFirmware 3.01-RC6 released
-
I'm sorry that there are some issues with upgrading to the new RRF/DWC/DSF. There have been many major changes, especially to DSF and DWC which now support almost the full object model.
Here's a summary of issues we are aware of with upgrading to RRF 3.01-RC6, DWC 2.1.0 and DSF 1.3.0.
- DWC issue: extrude/retract buttons greyed out when they shouldn't be. Workaround: if you need those buttons, use DWC 2.0.7.
- DWC issue: when you click on a heater in the Fault state there is a new dialog that allows you to reset the fault; but the heater fault reset doesn't work.
- Upgrading RRF+DSF+DWC on Duet 3 with attached RPi does not always go smoothly.
- DSF issue: laser and magnetic filament monitors without a filament present switch are not handled. Workaround: add 1 to the filament monitor type (M591 P parameter) to say that a filament present switch is present, and put a jumper across the filament present switch pins to simulate the presence of filament.
We are preparing a new DWC release (2.1.1) to address #1 and #2, and a new DSF release (1.3.1) to address #4. Chrishamm will provide new instructions to address #3. I will then lock this thread and we will start two new threads: one for issues users are having using the new release on Duet 3 + SBC, and one for other users.
-
for me work this to upgrade my sbc:
apt remove duetsoftwareframework duetcontrolserver duetsd duettools duetwebserver duetwebcontrol reprapfirmware
and install with
apt install duetsoftwareframework duetcontrolserver duetsd duettools duetwebserver duetwebcontrol reprapfirmware
-
@droftarts, I send you the DWC screen, as you can see nothing has changed since the previous build.
The only doubt is that there is something at the beginning of the file that creates some noise.M117 Preparing ;write Preparing G4 S2 ;delay 2 seconds M140 S60 ;set bed temperature and move on M141 S0 ;set heated chamber temperature and move on M104 T0 S195 ;wait for the extruder to reach desired temperature M107 ;start with the fan off G28 ;home all axes T0 ;select tool 0 G1 X-23 Y-24 F10000 ;go to the center of bed G1 Z10 F1000 ;E go to Z10 M107 P0 ;turn off leds G30 X-23 Y-24 S-2 H1.915 ;probe current position and ajust Z offset G1 Z40 F1000 ;E go to Z40 M106 P0 S1 ;turn on leds T0 ;reset current tool M584 P4 ;apply custom setting G1 X-87 Y160 F10000 ;go to X-87 Y160 M117 Spray print adhesive ;write Spray print adhesive G4 S2 ;delay 2 seconds M226 ;pause M190 S60 ;wait for the bed to reach desired temperature M109 S205 ;wait for the extruder to reach desired temperature G1 U130 F10000 ;go to U130 G92 E0 ;reset the extruder position G1 X-137 E25 F500 ;move to X-137 and extrude 25mm of feed stock G92 E0 ;reset the extruder position G1 E-4 F5000 ;retract 4mm G1 X-187 F500 ;go to X-187 G1 Y165 F500 ;go to Y165 G10 ;retract G1 X-137 F500 ;go to X-137 and clean nozzle G1 XO Y0 U0 F10000 ;go to X0 Y0 U0 M584 P3 ;apply custom setting G21 ;metric values G90 ;absolute positioning M117 Print starting ;write Print starting G4 S2 ;delay 2 seconds G92 E0 ;reset the extruder position G1 E4 F500 ;unretract 4mm G11 ;unretract
I am attaching the file to verify.
HA_Rudder.gcode -
@Marco-Bona can you confirm youโre using the latest firmware and DWC versions? Shown on System tab of DWC. I have not had a chance to test if the layer time problem is fixed.
Ian
-
@droftarts, I confirm, I am using DWC 2.1.0, I have updated to RRF3.01 RC6 and DuetWiFiServer 1.23.
M115 FIRMWARE_NAME: RepRapFirmware for Duet 2 WiFi/Ethernet FIRMWARE_VERSION: 3.01-RC6 ELECTRONICS: Duet WiFi 1.02 or later + DueX5 FIRMWARE_DATE: 2020-04-03b3
-
@dc42 thanks for your clear statement. have a nice weekend.
-
@dc42
I've just stumbled across another odd error.
I had just started a print but a bit of purge material got caught on the head so I paused the print (I have a hardware button and use the input to trigger a pause using M581).On first press of the button, all motion stopped instantly but the pause script (below) wasn't executed. I pressed the button again and the notification to say that the print had been paused be external trigger showed but the head still didn't move out of the way.
; Pause macro file M83 ; relative extruder movements G1 E-3 F2500 ; retract 3mm G91 ; relative moves G1 Z10 F5000 ; raise nozzle 10mm G90 ; absolute moves G1 X0 Y110 F5000 ; move head out of the way of the print
I then pressed Emergency Stop on the web interface at which point the web interface said it was tying to reconnect, but it never came back to life. I tried moving the axis by hand to move the hot nozzle off the print but all the axis motors were sitll powered and holding. I took the following dump fron the DCS service log on the SBC:
Apr 04 11:25:18 starttex DuetControlServer[360]: [info] Aux: Running code from firmware 'M20 S2 P0:/macros' on channel Aux Apr 04 11:25:28 starttex DuetControlServer[360]: [info] Aux: Running code from firmware 'M20 S2 P0:/macros' on channel Aux Apr 04 11:25:38 starttex DuetControlServer[360]: [info] Aux: Running code from firmware 'M20 S2 P0:/macros' on channel Aux Apr 04 11:25:46 starttex DuetControlServer[360]: [info] Aux: Running code from firmware 'M20 S2 P0:/macros' on channel Aux Apr 04 11:25:50 starttex DuetControlServer[360]: [info] Selected file /opt/dsf/sd/gcodes/Test Parts/20x20x10 8dia hole.gcode Apr 04 11:25:50 starttex DuetControlServer[360]: [info] Starting file print Apr 04 11:25:50 starttex DuetControlServer[360]: [info] File: Optional macro file start.g not found Apr 04 11:25:50 starttex DuetControlServer[360]: [info] Executing nested macro file pre_print.g on channel File Apr 04 11:25:51 starttex DuetControlServer[360]: [info] Executing nested macro file homeall.g on channel File Apr 04 11:25:51 starttex DuetControlServer[360]: [info] Executing nested macro file homez.g on channel File Apr 04 11:25:54 starttex DuetControlServer[360]: [info] File: Finished macro file homez.g Apr 04 11:25:54 starttex DuetControlServer[360]: [info] Aux: Running code from firmware 'M20 S2 P0:/macros' on channel Aux Apr 04 11:25:54 starttex DuetControlServer[360]: [info] Executing nested macro file homex.g on channel File Apr 04 11:25:55 starttex DuetControlServer[360]: [info] File: Finished macro file homex.g Apr 04 11:25:55 starttex DuetControlServer[360]: [info] Executing nested macro file homey.g on channel File Apr 04 11:25:59 starttex DuetControlServer[360]: [info] File: Finished macro file homey.g Apr 04 11:26:01 starttex DuetControlServer[360]: [info] File: Finished macro file homeall.g Apr 04 11:26:01 starttex DuetControlServer[360]: [info] Executing nested macro file tfree0.g on channel File Apr 04 11:26:02 starttex DuetControlServer[360]: [info] File: Finished macro file tfree0.g Apr 04 11:26:02 starttex DuetControlServer[360]: [info] Executing nested macro file tpre0.g on channel File Apr 04 11:26:02 starttex DuetControlServer[360]: [info] File: Finished intermediate macro file tpre0.g Apr 04 11:26:02 starttex DuetControlServer[360]: [info] Executing nested macro file tpost0.g on channel File Apr 04 11:26:02 starttex DuetControlServer[360]: [info] Executing nested macro file config.g on channel File Apr 04 11:26:02 starttex DuetControlServer[360]: [info] File: Finished macro file config.g Apr 04 11:26:02 starttex DuetControlServer[360]: [info] Aux: Running code from firmware 'M20 S2 P0:/macros' on channel Aux Apr 04 11:26:02 starttex DuetControlServer[360]: [info] File: Finished macro file tpost0.g Apr 04 11:26:02 starttex DuetControlServer[360]: [info] Executing nested macro file tfree0.g on channel File Apr 04 11:26:03 starttex DuetControlServer[360]: [info] File: Finished macro file tfree0.g Apr 04 11:26:10 starttex DuetControlServer[360]: [info] Aux: Running code from firmware 'M20 S2 P0:/macros' on channel Aux Apr 04 11:26:18 starttex DuetControlServer[360]: [info] Aux: Running code from firmware 'M20 S2 P0:/macros' on channel Aux Apr 04 11:26:26 starttex DuetControlServer[360]: [info] Aux: Running code from firmware 'M20 S2 P0:/macros' on channel Aux Apr 04 11:26:35 starttex DuetControlServer[360]: [info] Aux: Running code from firmware 'M20 S2 P0:/macros' on channel Aux Apr 04 11:31:16 starttex DuetControlServer[360]: [info] File: Finished macro file pre_print.g Apr 04 11:31:17 starttex DuetControlServer[360]: [info] Aux: Running code from firmware 'M20 S2 P0:/macros' on channel Aux Apr 04 11:31:18 starttex DuetControlServer[360]: [info] Executing nested macro file purge.g on channel File Apr 04 11:31:18 starttex DuetControlServer[360]: [info] File: Finished macro file purge.g Apr 04 11:31:18 starttex DuetControlServer[360]: [info] Executing nested macro file wipe.g on channel File Apr 04 11:31:20 starttex DuetControlServer[360]: [info] File: Finished macro file wipe.g Apr 04 11:31:25 starttex DuetControlServer[360]: [info] Aux: Running code from firmware 'M20 S2 P0:/macros' on channel Aux Apr 04 11:31:33 starttex DuetControlServer[360]: [info] Aux: Running code from firmware 'M20 S2 P0:/macros' on channel Aux Apr 04 11:31:42 starttex DuetControlServer[360]: [info] Aux: Running code from firmware 'M20 S2 P0:/macros' on channel Aux Apr 04 11:31:50 starttex DuetControlServer[360]: [info] Aux: Running code from firmware 'M20 S2 P0:/macros' on channel Aux Apr 04 11:32:00 starttex DuetControlServer[360]: [info] Aux: Running code from firmware 'M20 S2 P0:/macros' on channel Aux Apr 04 11:32:10 starttex DuetControlServer[360]: [info] Aux: Running code from firmware 'M20 S2 P0:/macros' on channel Aux Apr 04 11:32:18 starttex DuetControlServer[360]: [info] Aux: Running code from firmware 'M20 S2 P0:/macros' on channel Aux Apr 04 11:32:18 starttex DuetControlServer[360]: [warn] Bad data checksum (expected 0x7222, got 0x7aaa) Apr 04 11:32:18 starttex DuetControlServer[360]: [warn] Bad data checksum (expected 0x7222, got 0x7aaa) Apr 04 11:32:18 starttex DuetControlServer[360]: [warn] Bad data checksum (expected 0x7222, got 0x7aaa) Apr 04 11:32:18 starttex DuetControlServer[360]: [warn] Restarting transfer because the number of maximum retries has been exceeded Apr 04 11:32:18 starttex DuetControlServer[360]: [warn] Bad data checksum (expected 0x7222, got 0x7aaa) Apr 04 11:32:18 starttex DuetControlServer[360]: [warn] Bad data checksum (expected 0x7222, got 0x7aaa) Apr 04 11:32:18 starttex DuetControlServer[360]: [warn] Restarting transfer because the number of maximum retries has been exceeded Apr 04 11:32:18 starttex DuetControlServer[360]: [warn] Bad data checksum (expected 0x7222, got 0x7aaa) Apr 04 11:32:18 starttex DuetControlServer[360]: [warn] Bad data checksum (expected 0x7222, got 0x7aaa) Apr 04 11:32:18 starttex DuetControlServer[360]: [warn] Restarting transfer because the number of maximum retries has been exceeded Apr 04 11:32:18 starttex DuetControlServer[360]: [warn] Bad data checksum (expected 0x7222, got 0x7aaa) Apr 04 11:32:18 starttex DuetControlServer[360]: [warn] Bad data checksum (expected 0x7222, got 0x7aaa)
I pressed the reset button on the Duet3 (by the power LEDs) and everything came back to life. I've since tried to recreate the issue, but can't unfortunately as yet.
The printer has been running solidly for days, so I'm not inclined to believe its a hardware or other setup issue at the moment.
update:
I've not just had it crash randomly mid-print. Web interface becomes unresponsive and service logs are full of:Apr 04 12:03:53 starttex DuetControlServer[360]: [warn] Bad data checksum (expected 0x92b3, got 0x23e3) Apr 04 12:03:53 starttex DuetControlServer[360]: [warn] Bad data checksum (expected 0x92b3, got 0x23e3) Apr 04 12:03:53 starttex DuetControlServer[360]: [warn] Bad data checksum (expected 0x92b3, got 0x23e3) Apr 04 12:03:53 starttex DuetControlServer[360]: [warn] Restarting transfer because the number of maximum retries has been exceeded
I also seem to be getting lots of this. Which is confusing as I don't have the macros page open on anything...?
Apr 04 12:02:45 starttex DuetControlServer[360]: [info] Aux: Running code from firmware 'M20 S2 P0:/macros' on channel Aux
-
@ChrisP It looks like you have a PanelDue connected to your Duet 3 and that is not fully supported yet while the Duet 3 is operating in SBC mode. At present the only transmitted command from the firmware to DSF is M20 which you can see in the logs. So I suggest don't use the PanelDue for anything else than pausing prints (not resuming) or emergency stops in SBC mode until support for PanelDue has been fully implemented.
Can you share the output of M122 if you are certain the firmware reset unexpectedly?
-
@chrishamm
You are absolutely correct that I have a PanelDue connected I hadn't anticipated that this could be part of the problem since i'ts been connected since it has always been connected to the Duet3 from the first time I set it up over a few weeks ago. I was aware that it had limitations but have kept it there as an easy way to view teh temperatures and print progress - I don't use it for anything onther than displaying info currently. With previous firmwares / DCS it's been operating fine. That said, I'll take the advice and remove it for now.Is there a was that I can issue M122 and grab the result from the Pi as when the crashed happen, the web interface becomes totally unresponsive and requires me to press the hardware reset on the Duet3 to bring things back to life?
edit: I will unplug the PanelDue, power cycle and try the print again.... I'm only running test prints currently to ensure the system is stable... clearly not quite ready for a proper print yet
-
@ChrisP It sounds like there is a problem in DCS and I'll be happy to look into it. To obtain some debug info, please connect to your Pi via ssh, run
sudo journalctl -u duetcontrolserver -en 100 --no-pager
, and share the output you get.PS: It's fine to leave the PanelDue attached but be aware that most file-related commands will not work as expected.
-
@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. -
@chrishamm said in RepRapFirmware 3.01-RC6 released:
@ChrisP It sounds like there is a problem in DCS and I'll be happy to look into it. To obtain some debug info, please connect to your Pi via ssh, run
sudo journalctl -u duetcontrolserver -en 100 --no-pager
, and share the output you get.Thanks for the help. I'm running this as a test machine anyway, so I'm happy to test anything on it if it'll help move forward. Here's the log from a fresh boot (with PanelDue disconnected):
-- Logs begin at Thu 2019-02-14 10:11:59 GMT, end at Sat 2020-04-04 12:33:27 BST. -- Apr 04 12:28:50 starttex systemd[1]: Started Duet Control Server. Apr 04 12:28:52 starttex DuetControlServer[350]: Duet Control Server v1.3.0 Apr 04 12:28:52 starttex DuetControlServer[350]: Written by Christian Hammacher for Duet3D Apr 04 12:28:52 starttex DuetControlServer[350]: Licensed under the terms of the GNU Public License Version 3 Apr 04 12:28:54 starttex DuetControlServer[350]: [info] Settings loaded Apr 04 12:28:55 starttex DuetControlServer[350]: [info] Environment initialized Apr 04 12:28:55 starttex DuetControlServer[350]: [warn] Downgrading protocol version 2 to 1 Apr 04 12:28:55 starttex DuetControlServer[350]: [warn] Incompatible firmware, please upgrade as soon as possible Apr 04 12:28:55 starttex DuetControlServer[350]: [info] Connection to Duet established Apr 04 12:28:55 starttex DuetControlServer[350]: [info] IPC socket created at /var/run/dsf/dcs.sock Apr 04 12:28:55 starttex DuetControlServer[350]: [info] Executing system macro file config.g on channel Trigger Apr 04 12:28:56 starttex DuetControlServer[350]: [warn] Deprecated firmware detected, please update it in order to use DSF Apr 04 12:28:56 starttex DuetControlServer[350]: [warn] Deprecated firmware detected, please update it in order to use DSF Apr 04 12:28:57 starttex DuetControlServer[350]: [info] Trigger: Finished system macro file config.g Apr 04 12:31:48 starttex DuetControlServer[350]: [info] System time has been changed Apr 04 12:32:05 starttex DuetControlServer[350]: [info] Flashing IAP binary Apr 04 12:32:05 starttex DuetControlServer[350]: [info] Flashing RepRapFirmware Apr 04 12:32:11 starttex DuetControlServer[350]: [info] Verifying checksum Apr 04 12:32:14 starttex DuetControlServer[350]: [info] Firmware update successful Apr 04 12:32:14 starttex DuetControlServer[350]: [fatal] Abnormal program termination Apr 04 12:32:14 starttex DuetControlServer[350]: [fatal] SPI task faulted Apr 04 12:32:14 starttex DuetControlServer[350]: System.Exception: Invalid protocol version 2 Apr 04 12:32:14 starttex DuetControlServer[350]: at DuetControlServer.SPI.DataTransfer.ExchangeHeader() in /home/christian/duet/DuetSoftwareFramework/src/DuetControlServer/SPI/DataTransfer.cs:line 1130 Apr 04 12:32:14 starttex DuetControlServer[350]: at DuetControlServer.SPI.DataTransfer.PerformFullTransfer(Boolean mustSucceed) in /home/christian/duet/DuetSoftwareFramework/src/DuetControlServer/SPI/DataTransfer.cs:line 157 Apr 04 12:32:14 starttex DuetControlServer[350]: at DuetControlServer.SPI.Interface.Run() in /home/christian/duet/DuetSoftwareFramework/src/DuetControlServer/SPI/Interface.cs:line 744 Apr 04 12:32:14 starttex DuetControlServer[350]: [fatal] SPI task faulted Apr 04 12:32:14 starttex DuetControlServer[350]: System.Exception: Invalid protocol version 2 Apr 04 12:32:14 starttex DuetControlServer[350]: at DuetControlServer.SPI.DataTransfer.ExchangeHeader() in /home/christian/duet/DuetSoftwareFramework/src/DuetControlServer/SPI/DataTransfer.cs:line 1130 Apr 04 12:32:14 starttex DuetControlServer[350]: at DuetControlServer.SPI.DataTransfer.PerformFullTransfer(Boolean mustSucceed) in /home/christian/duet/DuetSoftwareFramework/src/DuetControlServer/SPI/DataTransfer.cs:line 157 Apr 04 12:32:14 starttex DuetControlServer[350]: at DuetControlServer.SPI.Interface.Run() in /home/christian/duet/DuetSoftwareFramework/src/DuetControlServer/SPI/Interface.cs:line 744 Apr 04 12:32:14 starttex systemd[1]: duetcontrolserver.service: Succeeded. Apr 04 12:32:19 starttex systemd[1]: duetcontrolserver.service: Service RestartSec=5s expired, scheduling restart. Apr 04 12:32:19 starttex systemd[1]: duetcontrolserver.service: Scheduled restart job, restart counter is at 1. Apr 04 12:32:20 starttex systemd[1]: Stopped Duet Control Server. Apr 04 12:32:20 starttex systemd[1]: Started Duet Control Server. Apr 04 12:32:20 starttex DuetControlServer[1513]: Duet Control Server v1.3.0 Apr 04 12:32:20 starttex DuetControlServer[1513]: Written by Christian Hammacher for Duet3D Apr 04 12:32:20 starttex DuetControlServer[1513]: Licensed under the terms of the GNU Public License Version 3 Apr 04 12:32:21 starttex DuetControlServer[1513]: [info] Settings loaded Apr 04 12:32:22 starttex DuetControlServer[1513]: [info] Environment initialized Apr 04 12:32:22 starttex DuetControlServer[1513]: [info] Connection to Duet established Apr 04 12:32:22 starttex DuetControlServer[1513]: [info] IPC socket created at /var/run/dsf/dcs.sock Apr 04 12:32:22 starttex DuetControlServer[1513]: [info] Executing system macro file config.g on channel Trigger Apr 04 12:32:26 starttex DuetControlServer[1513]: [info] Trigger: Finished system macro file config.g
-
@ChrisP Thanks, please run that when DSF becomes unresponsive. So far nothing unusual in this excerpt.
-
@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
-
@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)
-
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. -
@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...?
-
@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
-
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.
-
@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?