Problems after updating firmware
-
@samlogan87 When it misbehaves, can you run M122. Your symptoms are very similar to those that can occur if you get I2C errors. This should be fixed in 2.03 - read the notes here https://github.com/dc42/RepRapFirmware/blob/dev/WHATS_NEW.md.
So run M122 when it misbehaves and post what is reported for I2C.
-
Hi @deckingman i can’t now. I can’t connect to it via Ethernet and the panel due can not find the board either. Just about to try connecting via USB.
Kind Regards,
Sam
-
HI @dc42 and @deckingman
So I can connect to it via usb. There were lights on the ethernet port and Yat said that the ethernet was running, however I could not connect to it.
Below is what I sent.
m115
FIRMWARE_NAME: RepRapFirmware for Duet 2 WiFi/Ethernet FIRMWARE_VERSION: 2.03 ELECTRONICS: Duet Ethernet 1.02 or later + DueX2 FIRMWARE_DATE: 2019-06-13b2<LF>
M552
Network is enabled, configured IP address: 192.168.1.40, actual IP address: 192.168.1.40<LF>Error: Attempt to move motors when VIN is not in range<LF>Error: Attempt to move motors when VIN is not in range<LF>Network running, IP address = 192.168.1.40<LF>
M552 S0
Network stopped<LF><LF>
M552 S0
<LF>
M552 S1
<LF>Network running, IP address = 192.168.1.40<LF>So what I did was to stop the ethernet, re enable it again and it started working. I can now connect to it and this time it has not wiped my config file, which I am happy about.
So it seems that something has gone haywire again. Am I best to format the sd card and start again? I am wondering if the issues I was having were due to something fishy going on
Kind Regards,
Sam
-
@samlogan87 I'd run it as is but as soon as something fishy happens, run M122 and post the result.
-
So I just got the printer standing back up (the board is under it) and started running my macro for bed leveling. It homed the X, y and z fine and then started heating. It managed to heat to the correct temp without rebooting. It is set to probe each point twice. It probed the first point once and paused in the touching position and then probed again. It did it again for the second point and then was fine for 3 and 4. It then did it again every other time. It took a while to get the m122 dump as the DWC locked up.
M122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 2.03 running on Duet Ethernet 1.02 or later + DueX2
Board ID: 08DGM-956GU-DJMSN-6J9D4-3SD6Q-1VR7G
Used output buffers: 3 of 24 (13 max)
=== RTOS ===
Static ram: 25680
Dynamic ram: 94088 of which 76 recycled
Exception stack ram used: 492
Never used ram: 10736
Tasks: NETWORK(ready,524) HEAT(blocked,1104) DUEX(suspended,156) MAIN(running,1668) IDLE(ready,160)
Owned mutexes:
=== Platform ===
Last reset 00:09:43 ago, cause: power up
Last software reset time unknown, reason: User, spinning module GCodes, available RAM 10908 bytes (slot 1)
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0441f000 BFAR 0xe000ed38 SP 0xffffffff Task 0x4e49414d
Error status: 0
Free file entries: 10
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest block write time: 0.0ms, max retries 0
MCU temperature: min 16.4, current 31.9, max 32.2
Supply voltage: min 24.1, current 24.2, max 24.4, under voltage events: 0, over voltage events: 0, power good: yes
Driver 0: standstill, SG min/max 0/117
Driver 1: standstill, SG min/max 0/1023
Driver 2: standstill, SG min/max not available
Driver 3: standstill, SG min/max not available
Driver 4: standstill, SG min/max not available
Driver 5: standstill, SG min/max not available
Driver 6: standstill, SG min/max not available
Date/time: 2019-08-05 20:45:41
Cache data hit count 1398330345
Slowest loop: 1097.98ms; fastest: 0.07ms
I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0
=== Move ===
Hiccups: 0, FreeDm: 169, MinFreeDm: 162, MaxWait: 243225ms
Bed compensation in use: none, comp offset 0.000
=== DDARing ===
Scheduled moves: 90, completed moves: 90, StepErrors: 0, LaErrors: 0, Underruns: 0, 0
=== Heat ===
Bed heaters = 1 -1 -1 -1, chamberHeaters = -1 -1
Heater 0 is on, I-accum = 0.1
Heater 1 is on, I-accum = 0.2
=== GCodes ===
Segments left: 0
Stack records: 3 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 idle 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 ===
Slowest loop: 542.30ms; fastest: 0.02ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) Telnet(0)
HTTP sessions: 1 of 8
Interface state 5, link 100Mbps full duplexSomething is not right and I have no idea where to go unfortunately.
Kind Regards,
Sam
-
just tried running it again and I am getting the same pausing between probes. M122 below
M122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 2.03 running on Duet Ethernet 1.02 or later + DueX2
Board ID: 08DGM-956GU-DJMSN-6J9D4-3SD6Q-1VR7G
Used output buffers: 1 of 24 (9 max)
=== RTOS ===
Static ram: 25680
Dynamic ram: 94088 of which 76 recycled
Exception stack ram used: 516
Never used ram: 10712
Tasks: NETWORK(ready,652) HEAT(blocked,1160) DUEX(suspended,156) MAIN(running,1668) IDLE(ready,160)
Owned mutexes:
=== Platform ===
Last reset 00:18:51 ago, cause: software
Last software reset at 2019-08-05 20:57, reason: User, spinning module GCodes, available RAM 10712 bytes (slot 3)
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0441f000 BFAR 0xe000ed38 SP 0xffffffff Task 0x4e49414d
Error status: 0
Free file entries: 10
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest block write time: 0.0ms, max retries 0
MCU temperature: min 29.6, current 32.6, max 35.5
Supply voltage: min 24.1, current 24.3, max 24.3, under voltage events: 0, over voltage events: 0, power good: yes
Driver 0: standstill, SG min/max 0/117
Driver 1: standstill, SG min/max 0/123
Driver 2: standstill, SG min/max not available
Driver 3: standstill, SG min/max not available
Driver 4: standstill, SG min/max not available
Driver 5: standstill, SG min/max not available
Driver 6: standstill, SG min/max not available
Date/time: 2019-08-05 21:15:56
Cache data hit count 2731265669
Slowest loop: 995.99ms; fastest: 0.07ms
I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0
=== Move ===
Hiccups: 0, FreeDm: 169, MinFreeDm: 162, MaxWait: 827462ms
Bed compensation in use: none, comp offset 0.000
=== DDARing ===
Scheduled moves: 90, completed moves: 90, StepErrors: 0, LaErrors: 0, Underruns: 0, 0
=== Heat ===
Bed heaters = 1 -1 -1 -1, chamberHeaters = -1 -1
Heater 0 is on, I-accum = 0.1
Heater 1 is on, I-accum = 0.2
=== GCodes ===
Segments left: 0
Stack records: 3 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 idle 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 ===
Slowest loop: 870.32ms; fastest: 0.02ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) Telnet(0)
HTTP sessions: 1 of 8
Interface state 5, link 100Mbps full duplexKind Regards,
Sam -
@samlogan87 It looks like it isn't anything to do with I2C as I suspected it might be. So that's good. Maybe DC42 can make something of the software reset report.
-
@deckingman yeah it was not showing the signs I have usually seen with the i2c errors but then again I have not had it for long enough to maybe see them all. Hopefully he can shed some light as I have a few things to print.
Kind Regards,
Sam
-
Sorry I know you are probably very busy, but do you have any ideas what I could be? It almost seems like it’s buffering between come operations like probing.
Kind Regards,
Sam
-
So a bit of an update. I took the SD card out and backed up the files on it. I then formatted it and put everything back over onto the card and it seems to be working ok. I wonder if something happened with the SD card. I have changed the card to a 16gb one now as well.
Kind Regards,
Sam -
Hey Everyone,
So there are a couple of other things that are happening now.
First I seem to have an issue with Z height and it is sporadic. Sometime after I run my macro, I do my usual baby stepping and it is fine and prints a nice first layer. Other times I run the macro and it homes, levels and then homes the z axis and when it goes to print, it is about 3mm above the surface. I cancel the print, and start it again without homing and it is fine. I do not run the macro. It is really confusing me now.
The other issue is my end g-code in cura runs a M84 which should shut all the motors off. It doesn't exactly do that. DWC says the motors need to be homed to be able to move, however you can still hear the hum of the motors. If I go into the console, and type M84, it turns the motors off.
@deckingman do you have any ideas what it could be.
Macro:
G28 XY ; Home XY
G28 Z ; Home Z
M190 S55 ; Heat bed to 55 Degrees and wait
M104 S130 ; Heat Extruder to 130
M109 S130 ; Heat Extruder to 130 degrees and wait
G1 Z10 ; Move Z 10mm down
M561 ; Clear any bed transform
G32 ; Start 4-point probe sequence
G28 Z ; Home Z
G1 X0 Y0 ; Move to HomeHere is my End GCode for Cura
; End Gcdoe
G10 P0 R-273.15 S-273.15 ; Turn off Tool0
M140 S-273.15 ; Turn off Bed
M106 S0 ; Object fan off
G92 E0 ; Zero Extruder
G1 E-6 F300 ; Retract 2mm
G92 E0 ; Zero Extruder
G28 XY ; Home XY and U to Z max
M84 ; All motors Off
M290 R0 S0 ; clear babysteppingSam
-
@samlogan87 Hi Sam,
Sorry but I'm a bit busy too (for the same reasons that DC is busy - the TCT show is fast approaching).
I can't help with the probing as I don't use any form of bed level or flatness compensation. Your M84 is a bit odd. It sounds like the command to turn th motors off is happening while the previous G28 XY is still happening. So try putting M400 before the M84. That will wait for all moves to complete.
Note. Whenever you run M84, all the axes will revert to showing as being un-homed. That's because with no holding current, it is easy to knock something out of position. So it is mandatory to always home all axes after an M84 command. Is there a particular reason why you want to turn off the motors at the end of every print?
-
Hi @deckingman
That is not a problem and I fully understand. This forum is fantastic and I really appreciate the help.
Yeah it seems strange. With the M84 it use to work. I think I may start from scratch as I am now having issues with DWC as well. It says it is connected and I just tried pressing emergency stop and it did nothing.
I will download the sd card files and write the firmware back to it. Maybe the firmware is corrupted slightly. It always use to be stable and I very rarely had issues. Now it seems to be odd ones that pop up and go away when I cycle power.
In regards to running M84, I just do it as a matter of course. I usually have prints running during the day with the wife at home and she hates my printer at the best of times, so if I can make it quite and on after the print is done, I still partially stay in her good books
Regards,
Sam
-
@samlogan87 Maybe it's the card itself. If it was me, I think I'd be inclined to buy a new sd card, or at least try another one.
-
So the problems have started again. Below is 2x M122 for the printer when it was starting to stall between moves. I also have a video where I am doing a bed leveling Macro and it hangs between moves badly. When pressing emergency stop, the pwm fans run for about 10 seconds before turning off which is usually only 1-2 seconds.
8/21/2019, 9:48:17 PM: Connected to 192.168.1.40
8/21/2019, 9:48:27 PM: Emergency stop, attemping to reconnect...
8/21/2019, 9:48:28 PM: M112
M999: Cancelled printing file 0:/gcodes/CFFFP_Flex3Drive Orion Adaptor v2.gcode, print time was 0h 1m
Error: Homing failed
8/21/2019, 9:48:34 PM: Connection established
8/21/2019, 9:54:24 PM: M98 P"0:/macros/Bed Leveling Macro 55 Degrees": === Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 2.03 running on Duet Ethernet 1.02 or later + DueX2
Board ID: 08DGM-956GU-DJMSN-6J9D4-3SD6Q-1VR7G
Used output buffers: 1 of 24 (9 max)
=== RTOS ===
Static ram: 25680
Dynamic ram: 94052 of which 112 recycled
Exception stack ram used: 540
Never used ram: 10688
Tasks: NETWORK(ready,524) HEAT(blocked,1172) DUEX(blocked,156) MAIN(running,3820) IDLE(ready,160)
Owned mutexes: I2C(DUEX)
=== Platform ===
Last reset 00:05:53 ago, cause: software
Last software reset time unknown, reason: Assertion failed, spinning module Platform, available RAM 33492 bytes (slot 3)
Software reset code 0x4090 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0440f819 BFAR 0xe000ed38 SP 0x2001ff8c Task 0x454c4449
Stack: 000002f3 00462a68 0044a485 20002bd4 0044b3c9 00000011 00020000 20005558 00000001 10000000 004385c9 20006284 00000000 20006220 004466af 00000001 20006288 20006284 200062f8 20006220 fffffffd 00000000 00f00000
Error status: 0
Free file entries: 8
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest block write time: 0.0ms, max retries 0
MCU temperature: min 33.5, current 35.2, max 35.5
Supply voltage: min 24.1, current 24.2, max 24.3, under voltage events: 0, over voltage events: 0, power good: yes
Driver 0: standstill, SG min/max 0/1023
Driver 1: standstill, SG min/max 0/66
Driver 2: ok, SG min/max not available
Driver 3: ok, SG min/max not available
Driver 4: ok, SG min/max not available
Driver 5: ok, SG min/max not available
Driver 6: standstill, SG min/max not available
Date/time: 2019-08-21 21:54:23
Cache data hit count 849160355
Slowest loop: 209.78ms; fastest: 0.07ms
I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0
=== Move ===
Hiccups: 0, FreeDm: 168, MinFreeDm: 165, MaxWait: 174596ms
Bed compensation in use: none, comp offset 0.000
=== DDARing ===
Scheduled moves: 31, completed moves: 30, StepErrors: 0, LaErrors: 0, Underruns: 0, 0
=== Heat ===
Bed heaters = 1 -1 -1 -1, chamberHeaters = -1 -1
Heater 0 is on, I-accum = 0.2
Heater 1 is on, I-accum = 0.3
=== GCodes ===
Segments left: 0
Stack records: 2 allocated, 2 in use
Movement lock held by http
http is idle in state(s) 45 0 0
telnet is idle in state(s) 0
file is idle in state(s) 0
serial is idle 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 ===
Slowest loop: 221.10ms; fastest: 0.02ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) Telnet(0)
HTTP sessions: 1 of 8
Interface state 5, link 100Mbps full duplex
8/21/2019, 9:54:24 PM: M122: === Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 2.03 running on Duet Ethernet 1.02 or later + DueX2
Board ID: 08DGM-956GU-DJMSN-6J9D4-3SD6Q-1VR7G
Used output buffers: 1 of 24 (9 max)
=== RTOS ===
Static ram: 25680
Dynamic ram: 94052 of which 112 recycled
Exception stack ram used: 540
Never used ram: 10688
Tasks: NETWORK(ready,524) HEAT(blocked,1172) DUEX(blocked,156) MAIN(running,3820) IDLE(ready,160)
Owned mutexes: I2C(DUEX)
=== Platform ===
Last reset 00:05:53 ago, cause: software
Last software reset time unknown, reason: Assertion failed, spinning module Platform, available RAM 33492 bytes (slot 3)
Software reset code 0x4090 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0440f819 BFAR 0xe000ed38 SP 0x2001ff8c Task 0x454c4449
Stack: 000002f3 00462a68 0044a485 20002bd4 0044b3c9 00000011 00020000 20005558 00000001 10000000 004385c9 20006284 00000000 20006220 004466af 00000001 20006288 20006284 200062f8 20006220 fffffffd 00000000 00f00000
Error status: 0
Free file entries: 8
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest block write time: 0.0ms, max retries 0
MCU temperature: min 33.5, current 35.2, max 35.5
Supply voltage: min 24.1, current 24.2, max 24.3, under voltage events: 0, over voltage events: 0, power good: yes
Driver 0: standstill, SG min/max 0/1023
Driver 1: standstill, SG min/max 0/66
Driver 2: ok, SG min/max not available
Driver 3: ok, SG min/max not available
Driver 4: ok, SG min/max not available
Driver 5: ok, SG min/max not available
Driver 6: standstill, SG min/max not available
Date/time: 2019-08-21 21:54:23
Cache data hit count 849160355
Slowest loop: 209.78ms; fastest: 0.07ms
I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0
=== Move ===
Hiccups: 0, FreeDm: 168, MinFreeDm: 165, MaxWait: 174596ms
Bed compensation in use: none, comp offset 0.000
=== DDARing ===
Scheduled moves: 31, completed moves: 30, StepErrors: 0, LaErrors: 0, Underruns: 0, 0
=== Heat ===
Bed heaters = 1 -1 -1 -1, chamberHeaters = -1 -1
Heater 0 is on, I-accum = 0.2
Heater 1 is on, I-accum = 0.3
=== GCodes ===
Segments left: 0
Stack records: 2 allocated, 2 in use
Movement lock held by http
http is idle in state(s) 45 0 0
telnet is idle in state(s) 0
file is idle in state(s) 0
serial is idle 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 ===
Slowest loop: 221.10ms; fastest: 0.02ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) Telnet(0)
HTTP sessions: 1 of 8
Interface state 5, link 100Mbps full duplex
8/21/2019, 9:54:33 PM: : Leadscrew adjustments made: 0.256 0.251 0.250 0.265, points used 4, deviation before 0.256 after 0.000
8/21/2019, 9:55:06 PM: : Leadscrew adjustments made: 0.001 0.004 -0.001 0.003, points used 4, deviation before 0.003 after 0.000Here is a link to the video of it misbehaving. I have just pressed emergency stop again and it seems to have dropped its config again as panel due is gone back to a basic config, the fans are going full speed and I can not connect via DWC. Not sure if you can shed any light on the issue.
Kind Regards,
Sam -
@samlogan87 said in Problems after updating firmware:
Software reset code 0x4090
I'm not overly-familiar with error codes, but according to the error codes page I think that means:
memManage = 0x40
and...
moduleStorage = 9
(I think, please someone correct me if I'm wrong!)So I'm guessing SD card, or reading SD card, or SD card socket? Particularly if it's having problems reading the config.g from the card. You say you have recently got another SD card (16GB)? Maybe try formatting a card with the official SD card formatter https://www.sdcard.org/downloads/formatter/index.html
SD Cards should be formatted either FAT16 with 64kb clusters (4GB or below) or FAT32 with 32kb clusters for SD cards up to 32GB, with 512 byte sectors (should be default). SD cards larger than 32GB are not supported, and neither is exFAT format.Ian
-
@droftarts thanks for that.
I had no idea how to read the error codes. Something strange seems to be happening here as it has done it to two sd cards now. I am thinking there is something else happening perhaps. The amount of disconnects I get between dwc and the board has increased greatly since upgrading and I wonder if maybe when I was making changes to my config file if whether one of the disconnects happened and the file didn’t get uploaded correctly. I will give an official formatted a go. I usually just use the windows one.
Hopefully David can find sometime to shed some light on what could be happening as it is getting a tad frustrating now. Luckily when it started doing this last night I opened the config file and copied it so I have a backup before it seemed to have completely crapped itself. Last time I was not so lucky.
Kind Regards
Sam
-
@samlogan87, I am sorry, that software reset code is a known issue in firmware 2.03 when a DueX is present in the system and there is noise on the endstop inputs of the DueX during startup. You are only the second user to report it. There is a temporary 2.04RC2 version at https://www.dropbox.com/sh/mk3jlsoi6gyxd8q/AABbEvX2qb19McbRe6UvRmI9a?dl=0 that includes a fix for it. Or you can revert to firmware 2.02.
The noise on the endstop inputs may also be responsible for the increased rate of disconnections. Firmware 2.03 and 2.04 use a separate high-priority task to update the DueX endstop states recorded by the main processor when they change, in order to reduce endstop latency; but if they change very frequently, that task may use too much CPU time.
Duet WiFi hardware designer and firmware engineer
Please do not ask me for Duet support via PM or email, use the forum
http://www.escher3d.com, https://miscsolutions.wordpress.com -
@dc42
I understand you are probably flat out at the moment and can’t answer everyone’s questions so thank you for replying.In a way that is great news as it is just not me going crazy. I will try the upgrade as I am hoping to get a magnetic filament monitor when they are released that I will need to be running 2.04 with won’t I? Is there anything else that I could do to mitigate these issues?
Kind Regards,
Sam
-
Also the only endstop I currently have connect to my duex is a filament run out switch if that is any help.
Kind Regards,
Sam
