Cannot properly tune StallGuard Threshold into a functional regime

[r-a-i]

Hi,

I working on a project using the OpenBuilds C-Beam linear actuator with a NEMA 23 driven by a BigTree TMC2130 V3.0 Stepper and controlled by an Arduino MEGA2560.

SPI communication works well and the motor/stage moves very smoothly, but for the life of me, I can't seem to find a proper value for the StallGuard threshold for sensorless homing. Perhaps I'm asking more of StallGuard than is expected. My project is a tensile tester that moves a linear stage to strain/stress a sample while measuring the load (via a load cell) and as such is intended to have several configurations of linear-stage grippers and load cells. I went with the TMC2130 (over A4988 + limit switch) thinking that I could have StallGuard enabled all the times and use it to detect collisions if ever. I leaped into this knowing the Prusa MK3 can detect collisions using these drivers, but as I write this, I realize that perhaps they do that counting missing steps. Are my initial expectations wrong?

Regarding specific tunning, I've followed the recommendations on the TMC2130 (set threshold at low velocity) but I find that if I set the threshold too sensitive (say 11) then StallGuard fires false positives when starting to move the stepper, and if I relax the threshold (say 12) it does not detect a collision. Furthermore, the results are somewhat inconsistent on both sided. Am I missing something? I've tried with StealthChop on and off. I see #6 says StallGuard does not work with StealthChop but I cannot find this explanation on the DataSheet and I actually do see the DIAG1 signal firing and SG_RESULT reported when StealthChop is on.

Overall, my application was supposed to be simple and I was looking for one set of parameters that could work through my entire operation range. Was this wrong and the homing process needs to be very carefully orchestrated for StallGuard to replace a limit switch? For example, do I need to start the motor moving and then update the StallGuard_Threshold?

After fiddling with this for a few days (n more than intended), I installed a limit-switch and can move on, but I figured I should share my findings with the community.

These are the specific parts I'm using: C-Beam Linear Actuator: https://openbuildspartstore.com/c-beam-linear-actuator-bundle/ TMC2130 V3.0 Stepper: https://www.amazon.com/dp/B07RSX2W3V/ref=cm_sw_em_r_mt_dp_U_1abzDbYN7F7EG

[teemuatlut]

Hey, really great to see the library and the drivers used for other projects than just printers!

My understanding is that the MK3 has stallGuard reporting always on when it sees a triggered "endstop" while printing, it'll know to home again.

With stallGuard (v1, like on TMC2130) you can only measure the back EMF when the motor is current driven, as opposed to voltage driven like with stealthChop. This therefore means that the load can only be measured when in spreadCycle mode. Homing with stallGuard is just interpreting this measured value.

The main point that comes to mind is that based on my own experience the stallGuard doesn't work well if the steps are not nicely equally spaced out. Use interrupts for stepping! Also you should try to avoid jerky movements -> low acceleration. But not sure if this is an issue in your application. You can also implement a guard period; for a brief duration after starting a motion the stallGuard signal gets ignored.

[r-a-i]

Thanks @teemuatlut !

This explains why the MK3 has two modes: Collision detection or Stealth. Unfortunately, the data-sheet is not very clear about this. At least not in an obvious and explicit way.

I'm driving the STEP signal with an interrupt and the timing is very stable. I'm doing double-edge detection--something we had discussed previously in a Marlin thread, and which is for another project.

My application is very simple and I was intending to do square velocity profiles and keep the interrupt routines to a minimum, but next time I'll consider ramping up speed to keep acceleration low, or maybe guarding the first few steps.

For now, the limit-switch is working and I have another million things to do, but this is a great library and the drivers are nice.

For other projects, are there new TMC drivers that I should consider as a replacement to the 2130?

P.S. I had compilation issues because I'm pulling in the library as a git submodule for easy migration between different computers. I had to move some files and tweak some includes to compile. I did this in a fork. I think this would also compile for people including the library into the IDE. Let me know if you'd like to explore this and we can create an issue specific for this and explore a pull-request.

[merabmali]

This post is kinda old but I had a similar problem and can share the solution:

To avoid false positives at low speed the TCOOLTHRS must be set. To correctly set the value do the following:

1. Read TSTEP - you can see that for larger velocity it decreases and vice versa. This is kinda obvious, because it's just time btw two successive microsteps (see the documentation).
2. Start at low velocity and slowly increase. As the TSTEP decreases find a specific value at which you want Stallguard to activate.
3. Now set TCOOLTHRS to that value.

What will happen is that for smaller velocity you're gonna have condition TSTEP > TCOOLRTHS - so the Stallguard will not fire. For higher velocity you will have TSTEP < TCOOLTHRS - and the Stallguard will become active. You can also set the high velocity threshold - check THIGH parameter.

Hope this is useful, Cheers