New experimental firmware 1.20beta6

[Yonkiman]

Cool! In addition to homing, could we eventually have a feature where anytime there's a skipped step, the motor that skipped reverses for a second and stops? I don't have a problem with skipped steps in normal printing (at least I don't think I do - I'll know soon), but I have occasionally accidentally pressed the wrong button on an unhomed system and banged into the end of travel on an axis.

EDIT: I just saw "Stall detection and sensorless homing" - you basically have that already!

Another reason I'm so happy I bought Duet Wifis for both my printers…

[Mike]

My PT100 temp sensor is malfunctioning in this beta (1.20b6) - heater fault at 2000 degrees.
It's defined by:
M305 P1 T100000 B4138 C0 R4700 X200

On a side note, has anyone been able to trigger Stallguard yet?

[krzaku]

@Mike:

My PT100 temp sensor is malfunctioning in this beta (1.20b6) - heater fault at 2000 degrees.
It's defined by:
M305 P1 T100000 B4138 C0 R4700 X200

On a side note, has anyone been able to trigger Stallguard yet?

T, B and C parameters have no effect on PT100 sensors, and in the new beta the R parameter configures the reference resistor. If you have the original PT100 daughterboard you should remove the R parameter (and the other parameters I mentioned in case they are used in the future).

[dc42]

@krzaku:

@Mike:

My PT100 temp sensor is malfunctioning in this beta (1.20b6) - heater fault at 2000 degrees.
It's defined by:
M305 P1 T100000 B4138 C0 R4700 X200

On a side note, has anyone been able to trigger Stallguard yet?

T, B and C parameters have no effect on PT100 sensors, and in the new beta the R parameter configures the reference resistor. If you have the original PT100 daughterboard you should remove the R parameter (and the other parameters I mentioned in case they are used in the future).

Good catch! I'll add this to the upgrade notes.

[Mike]

@krzaku:

T, B and C parameters have no effect on PT100 sensors, and in the new beta the R parameter configures the reference resistor. If you have the original PT100 daughterboard you should remove the R parameter (and the other parameters I mentioned in case they are used in the future).

Nice, thanks! That solved it.

[Jason K]

Hey yall-
Trying to test out sensor-less homing on my Cartesian rig. I cant seem to get it working. Probably my fault but I imagine if i have the problems other people could use it spelled out for them too.
I am using 0.9 degree steppers, 1.6A (from E3D, hard to find a good 0.9 stepper with a connector). I run at 24V and I have the current on the motors set to 1.2A. I am set to 256microstepping so 400s x 256/200 =512 puts me well within the speed i need to be going at.

I have changed my config.g with the following…

M915 X Y S5 R0 ; sensorless homing config (lifted from wiki)
M574 X1 Y1 Z0 S3 ; low end stop, sensor-less homing

I have modded my homex.g to the following as a test:

G91 ; relative mode
G1 Z4 F200 ; raise head to avoid dragging nozzle over the bed
M913 X50 Y50 Z50
M574 X1 Y1 Z0 S3
G1 X-200 F3000 S1 ; move up to 240mm in the -X direction, stopping if the homing switch is triggered
G1 X4 F600 ; move slowly 4mm in the +X direction
G90 ; back to absolute mode

The belt does not skip and the stepper just skips when it butts up at the end of the rail. The endstop is never triggered. What did i miss?

Also, Im a little confused about what the new z-probe changes mean for my z-IR probe.

These are my current settings
M558 P1 F200 T5000 R0
G31 Z2 P500

[dc42]

As I tried to explain on the wiki page, you need to tune the M915 settings to work for your motors. It appears that the motor stall is not being detected, so you need to reduce the S parameter. To prevent false stall detection at low speed, you may need to increase the minimum speed (H parameter) from its default value of 200. I found that with 0.9deg motors I needed 400.

You do not need to make any changes to your Z probe configuration.

[keyz182]

I seem to be having an issue with this release where Z homing is failing with my BL Touch. I've verified that it works fine in all 1.20 betas up to and including 4, but doesn't in 6.

When I hit home Z, the probe deploys, the Z axis moves down, the probe triggers, but the axis keeps moving and crashes into the bed. The probe then goes into it's flashing error mode because it's trying to redeploy but there's already something there (though I think this may be irrelevant, just happening because the axis doesn't lift up).

I didn't see any upgrade notes that seemed related to this, did I miss something, or is it not me?

I've dropped back to beta 4 for now, but can switch between versions if needed to test stuff.

[dc42]

That could happen if your homez.g and the Z homing section of your homeall.g file are set up for a homing switch, in other words using a G1 S1 Z move instead of a G30. Previously that would have worked if you included parameter Z1 in your M558 command. That parameter is no longer supported because that functionality has been moved to M574. But you should use a G30 command to home Z using a Z probe.

[resam]

I currently use 1.19.2 on a corexy with BLTouch for Z homing with these configs:

M574 X2 Y2 Z0 S1
M558 P5 X0 Y0 Z1 H7 F100 T7000
 

I'm homing with the BLTouch: [c]G30[/c] in my homez.g and homeall.g

Does this mean that with 1.20beta6 and later, M558 can completely be removed, and the M574 should be changed?
Do I need two M574, one for X&Y with S1, and one for Z with S2?

[dc42]

If you are homing Z using G30, you should not need to make any configuration changes.

[Jason K]

@dc42:

As I tried to explain on the wiki page, you need to tune the M915 settings to work for your motors. It appears that the motor stall is not being detected, so you need to reduce the S parameter. To prevent false stall detection at low speed, you may need to increase the minimum speed (H parameter) from its default value of 200. I found that with 0.9deg motors I needed 400.

You do not need to make any changes to your Z probe configuration.

Thanks for the help. Ill keep playing with it and report back when i get it working. I consulted the wiki first before I posed the question. From the page it sounded like I was likely to get false positives rather than undetected stall events. I havent done any more work on it since i put my question on the wiki but I did try S-values all the way down to -5. I did compensate for 0.9deg motors but im running at 256 microsteps so my min speed is very low as laid out by the equation in the wiki.

Now that I know im on the right track ill get back to it. Thanks for all your help and hard work.

[JRDM]

I was trying to set up sensorless homing tonight on a DuetWifi on 1.20beta6.

I think the end of this line is in error:

Snnn Stall detection threshold (-64 to +63, values below -10 not recommended). Higher values reduce the sensitivity.

https://www.duet3d.com/wiki/Stall_detection_and_sensorless_homing

As far as I can tell by experimentation, increasing the value increases sensitivity, not reduces.

[dc42]

Higher (more positive) values of S definitely reduce the sensitivity.

[JRDM]

When I was experimenting with values, anything below S9 wouldn't detect a stall, hit the end of travel and chatter against the end of travel. S10 and above stops. I'd repeated the cycle maybe a dozen times last night, reducing and increasing values until I could find an ideal one.