Y axis sensorless houming failed

[calabr]

Single axis manual houming for x,y,z with TMC2209 successfull,
but trying to execute $H no home all axes - only Y not reacting on stall state.

The same setup successfully houming all axes if Y using normal sensor, X and Z sensorless
Assuming it's error in stallguard deporting configuration before houming

It's also not clear which mode is it using for houming - StelthChop or CoolStep

[OPT:VNMHSL+,100,1024,5,0]
[AXS:5:XYZAB]
[NEWOPT:ENUMS,RT+,HOME,ES,MPG,SED,TMC=7,ODO,SD,YM]
[FIRMWARE:grblHAL]
[SIGNALS:HSDEP]
[NVS STORAGE:*EEPROM 4K]
[FREE MEMORY:82K]
[DRIVER:STM32F407]
[DRIVER VERSION:250201]
[BOARD:MKS ROBIN-NANO 3.0]
[PLUGIN:Bootloader Entry v0.02]
[PLUGIN:Trinamic v0.24]
[PLUGIN:KEYPAD v1.38]
[PLUGIN:Macro plugin v0.10]
[PLUGIN:Homing pulloff v0.01]
[PLUGIN:ODOMETERS v0.06]
[PLUGIN:SDCARD v1.21]
[PLUGIN:FS macro plugin v0.16]```

[terjeio]

Do you have homing feedrates per axis enabled? If so Y differ from X?

It's also not clear which mode is it using for houming - StelthChop or CoolStep

StealthChop

[calabr]

Do you have homing feedrates per axis enabled? If so Y differ from X?

It's not enabled. Speed is the same.
If homing axis movement separated 1st Z, 2-nd X, 3-d Y - homing completes successfully.

[terjeio]

I do not have hardware for testing, and the code looks ok. What happens when it fails. Alarm? Freeze? ...?

I see in the datashet that a pulse is output on stall, since detection is done by polling the DIAG signals it could be that it is missed? AFAIKT there is no mention of how long the pulse is in the datasheet so it might be a plausible explanation if the Y hits moments after the X. Does it fail in the same way if you move Y a bit further away from the end than X before homing?

[terjeio]

Thinking about this a bit more - perhaps having different pull-off distances for X and Y will solve the issue? The homing pullof plugin can be used to configure that.

[calabr]

Does it fail in the same way if you move Y a bit further away from the end than X before homing?

no difference which axis come first to the stopper. X finishing location move and waiting for Y
Y just keep moving and loosing steps, so I assuming it's should trigger StallGuard again if first touch was missed.

Pull-off distance should not influence - Y axis failed on first locating move.
If I'm disconnecting DIAG jumper and connect switch instead Y works normally so it's isn't GRBL logic error
I think Y driver become not initialized for homing either threshold or stallguard enable failed.
Unfortunately I cannot enable StallGuard for other than homing - it's disabled in driver. My target with sensor-less is more to detect step loosing and replace hard limits.
Is it any way to activate and monitor it's state in real time? M122 not available during homing and Run state

[terjeio]

Y just keep moving and loosing steps, so I assuming it's should trigger StallGuard again if first touch was missed.

Can you scope the DIAG signal from Y?

Is it any way to activate and monitor it's state in real time?

M122YS1 - polls driver every 20ms when axis is in motion and outputs sg_result. This is likely to interfere with detection of the DIAG signal...

[terjeio]

I have just committed an update to the motor plugin where I have refactored the homing code, I am still not able to test it in a machine but by simulating stalls I can see pulses on the outputs of the Y driver when both X and Y is homed in the same cycle.
I have also added StallGuard result for both motors for ganged/auto-squared axes which will crash ioSender, to fix that and also improve a bit on plotting I have uploaded a new edge build (p2). The latest edge build when used with the new motor plugin should now be able to plot the StallGuard result more reliably when homing is initiated from the Trinamic tuner tab. I have also added support for the M122 P word, use it to set the report interval (in ms) - default is 20 ms which may be a bit short for TMC2209.

Finally I have added an option to enable SR-latching of the stall output, this enables interrupts for the limit inputs while homing and latches on the first edge. Enable by uncommenting this line. I have only bench tested this so nice if you would check it out.

[calabr]

Нou are incredible @terjeio !
but to-fast for me. In normal single axis homing DIAG pulse are 130 - 150us sometimes shorter pulse are coming before ( near 200-300us before), but it's half in amplitude.

in case 2 axis are moved together - no pulse at all
if X and Z set to home in first pass - Z are cannot stop.
Looks like second axis not configured for StelthChop
If I'm trying to set M122xyS1 - only X are set for StelthChop and threshold. It might be the same behavior.

Tested latest IoSender - graph is more readable and shows plot during homing. It's a bit confusing for the first time the lower SG value are on the top, so adding the scale should be helpful.

I'm still preparing to build firmware by myself - little bit lost where to configure build parameters
I'm changing it in inc/my_machine.h, grbl/config.h boards/..._map.h - is any common safe palce?

Regarding TMC driver parameters - I need to find TMC configuration for my setup - at least now X-axis works better in StelthChop, Z-inly in CoolStep , but driver config always dropping it to CoolStep on reset.
I think it's related to step interpolation, and PWM frequency which cannot be controlled in runtime. In general TMC2209 cannot maintain speed and torque, I get from DRV8825/S109 on this machine.
@terjeio what is the right place to override TMC2209 default settings?
Is it any way to dump all current TMC settings, set registers in runtime without recompile - like provide hex values with debug M-code command.

[calabr]

In STM32F401 folder I see LD-script STM32F407VGTX_BL48K_FLASH.ld which is most close to MKS robin board, but My board is MKS Robin Nano v3.1 with STM32F407VET whish is 512Kb flash - should I re-build .ld for this CPU?
I'm using STM32Cube IDE

[terjeio]

Looking again at the schematic I see that the driver DIAG outputs when linked to the MCU via J17 are connected via a pullup resistor and a resistor in series with the MCU input, there is also a capacitor to ground for filtering - all without values. The limit switches inputs are wired together with the DIAG inputs which will be an issue if they are connected and of NC type or three-wire and switching between 5V and GND. The TMC2209 driver chip (and SilentStepStick drivers I have) has push-pull output for the DIAG signal unlike other TMC drivers that has open drain outputs. So the TMC2209 drivers will likely not be happy with having the DIAG pin driven by any externally applied voltage. Anyway, I assume you do not have limit switches connected and driving the inputs while trying sensorless homing...

In normal single axis homing DIAG pulse are 130 - 150us sometimes shorter pulse are coming before ( near 200-300us before), but it's half in amplitude.

This means the homing routine is stopping the motor as it should. When I test I get repeated pulses of some milliseconds in length since I have not wired the DIAG output to the limit input. I get these pulses even when homing two axes at the same time.

adding the scale should be helpful.

It is on my todo list - there should be a line for the current StallGuard limit setting too.

I'm still preparing to build firmware by myself - little bit lost where to configure build parameters

For most configurations Inc/my_machine.h is the main file to edit. grbl/config.h is for configuring the core and must be edited if stuff like > 3 axes are required - unless the options needed are passed from either a platformio.ini file or compile command line arguments (which can be defined in the STM32CubeIDE UI). Defaults for plugins like the motor plugin can be added to Inc/my_machine.h if they are overridable (enclosed in #ifndef ... #endif or commented out).

Is it any way to dump all current TMC settings, set registers in runtime without recompile - like provide hex values with debug M-code command.

If compiled with #define TRINAMIC_DEV 1 then M123 and M124 can be used to read/write registers. R is the register address, O value to set. I have not tested these commands for a long time so I cannot guarantee that they work.

should I re-build .ld for this CPU?

No, not needed. If you program with a SD card then use the 8MHz 48K bootloader version.

I'm using STM32Cube IDE

Then select the build from the "hammer" tool dropdown:

[calabr]

Finally I ended up with new linker script, board config and machine settings.
After trinamic driver update behavior are significantly changed-
Drivers started to produce more torque and stable fast move. but also more current. looks like chopper frequency become 37KHz ( was 60KHz before)
Current setting now producing lot more real current - it's feels like previous setting of 2.5A equal to 1A now. power consumption and heat produced by the driver is also increased. Both, StelthChop and CoolStep are improved.
Sensorless homing working correctly now, but require different tuning of speed and SG threshold. slow motion 25mm/min are now triggering SG without barrier. 50-60mm/min is Ok. I'm also set lower de-bouncing timeout for homing.
First DIAG pulse are still the same 130 - 150us, second locating pulse are near 4.5ms

I'm not sure TMC2209 are recognized and configured accordingly. it's probable configured as different TMC chip
Current setting are not much, IoSender do not allowing to set current higher than 1700, chopper settings are disappeared from IoSender grbl setting window. m122 displaying different Vref value - 0=0.318 instead of 0=0.137 before. not sure if I correctly enabled extended TMC driver settings.

Robin_TMC2209.zip
I see the warning from compiler

  271 | TMC2660_drvstatus_dgr_t TMC2660_ReadRegister (TMC2660_t *driver, TMC2660_datagram_t *reg, tmc2660_rdsel_t rdsel)
      |                         ^~~~~~~~~~~~~~~~~~~~
In file included from ../trinamic/tmc2660.c:48:
../trinamic/tmc2660.h:354:25: note: previous declaration of 'TMC2660_ReadRegister' with type 'TMC2660_drvstatus_dgr_t(TMC2660_t *, TMC2660_datagram_t *, uint8_t)' {aka 'TMC2660_drvstatus_t(TMC2660_t *, TMC2660_datagram_t *, unsigned char)'}
  354 | TMC2660_drvstatus_dgr_t TMC2660_ReadRegister (TMC2660_t *driver, TMC2660_datagram_t *reg, uint8_t rdsel);
      |                         ^~~~~~~~~~~~~~~~~~~~

and no any messages about TMC2209

[terjeio]

After trinamic driver update behavior are significantly changed

Found it, a typo in the top level configuration file for the Web Builder for the R sense value.

Sensorless homing working correctly now, but require different tuning of speed and SG threshold.

This is due to the incorrect R sense value.

I'm not sure TMC2209 are recognized and configured accordingly. it's probable configured as different TMC chip

No way, initialisation would fail and you would not get the Trinamic tuner tab in ioSender. You can see which chip is actually configured in the top of the M122 output:

                      X       Y       Z
Driver          TMC2209 TMC2209 TMC2209
Set current        1500     500     500
RMS current        1492     490     490
Peak current       2110     692     692
Run current       26/31   15/31   15/31
Hold current      13/31    7/31    7/31
CS actual         13/31    7/31    7/31
PWM scale            15       9       9
vsense          0=0.325 1=0.180 1=0.180

Current setting are not much, IoSender do not allowing to set current higher than 1700

The incorrect R sense value allowed higher current settings than should be possible.
Current is set by CS value in the range 0-31, max current for a given R sense is 31 and current in mA is calculated from that.

chopper settings are disappeared from IoSender grbl setting window.

Add #define TRINAMIC_EXTENDED_SETTINGS 1 to my_machine.h to get them back.

m122 displaying different Vref value - 0=0.318 instead of 0=0.137 before.

Vref (vsense) displayed is dependent on the current setting - see the M122 output above.

I see the warning from compiler

A typo - you must have a newer compiler than me or with different settings because I do not get it.