New beta firmware 1.20beta8

[dc42]

I've just released this in the usual Edge folders. For the Duet WiFi it's 1.20beta8+1 due to a late bug fix.

This beta completes the implementation of almost all the new features scheduled for the 1.20 release, in particular the stall detection is complete. See https://github.com/dc42/RepRapFirmware/ … ATS_NEW.md as usual for the change list and upgrade notes.

Alongside this I have released DuetWiFiServer-1.20beta9.

[DjDemonD]

Hi David can I report something a bit strange?

I've been testing some new sensors I started off testing on my corexy on 1.20b8 but it was giving me quite inaccurate results, presuming it was just that it has a wobbly z axis, I moved the test to my kossel XL which is a much more precise machine and still got odd results, so I downgraded to 1.19.1 and got much more consistent probing, nothing else changed.

Its quite significantly different between the two FW versions
example:
kossel XL - 1.20b8 - electrical contact range 85 microns, std dev 18 microns
kossel XL - 1.20b8 - smarteffector range 70 microns, std dev 23 microns
kossel XL - 1.19.1 -smarteffector range 20 microns, std dev 5 microns
kossel XL - 1.20b8+1 smarteffector range 65 microns std dev 20 microns

The test I'm running is just G30 S-1 then raise nozzle to z=10 then repeat 30 times, I'm using excel to collate them into just range and std dev.

This is the gcode I'm running https://1drv.ms/u/s!Apv79JfGbPIwg4QQ7wvRxqHtBplvJg
after manually homing and going to Z=10 at bed centre.

Here are my detailed results https://1drv.ms/x/s!Apv79JfGbPIwg4QOBEnrpMleDlCRPQ
as you can see even using direct electric contact its all over the place. Whats really odd is it calibrates and prints perfectly. So maybe a bug in the G30 code, but not G32??

All belts tight, pulleys secure, bed clamped etc…

Anyone else running 1.20b8/b8+1 fancy trying it? How about if you downgrade to 1.19.1 (doesn't cause any issue doing this).

[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)...

[zlowred]

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

[mchiriciuc]

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

M400 ; 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
G90

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

[zlowred]

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…)

[MrBlom]

i can comfirm the wrong direction on homing as mchiriciuc says (CoreXY )
it happens sometimes but most of the times it works fine

i have not yet upgrade to the latest FW will do that soon
and do more test

[fma]

I didn't notice that in beta7… But I was homing to max endstops.

[mchiriciuc]

I have printed all day with beta8. Works fine, except for this random homing direction inversion.
No other issues detected so far by me.

[dc42]

@mchiriciuc:

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

M400 ; 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
G90

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

[mchiriciuc]

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.

[dc42]

Yes, that's entirely possible. You may need to increase the M915 S parameter, or reduce the acceleration.

[DjDemonD]

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.

[dc42]

@DjDemonD:

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.

[Forgvn77]

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.

[Forgvn77]

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.

[okercho]

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

[dc42]

Currently, stall detection will only pause or rehome when you are printing from SD card.

[okercho]

@dc42:

Currently, stall detection will only pause or rehome when you are printing from SD card.

Ok, thanks

[dc42]

@DjDemonD:

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.