New beta firmware 1.20beta7
-
Thanks for that report. I'll test it before I release beta 8. Please check using M115 that you really are running beta 7.
-
Below is the m115 report.
M115
FIRMWARE_NAME: RepRapFirmware for Duet WiFi FIRMWARE_VERSION: 1.20beta7 ELECTRONICS: Duet WiFi 1.0 FIRMWARE_DATE: 2017-11-11 -
Hi.
I'm trying to use Z baby stepping in 1.20beta7 and it seems that the offset is not stored and applied to further moves.
To test this I have set up Z home with a 2mm offset so the print will stat clearly in the air and then tryied to compensate it with M290 S-2 command. It lowered the Z axis by 2mm as expected for one segment then came back to the same height it was before the M290 command.
Is there something I'm missing? -
The offset will be lost when you power down the printer, or you home Z, or you probe the bed. Otherwise it should be preserved.
Babystepping is intended for small corrections, so the M290 command is limited to +/- 1mm.
-
I never noticed that before, but with the latest (1.20beta7) firmware I just had 3 occurrences of what looks like the firmware hanging and then being reset by the watchdog. This seem to be random and not reproducible (happened on different gcode files, and then I'm able to print the same file without any problems).
The symptoms are printer just stops mid-print after an hour or two of printing, and several seconds later the 24v power shuts down (I use separate standby 5v power supply) - I believe that's firmware restarting because of the watchdog.
Here is the output of M122 when I connected by USB after such failure:=== Diagnostics === Used output buffers: 1 of 32 (1 max) === Platform === RepRapFirmware for Duet WiFi version 1.20beta7 running on Duet WiFi 1.0 Board ID: 08DDM-9FAM2-LW4S8-6JTDD-3SJ6P-9MXBY Static ram used: 15472 Dynamic ram used: 99144 Recycled dynamic ram: 72 Stack ram used: 3992 current, 5012 maximum Never used ram: 11372 Last reset 00:01:15 ago, cause: reset button or watchdog Last software reset reason: User, spinning module GCodes, available RAM 11568 bytes (slot 3) Software reset code 0x0003, HFSR 0x00000000, CFSR 0x00000000, ICSR 0x00400000, BFAR 0xe000ed38, SP 0xffffffff Error status: 0 Free file entries: 10 SD card 0 detected, interface speed: 20.0MBytes/sec SD card longest block write time: 0.0ms MCU temperature: min 31.6, current 35.5, max 35.7 Supply voltage: min 0.4, current 0.5, max 24.3, under voltage events: 1, over voltage events: 0 Driver 0: standstill Driver 1: standstill Driver 2: standstill Driver 3: standstill Driver 4: standstill Date/time: 1970-01-01 00:00:00 Cache data hit count 259223121 Slowest main loop (seconds): 0.001733; fastest: 0.000033 === Move === MaxReps: 0, StepErrors: 0, FreeDm: 240, MinFreeDm 240, MaxWait: 0ms, Underruns: 0, 0 Scheduled moves: 0, completed moves: 0 Bed compensation in use: none Bed probe heights: 0.000 0.000 0.000 0.000 0.000 === Heat === Bed heater = 0, chamber heater = -1 Heater 1 is on, I-accum = 0.0 === GCodes === Segments left: 0 Stack records: 2 allocated, 0 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 queue is idle in state(s) 0 autopause is idle in state(s) 0 Code queue is empty. Network state is running WiFi module is connected to access point Failed messages: pending 0, notready 0, noresp 0 WiFi firmware version 1.20b8 WiFi MAC address _WiFi Vcc 3.35, reset reason Turned on by main processor WiFi flash size 4194304, free heap 28824 WiFi IP address 192.168.1.102 WiFi signal strength -53dBm, reconnections 0, sleep mode modem HTTP sessions: 0 of 8 Socket states: 0 0 0 0 0 0 0 0 Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0)_ -
No, I don't think it's order-related. Try uploading wifiserver b8 again. If it gets stuck in "starting up" again, send M997 S1 again to reinstall the same file and see if that fixes it.
Uploaded wifiserver b8 after uploading 1.20 b7 firmware, and working normally. This was on a v1.00 duet wifi. My other machine with a v.102 duetwifi upgraded without a problem.
-
The issue described in https://www.duet3d.com/forum/thread.php?pid=30376#p30376 still happens after the upgrade to 1.20beta8
-
Thanks for your report. It does look like a watchdog reset. Prior to installing 1.20b7, what was the last firmware version you used that you are confident did not have this problem?
-
Last version I'm pretty sure was stable is the one I built myself, immediately after I added the 3-wire PT100 support. I've spent maybe 20 hours printing on that version, and didn't see any resets. The next one (was that 1.20beta6?) also never reset, but I spent only couple of hours printing with it, so less confident.
-
I wonder if this is related to the WiFi disconnections. I've looked at the assertion that produces that p->ref==1 message. If that indicates any sort of memory corruption, the watchdog reset could happen irrespective to your recent changes in the code. It might be that because of totally unrelated changes the compiler optimised something slightly differently, and it started to cause side-effects that weren't there before.
