Problems after updating firmware
-
@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
-
Hi @dc42
A bit of an update. I removed the sd card, formatted it (16gb formatted as fat32 with 64kb unit size), put the sd card files on it and then copied all of the appropriate printer specific files onto it that I backed up. I then updated the firmware to the release in your dropbox.
Unfortunately it has not worked and the same issues still exist. The bed leveling still pauses and when I did try printing something it lagged between straight moves.
Do you have anything else I could try?
Kind Regards,
Sam -
Could you try disconnecting the filament runout switch connected to the Duex, and disable it in config.g? This might at least remove this as a source of the problem.
Ian
-
Well i tried it and it seems to be working well. I am just had a look and when I put the water cooled hotend in I re ran some of the wiring up the the top of the printer and one of the stepper motors for the corexy mechanism runs down the same channel in the extrusion as the filament sensor.
The question is do I need to run shielded stepper motor cables now?
Kind Regards,
Sam -
If you can put some distance between the stepper motor wires from the endstop wires, so they're not running next to each other, it will help.
From what I understand, twisting the pairs of stepper motor cables should help, as will twisting the pairs of endstop cables, as interference is then cancelled out. I tend to braid/plait the stepper motor cables and twist endstop/thermistor cables, but that's more for wire neatness than for noise cancelling, so I'm really not sure if it works for the stepper motors.
It can be a bit of a pain running shielded cables. At RepRapPro we used foil shielded stepper motor wiring, grounded to the metal case of the Duet enclosure, which was grounded to the PSU. This seemed to work well, but for you it means changing all your motor wiring. Might be easier to run twisted pair shielded endstop wires instead first, and see if that's enough, though you'll need to ground the shield to something. I think shielded ethernet cable is the preferred choice, but I haven't had to do it myself, yet. At least you know where the problem is, if it reoccurs!
I found this guide to best wiring practices from LinuxCNC a while ago, thought it was a pretty comprehensive: http://linuxcnc.org/docs/html/integrator/wiring.html
Ian
-
Hi @droftarts
I will see what I can do. I am wondering whether the noise also was going through to my piezo probe as well that is connected into the z probe connector as it would just start randomly probing in mid air. I may just do the end stops as they are easy to change to shielded.
Kind Regards,
Sam -
Ethernet is "preferred" because it's easily available and relatively cheap. But it's also the lowest grade of shield (foil). Make sure to use stranded and not single core in any case (in the Ethernet case that would be patch cable instead of installation cable)
-
@bearer thanks for that. I have some cat6 cable laying around. But as an update, I have managed 3 5 hour prints on the printer without issue so it is definitely that. However the fix @dc42 didn’t seem to work for me. I am waiting on the magnetic filament sensor to be released so I can buy it and then I will do it on shielded cable.
Kind Regards,
SamCustom Core-XY
-
Hi @dc42
So I have had my filament out sensor disabled and disconnected for a few prints now and it has worked fine. Now all of a sudden I am getting probing issues again. The piezo probe seems to probe fine for homing and bed leveling then all of a sudden when it want to re home z after leveling it starts probing in mid air. I press the emergency stop and it will home and level correctly but when it does the last z home, it stops working. Same if I turn power on and off. Do you think this is related to the changes in the new firmware? The z probe is connected to the z probe connector and there are no end stops connected to the duex anymore. Just two stepper motors and one PWM fan control.
Kind Regards,
Sam -
@samlogan87 just to clarify cat6 doesn't say anyhting about shielding, but its usually accompanied by utp or ftp; so cat6 ftp is shielded and cat6 utp is not shielded.
-
@bearer sounds like I am going to have to rip the printer apart and shield everything now which is a pain in the backside. Will proper shielded cat6 cable be able to handle 1.5 amps if I double the pairs up for the steppers? The steppers are probably easier to do as the end stops for my y axis and precision piezo are in a sheath going from my carriage along with my pt100. It is quite a pain to do. Lucky I have a flex3drive and I don’t have a stepper motor on my carriage. I guess what I am however asking is am I going to waste my time doing all this if it is not something else.
Kind Regards,
Sam -
Sadly cat6 doesn't actually say anything about current handling, the rating is mostly concerned with the frequency response of the cable.
I think its commonly available as both 22 and 24 awg. 24 awg is rated for about 2A as a single wire, you might get away with a total of 3A peak on double pairs even in a 4 pair cable, as both coils won't be at full power at the same time(?) I went with flexible rubber 2 pair 22 awg with braided shield when I rewired my printers, a little thicker than 22 awg cat6, but a lot softer and likely to last longer in the cable drag chains.
