wifi 2 Board skipping steps
-
@juls said in wifi 2 Board skipping steps:
Your gcode is changing the M566 setting, which is 'jerk' or 'maximum instantaneous speed changes'. This is how fast it will change between one speed and another instantaneously. eg:
;LAYER_COUNT:197 ;LAYER:0 M107 M566 X1200 Y1200 G0 F2800 X193.51 Y240.788 Z0.35 M566 X900 Y900 ;TYPE:SKIRTM566 X1200 Y1200 is double the jerk setting in config.g of M566 X600 Y600. Your motors may not have enough torque to do this move in certain situation, eg a change of direction.
Some slicers use 'adaptive jerk', and change M566 during the print. What slicer are you using? Possibly Orcaslicer? If you updated the slicer in the last couple of weeks, this may have been turned on. Is the gcode you posted newly created, or did this exact code print correctly a couple of weeks ago?
@juls said in wifi 2 Board skipping steps:
the 2nd Y value is inserted because there are 2 steppers on the Y axis controlled by 2 separate stepper drivers as previously explained. Unless you are telling me that it's only necessary to specify the one setting as it will be automatically applied across both channels?
Yes. In the past this has been known to cause issues. RepRapFirmware does not support individual motor settings where an axis has multiple motors connected to different stepper drivers. The first parameter specified will be used for all motors on the axis. You should use identical motors on any axis that has more than one motor to avoid unexpected behaviour. Each extruder axis is counted as a separate axis, so you only specify extra values if you have multiple extruders.
Ian
Cartesian bed-slinger with Duet 3 Mini 5+ WiFi and 1LC : RRP Fisher Delta v1 with Duet 2 Maestro : TronXY X5S with Duet 3 MB6HC and Roto toolboard
-
Hi Tony, appreciate your trying to help resolve
I have already tried swapping the axis drivers.. strangely the issue did not move but remained. That would of course make you think the axis is the issue but the axis and motors have been completely refurbed checked and all bearings and motors renewed. The layer shift is still occurring, it has reduced, mainly with slowing everything down but I'm still getting around 1-5 skips occurring per print. If there was any axis or motor issue (which I'm not convinced there was) then it's gone now anyway.
But none of this gets away from the fact the the identical prints were working perfectly with zero skips and much faster speeds and identical setup.. we are talking 20 or more of the same print, all completely successful! It just feels like the whole system has lost power somehow.
I've not made any change in the electronics enclosure but I have included a picture here so you can see it's not cramped in any way. I've already been running temp checks with an infra red thermometer and nothing on the board seems to be reading over 30 degrees which is consistent with M122 which is giving a max MCU temp of 27.8
The only other thing I can think of is that between the successful prints mentioned above and the current skipping steps scenario we completed a number of very large ABS prints, high temperatures, extruder 250 bed 80 across multiple days. The prints completed successfully, ie without any layer shifting issues however I'm wondering if the stress on the board has caused a power failure somewhere. It's odd that the problem has occurred since those prints.
-
Hi Ian,
so I've taken out the second parameter in config.g as suggested, thanks for explaining.
the slicer is CURA (which is actually written in the code)
the M566 changes you have noted are turned on/off via 'Jerk control'
However I've checked back through the gcodes and the layer skipping ones to start with all had jerk control turned off, ie no M566 changes in the gcode.
I've actually enabled that to try to cure the issue, it's certainly not made it worse, if anything it has improved it but we need prints without any layer skips at all obviously..
A recent gcode file that I ran I had the M566 turned down to X780 Y780 and it still had layer skips.
I'm currently running a file with the config change and M203 set at 5000, M201 set at 3000
However none of this still gets away from the fact that all was working perfectly at the faster settings and config so I feel issue lies elsewhere.
-
@juls thanks for the update.
There is no reason the higher ABS temperatures would have stressed the control board significantly unless the electronics enclosure is heated by the bed in some way so the internal temperature of the enclosure was higher.
What does occur to me is its worth confirming the power supply is not the issue, depending on how your bed and extruder are powered (I assume bed is AC given the printer size, extruder is DC)
Is the powersupply still providing the correct voltage and do you see any drop in power supply voltage when heating the extruder from cold?
Another point you mentioned:
@juls said in wifi 2 Board skipping steps:
Since then tried reducing motor current - 85% of rated value as suggested so currently 1.4A per channel on this axis, similar or lower on the other channels.
Have you subsequently restored the motor current to what is was when it was working perfectly? If not please do that.
-
@juls Please can you send M122 in the DWC console, and post the response. There's some diagnostics that may help.
If you have moved the stepper motors to different drivers and experienced the same issue on the same axis, I'd have to say this is:
- either a settings issue (I'd revert to not using 'Jerk control' in Cura), ie trying to run the motors faster than they were previously when it was working fine,
- or a power issue, ie the motors are trying to pull more or the same voltage (stepper drivers always supply the same current, but voltage changes as required to move the motor) but are not getting the required voltage supply. That makes be think the PSU or power wiring may be an issue. Please check all wiring is firmly seated (ie the power screw terminals on the Duet), and the PSU is supplying the correct voltage under load. The M122 report may show such voltage drops.
Edit: sorry, I see @T3P3Tony has replied with much the same thing.
Ian
Cartesian bed-slinger with Duet 3 Mini 5+ WiFi and 1LC : RRP Fisher Delta v1 with Duet 2 Maestro : TronXY X5S with Duet 3 MB6HC and Roto toolboard
-
the electronics enclosure isn't heated by the bed in any way. The bed is above the enclosure so no risk of that.
I've not noticed any issue with power supply or heating from cold, as you can see the bed is indeed powered via a relay so not directly heated by the board supply. All of the stepping issues seem to appear later in the printing anyway not at the start.
M122 reads supply voltage min 23.8 current 24 max 24.5, under voltage events: 0, over voltage events: 0, power good: yes
Yes already thought of that with regards to the motor current. I've actually been increasing it gradually again as it does of course reduce issues to have more current available. Current on the Y axis is 1600 at the moment - but the motors are only sitting around 50 degrees C during printing so still very comfortable.
-
as requested - wiring all looks good and has been checked, it was all replaced and rebuilt only a few months ago. I've just checked the voltage manually during the print and its reading just over 24v
Only slightly interesting thing is that 1 stepper motor on the Y axis is consistently reading about 2 degrees hotter than the other which is a bit odd since they are identical brand new motors and both sides of the axis are loaded identically. Either way max temp of the stepper is still only around 49.5 degrees.
m122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 3.4.6 (2023-07-21 14:08:28) running on Duet WiFi 1.02 or later
Board ID: 0JD0M-9P6B2-NJ4S4-6JKF2-3SD6P-KU1QL
Used output buffers: 1 of 26 (25 max)
=== RTOS ===
Static ram: 23896
Dynamic ram: 75612 of which 12 recycled
Never used RAM 9272, free system stack 104 words
Tasks: NETWORK(ready,14.4%,229) HEAT(notifyWait,0.0%,308) Move(notifyWait,2.5%,300) MAIN(running,83.0%,456) IDLE(ready,0.0%,30), total 100.0%
Owned mutexes: WiFi(NETWORK)
=== Platform ===
Last reset 02:07:08 ago, cause: software
Last software reset time unknown, reason: User, GCodes spinning, available RAM 9128, slot 0
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f000 BFAR 0xe000ed38 SP 0x00000000 Task MAIN Freestk 0 n/a
Error status: 0x00
Step timer max interval 0
MCU temperature: min 27.2, current 27.7, max 28.7
Supply voltage: min 23.8, current 24.0, max 24.5, under voltage events: 0, over voltage events: 0, power good: yes
Heap OK, handles allocated/used 99/1, heap memory allocated/used/recyclable 2048/28/0, gc cycles 0
Events: 0 queued, 0 completed
Driver 0: ok, SG min 0
Driver 1: stalled, SG min 0
Driver 2: ok, SG min 0
Driver 3: ok, SG min 0
Driver 4: ok, SG min 0
Driver 5:
Driver 6:
Driver 7:
Driver 8:
Driver 9:
Driver 10:
Driver 11:
Date/time: 2024-06-28 12:02:12
Cache data hit count 4294967295
Slowest loop: 9.39ms; fastest: 0.19ms
I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0
=== Storage ===
Free file entries: 9
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest read time 1.3ms, write time 0.0ms, max retries 0
=== Move ===
DMs created 83, segments created 18, maxWait 3211ms, bed compensation in use: mesh, comp offset 0.000
=== MainDDARing ===
Scheduled moves 99844, completed 99814, hiccups 0, stepErrors 0, LaErrors 2, Underruns [0, 0, 0], CDDA state 3
=== AuxDDARing ===
Scheduled moves 0, completed 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== Heat ===
Bed heaters 0 -1 -1 -1, chamber heaters -1 -1 -1 -1, ordering errs 0
Heater 0 is on, I-accum = 0.3
Heater 1 is on, I-accum = 0.8
=== GCodes ===
Segments left: 1
Movement lock held by null
HTTP is idle in state(s) 0
Telnet is idle in state(s) 0
File is doing "G0 X351.317 Y341.779" 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
Daemon is idle in state(s) 0
Autopause is idle in state(s) 0
Code queue is empty
=== Filament sensors ===
Extruder 0: pos 73.83, errs: frame 0 parity 0 ovrun 0 pol 0 ovdue 0
=== Network ===
Slowest loop: 100.48ms; fastest: 0.07ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0)
HTTP sessions: 1 of 8
= WiFi =
Interface state: active
Module is connected to access point
Failed messages: pending 0, notready 0, noresp 4
WiFi firmware version 1.27
WiFi MAC address a4:e5:7c:03:db:6c
WiFi Vcc 3.44, reset reason Power up
WiFi flash size 2097152, free heap 25840
WiFi IP address 192.168.0.21
WiFi signal strength -45dBm, mode 802.11n, reconnections 0, sleep mode modem
Clock register 00002002
Socket states: 0 0 0 0 0 0 0 0 -
@droftarts @T3P3Tony @jay_s_uk
So after following the previous advices given there were 2 successful prints, then the 3rd print and most recent print failed again - a big layer shift ruining the print about 3/4 the way up.
I've checked M122 following the print and there were no undervoltage issues reported and also no temperature issues.
-
@juls Was it the same Gcode file three times, or three different Gcodes files? Newly sliced or old files that have printed successfully or failed before? Can you post the Gcode file that failed?
Ian
-
So just to update you that all subsequent prints (about 3 since last report) have all continued to have stepping issues. All the prints have been a variation of the same file and sliced with the same settings, slowed down considerably from the original 20 or so prints that were all successful and with the tweaks that have been suggested above implemented. No jerk control, config corrected, overall speeds and acceleration reduced dramatically.
We can't post the full gcode for legal reasons but the lines as compared with the previous code show you that the M566 command has gone:
;FLAVOR:RepRap ;TIME:17378 ;Filament used: 61.718m ;Layer height: 0.3 ;MINX:192.102 ;MINY:237.71 ;MINZ:0.35 ;MAXX:397.898 ;MAXY:347.29 ;MAXZ:59.15 ;Generated with Cura_SteamEngine 4.13.2 T0 M190 S60 M104 S200 M109 S200 M82 ;absolute extrusion mode G28 ;Home G29 S1; G1 Z15.0 F6000 ;Move the platform down 15mm ;Prime the extruder G29 S1 ;load bed compensation mesh G92 E0 G1 E75 F200 G92 E0 M83 ;relative extrusion mode G1 F2400 E-2.5 ;LAYER_COUNT:197 ;LAYER:0 M107 G0 F2800 X193.512 Y239.036 Z0.35 ;TYPE:SKIRT G1 F2400 E2.5 G1 F2100 X193.955 Y238.762 E0.06064 G1 X194.435 Y238.558 E0.06071 G1 X194.94 Y238.429 E0.06067 G1 X195.445 Y238.38 E0.05906 G1 X196.398 Y238.359 E0.11097 G1 X198.693 Y238.353 E0.26716 G1 X205.669 Y238.356 E0.81208 G1 X389.908 Y238.356 E21.44735 G1 X391.319 Y238.352 E0.16426 G1 X393.87 Y238.36 E0.29696 G1 X394.528 Y238.371 E0.07661 G1 X395.047 Y238.42 E0.06069 G1 X395.552 Y238.547 E0.06062 G1 X396.032 Y238.751 E0.06071 G1 X396.475 Y239.025 E0.06064 G1 X396.871 Y239.363 E0.06061 G1 X397.211 Y239.758 E0.06067 G1 X397.487 Y240.201 E0.06076 G1 X397.691 Y240.68 E0.06061 G1 X397.82 Y241.185 E0.06067 G1 X397.87 Y241.698 E0.06 G1 X397.891 Y242.692 E0.11574 G1 X397.897 Y244.849 E0.2511 G1 X397.894 Y251.648 E0.79147 G1 X397.894 Y338.804 E10.14587 G1 X397.898 Y340.002 E0.13946 G1 X397.89 Y342.557 E0.29743 G1 X397.878 Y343.278 E0.08394 G1 X397.829 Y343.796 E0.06057 G1 X397.702 Y344.302 E0.06073 G1 X397.499 Y344.782 E0.06067 G1 X397.225 Y345.225 E0.06064 G1 X396.886 Y345.621 E0.06068 G1 X396.491 Y345.961 E0.06067 G1 X396.048 Y346.237 E0.06076 G1 X395.569 Y346.441 E0.06061 G1 X395.064 Y346.57 E0.06067 G1 X394.555 Y346.62 E0.05954 G1 X393.6 Y346.641 E0.1112 G1 X391.365 Y346.647 E0.26018 G1 X384.498 Y346.644 E0.79939 G1 X374.178 Y346.644 E1.20136 G1 X372.67 Y346.622 E0.17557 G1 X371.37 Y346.586 E0.15139 G1 X368.637 Y346.586 E0.31815 G1 X367.656 Y346.616 E0.11425 G1 X365.793 Y346.644 E0.2169 G1 X200.06 Y346.644 E19.29306 G1 X198.822 Y346.648 E0.14412 G1 X196.212 Y346.64 E0.30383 G1 X195.474 Y346.628 E0.08592 G1 X194.955 Y346.579 E0.06069 G1 X194.449 Y346.452 E0.06073 G1 X193.969 Y346.249 E0.06067 G1 X193.526 Y345.975 E0.06064 G1 X193.13 Y345.637 E0.06061 G1 X192.79 Y345.242 E0.06067 G1 X192.514 Y344.8 E0.06066 G1 X192.309 Y344.32 E0.06076 G1 X192.18 Y343.815 E0.06067 G1 X192.13 Y343.302 E0.06 G1 X192.109 Y342.315 E0.11492 G1 X192.103 Y340.151 E0.25191 G1 X192.106 Y333.352 E0.79147 G1 X192.106 Y246.196 E10.14587 G1 X192.102 Y244.998 E0.13946 G1 X192.111 Y242.391 E0.30348 G1 X192.123 Y241.718 E0.07836 G1 X192.172 Y241.2 E0.06057 G1 X192.3 Y240.694 E0.06076 G1 X192.503 Y240.215 E0.06056 G1 X192.778 Y239.772 E0.0607 G1 X193.117 Y239.376 E0.06068 G1 X193.512 Y239.036 E0.06067 G1 F2400 E-2.5The printer has not been turned off and I've been keeping an eye on diagnostics - this is the latest and as you can see still no particular issues reported in 72 hours
m122 === Diagnostics === RepRapFirmware for Duet 2 WiFi/Ethernet version 3.4.6 (2023-07-21 14:08:28) running on Duet WiFi 1.02 or later Board ID: 0JD0M-9P6B2-NJ4S4-6JKF2-3SD6P-KU1QL Used output buffers: 1 of 26 (25 max) === RTOS === Static ram: 23896 Dynamic ram: 75684 of which 12 recycled Never used RAM 9104, free system stack 92 words Tasks: NETWORK(notifyWait,23.4%,211) HEAT(notifyWait,0.5%,308) Move(notifyWait,15.2%,294) MAIN(running,60.8%,456) IDLE(ready,0.1%,30), total 100.0% Owned mutexes: WiFi(NETWORK) === Platform === Last reset 71:35:32 ago, cause: software Last software reset time unknown, reason: User, GCodes spinning, available RAM 9128, slot 0 Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f000 BFAR 0xe000ed38 SP 0x00000000 Task MAIN Freestk 0 n/a Error status: 0x00 Step timer max interval 0 MCU temperature: min 24.4, current 24.9, max 29.1 Supply voltage: min 23.7, current 24.1, max 24.6, under voltage events: 0, over voltage events: 0, power good: yes Heap OK, handles allocated/used 99/0, heap memory allocated/used/recyclable 2048/186/186, gc cycles 0 Events: 1 queued, 1 completed Driver 0: standstill, SG min 0 Driver 1: standstill, SG min 0 Driver 2: standstill, SG min 0 Driver 3: standstill, SG min 0 Driver 4: standstill, SG min 0 Driver 5: Driver 6: Driver 7: Driver 8: Driver 9: Driver 10: Driver 11: Date/time: 2024-07-01 09:30:36 Cache data hit count 4294967295 Slowest loop: 118.65ms; fastest: 0.15ms I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0 === Storage === Free file entries: 10 SD card 0 detected, interface speed: 20.0MBytes/sec SD card longest read time 7.3ms, write time 0.0ms, max retries 0 === Move === DMs created 83, segments created 22, maxWait 25669423ms, bed compensation in use: mesh, comp offset 0.000 === MainDDARing === Scheduled moves 353169, completed 353169, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1 === AuxDDARing === Scheduled moves 0, completed 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1 === Heat === Bed heaters 0 -1 -1 -1, chamber heaters -1 -1 -1 -1, ordering errs 0 Heater 0 is on, I-accum = 0.3 Heater 1 is on, I-accum = 0.7 === GCodes === Segments left: 0 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 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 Daemon is idle in state(s) 0 Autopause is idle in state(s) 0 Code queue is empty === Filament sensors === Extruder 0: pos 331.17, errs: frame 7 parity 0 ovrun 0 pol 4 ovdue 0 === Network === Slowest loop: 109.93ms; fastest: 0.07ms Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) HTTP sessions: 1 of 8 = WiFi = Interface state: active Module is connected to access point Failed messages: pending 0, notready 0, noresp 18 WiFi firmware version 1.27 WiFi MAC address a4:e5:7c:03:db:6c WiFi Vcc 3.44, reset reason Power up WiFi flash size 2097152, free heap 25840 WiFi IP address 192.168.0.21 WiFi signal strength -48dBm, mode 802.11n, reconnections 0, sleep mode modem Clock register 00002002 Socket states: 0 0 0 0 0 0 0 0 -
@juls Thanks for the information. I can't see anything in the Gcode that would cause a skip, and the M122 report doesn't show any skips (assuming this M122 was from after a print that skipped - some data in M122 resets after each M122 command). There are some errors in the Filament sensors section that I'm just checking with @dc42.
I think this is a regular cartesian machine, rather than CoreXY? Is it always the Y axis that skips, any skips on X? When you replaced the motors, did you replace the wiring to the motors? Please check all wiring and crimps from board to motor. I still find it difficult to rationalise that there is a problem with the drivers on the board, as you say you swapped which driver controlled which axis.
Ian
-
Hi Ian, it's a regular cartesian machine not core XY. Generally yes the skips appear to have been only on the Y, however it's the only axis with independent channels for the 2 motors - possibly that's the aspect the board is struggling with for some reason. I have checked the wiring to the motors on the axis and yes in fact ALL the wiring in the entire printer was replaced as part of the refurbishment with brand new cables. But I have rechecked just recently the specific wiring on the Y, everything is perfect.
I would agree with what you are saying however I feel having ruled out every other possibility the only option left to try is replacing the board. If the issue goes away then we know that there was a problem somewhere on the board. If changing the board doesn't solve the issue I'm willing to return you the replacement board.
-
@juls said in wifi 2 Board skipping steps:
RepRapFirmware for Duet Wifi/Ethernet version 3.4.6
Have you tried updating firmware to 3.5.2 yet?
If the issues stays with the Y axis itself regardless of drivers than it makes me think it's a mechanical binding issue. How heavy is the Y axis?
