New beta firmware 1.20beta8
-
David, I won't be able to test sensorless homing for CoreXY, as I need to replace my belt… If someone else can test it, and check than any of motors stall is detected, when moving along X or along Y (both motors turn in these directions)...
-
Moving report to the latest firmware version. As reported here https://www.duet3d.com/forum/thread.php?pid=30376#p30376, I'm experiencing random firmware resets, likely by the watchdog timer. I've tried several latest firmware versions, and now have high confidence that 1.20beta6 does not reset, while 3 versions afterwards (1.20beta7, 1.20beta8, 1.20beta8+1) all randomly reset. I also verified that reset behaviour is not affected by the WiFi module firmware, e.g. 1.20beta6 is still stable even with WiFi Firmware 1.20beta9
-
@fma:
David, I won't be able to test sensorless homing for CoreXY, as I need to replace my belt… If someone else can test it, and check than any of motors stall is detected, when moving along X or along Y (both motors turn in these directions)...
I'm using sensorless homing on my CoreXY with 1.20beta7. Stalling is detected, but sometimes, instead of going to -x or -y, the move is executed in the opposite direction. After moving the head using the controls it gows in the right direction. I have not been able to replicate this behaviour. Other than this, stalling seems to be detected properly.
This is my X home.g file content:
; Lift Z relative to current position
G91
G1 Z5 F6000
G90M400 ; make sure everything has stopped before we make changes
M913 X50 Y50 Z50 ; drop motor currents to 50%
M574 X1 Y1 S3 ; set endstops to use motor stall
M915 X Y S4 R0 F0 ; set X and Y to sensitivity 4, do nothing when stall, unfiltered
G91 ; use relative positioning
G1 S1 X-400 F4000 ; move left 400mm, stopping at the endstop
G1 X5 ; move away from end
G90 ; back to absolute positioning
G92 X ; set new X home possition
M400 ; make sure everything has stopped before we reset the motor currents
M913 X100 Y100 Z100 ; motor currents back to 100%
M574 X1 Y1 S0 ; Define active low and unused microswitches; Lower Z again
G91
G1 Z-5 F6000
G90I will test today 1.20beta8 in a few hours, I'll report if anything changes.
Regarding the reset problem, I have been printing more then 24 hours without any reset or any other problems. I have a Duet Ethernet, not Wifi, so it might be wifi related?
-
I'm on Duet WiFi. Also, my printer is Delta, not CoreXY. The bug may be in Delta-specific code. Or something else specific to my configuration (sensors, heaters, motors…)
-
i can comfirm the wrong direction on homing as mchiriciuc says (CoreXY )
it happens sometimes but most of the times it works finei have not yet upgrade to the latest FW will do that soon
and do more test -
I didn't notice that in beta7… But I was homing to max endstops.
-
I have printed all day with beta8. Works fine, except for this random homing direction inversion.
No other issues detected so far by me. -
@fma:
David, I won't be able to test sensorless homing for CoreXY, as I need to replace my belt… If someone else can test it, and check than any of motors stall is detected, when moving along X or along Y (both motors turn in these directions)...
I'm using sensorless homing on my CoreXY with 1.20beta7. Stalling is detected, but sometimes, instead of going to -x or -y, the move is executed in the opposite direction. After moving the head using the controls it gows in the right direction. I have not been able to replicate this behaviour. Other than this, stalling seems to be detected properly.
This is my X home.g file content:
; Lift Z relative to current position
G91
G1 Z5 F6000
G90M400 ; make sure everything has stopped before we make changes
M913 X50 Y50 Z50 ; drop motor currents to 50%
M574 X1 Y1 S3 ; set endstops to use motor stall
M915 X Y S4 R0 F0 ; set X and Y to sensitivity 4, do nothing when stall, unfiltered
G91 ; use relative positioning
G1 S1 X-400 F4000 ; move left 400mm, stopping at the endstop
G1 X5 ; move away from end
G90 ; back to absolute positioning
G92 X ; set new X home possition
M400 ; make sure everything has stopped before we reset the motor currents
M913 X100 Y100 Z100 ; motor currents back to 100%
M574 X1 Y1 S0 ; Define active low and unused microswitches; Lower Z again
G91
G1 Z-5 F6000
G90I will test today 1.20beta8 in a few hours, I'll report if anything changes.
Regarding the reset problem, I have been printing more then 24 hours without any reset or any other problems. I have a Duet Ethernet, not Wifi, so it might be wifi related?
I suggest you remove this:
G92 X ; set new X home possition
and use parameter X-5 in your M208 S1 command to define the endstop position. I'm not sure it will fix the homing issue, but at least the printer won't think it is homed if the stall is not detected.
-
The homing issue occurs an the G1 S1 X-400 F4000 command, so the G92 X should have nothing to do with it. I will go with your suggestion since is the better and safer way of doing this. Thank you.
But, I think I have an ideea what is happening.
Sometimes, a stall is detected when the motor accelerates and only the G1 X5 is executed (as far as movement is perceived by me).
I will test this further, and report back. -
Yes, that's entirely possible. You may need to increase the M915 S parameter, or reduce the acceleration.
-
Any thoughts on the probing issue DC? I only ask as the difference in results between firmware versions is so stark there has to be something going on? I've replicated that now on two different machines.
-
Any thoughts on the probing issue DC? I only ask as the difference in results between firmware versions is so stark there has to be something going on? I've replicated that now on two different machines.
Thanks for the reminder. I've made a note to look at it next week.
-
Just installed the 1.20beta8+1 and noticed right away that while printing my always on fan for my hot end is no longer always on. As the hot end moves, it revs up and down. The only change made to the printer was to update the firmware.
-
I worked the issue and determined it was a break in the fan connector or wiring somewhere that happened at the same time I updated the firmware. Checked further and found a broken ground wire at the board connector for the hot end fan.
-
Question about the stall detection (I'm still in 1.19, so this is a theoretical question, not a bug report). I'm having issues since couple of prints ago with motors loosing steps, and of course, layer shifting. This is not happening always though. My suspect is that X carriage bushings has a problem, but I wasn't able to reproduce it, as it only happens from time to time.
Yesterday I was executing the mesh bed levelling, and I heard how the X carriage was stuck, and it checked twice the same point, assuming that it moved… Anyway, here my question, if the stall detection is enabled, and for any reason some steps are missed during the mesh bed levelling... what happens? is the procedure cancelled? it will home again and continue?
Regards
-
Currently, stall detection will only pause or rehome when you are printing from SD card.
-
Currently, stall detection will only pause or rehome when you are printing from SD card.
Ok, thanks
-
Any thoughts on the probing issue DC? I only ask as the difference in results between firmware versions is so stark there has to be something going on? I've replicated that now on two different machines.
I just ran your file on my delta with the smart effector, and I added the results in a new column on your sheet. Looks OK to me. Probing speed is 1000mm/min, which is 16.7mm/sec or 16.7um/millisec. As the Z probe is only sampled once per millisecond, a range of commonly 15us and occasionally just over that is to be expected.
I am running a later build than 1.20b8+1, so things may have changed.
-
Thanks for having a look David. And for appending the results. For now if I am using my corexy as a sensor test rig then I'll just flash 1.19 temporarily. I'll test with whatever the latest edge build is and see if the behaviour changes when they're released.
-
btw in the next 1.20 beta there will be a new Z probe type 8, which is the same as type 5 without filtering, so faster response (no 1ms sampling). I've just tested it with your file again:
x16 microstepping, F1000: 25 instances of -0.166mm, 5 instances of -0.171mm
x32 microstepping, F1000: 1 instance of -0.158, 2 instances of -0.166, remainder -0.161 or -0.163.If you want to try this version, the Duet WiFi build is at https://www.dropbox.com/s/tr3be3v9o5iqxxa/DuetWiFiFirmware.bin?dl=0.
