Problems after updating firmware

samlogan87 · 9 Aug 2019, 22:41

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

samlogan87 · 8 Oct 2019, 04:47

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 Home

Here 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 babystepping

Sam

deckingman · 8 Oct 2019, 08:27

@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?

samlogan87 · 10 Aug 2019, 11:39

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

deckingman · 10 Aug 2019, 12:30

@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.

samlogan87 · 21 Aug 2019, 10:13

@dc42

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.000

Here 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.

https://youtu.be/NjQYrGi1lco

Kind Regards,
Sam

droftarts · 21 Aug 2019, 14:58

@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

samlogan87 · 21 Aug 2019, 17:52

@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

dc42 · 21 Aug 2019, 17:58

@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.

samlogan87 · 21 Aug 2019, 18:31

@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

samlogan87 · 21 Aug 2019, 18:35

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

samlogan87 · 22 Aug 2019, 09:03

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

droftarts · 22 Aug 2019, 09:09

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

samlogan87 · 22 Aug 2019, 09:18

@droftarts

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

droftarts · 22 Aug 2019, 09:42

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

samlogan87 · 22 Aug 2019, 10:08

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

A Former User · 22 Aug 2019, 10:56

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)

samlogan87 · 24 Aug 2019, 12:10

@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,
Sam

samlogan87 · 28 Aug 2019, 09:47

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

A Former User · 28 Aug 2019, 12:16

@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.