Backlash Settings only Queryable while Enabled ?
Should I expect the backlash parameters set with
not to be queryable when the drive is disabled?
My use of
Returns 0 for both while the drive while the drive is disabled but returns the values I gave it when the drive is enabled.
I found this counterintuitive, (especially since I can set the parameters while the drive is disabled, but I cannot verify that they’ve been set without enabling), but just so that I have informed expectations, is this expected behavior. The docs point out that backlash doesn’t use PUUs (which I assume doesn’t mean that it “ignores” position factor—because that’s used by the drive natively, right?), but nothing about the need to enable the drive to query the settings.
The “Backlash Compensation - Docs” page has a small typo: In the “RapidCode API Usage” section, “BacklashRetSet” is mentioned twice, once when “BacklashRateGet” seems intended.
Also, the docs for the specific backlash APIs have “See Also” links. Could I suggest that each of these link at least to the analagous get/set action for the same parameter and the same action for the “sister” parameter? If I wanted to move around to all the backlash API’s, I can’t do it without going back to search results, the entire Axis API, or the backlash topic doc.
This is expected behavior. The rate and width are overwritten to 0 while the axis is disabled to make sure no offsets are applied while the axis is idle. I understand that make is a bit difficult to verify it has been set correctly.
I’m not sure what you mean by PUU. Do you mean UserUnits ? That is correct that this feature uses drive counts an not UserUnits.
Thanks for the documentation feedback. I agree it can be a bit hard to navigate at times and we will work on improving navigability.
I’m seeing my attempts to set these values—when the drives are (very recently) enabled—failing.
In our enable sequence, we
AmpEnableSet() all the axes, then wait for them all to report
AmpEnableGet() == true, then we set backlash values (width, rate).
I added some logging to our code. Just after I set the width/rate, I get the current values and log them. What I routinely observe is that the setting the width will not be effective, but setting the rate will be.
If I wait long enough after they’re enabled, I can set the values. What do I need to wait for?
Based on the docs, I would expect that if RMP reports that the drive is enabled, then I can go ahead and set the backlash values. Is that accurate? Are there other conditions I need to wait for before setting values?
Two recent improvments might be affecting the behavior you’re seeing.
Some drives take hundreds of milliseconds to enable. So we strongly recommend using the new AmpEnableSet() overload which takes a timeout (milliseconds). This will wait for the drive to signal that it is actually enabled. You can also check this yourself with:
Note the 10.3.6 fixes any issues where you may have seen a “clunky” amp enable - we used to see this on systems with very slow enable times.
The latest AmpEnableGet() docs have this note:
Apr 7, 2022
- [New] AmpEnableSet() improved. Waits for AMP_ACTIVE before discontinuing command=actual.
Feb 1, 2022
- [New] Axis/MultiAxis AmpEnableSet() overload for timeout waiting for AMP_ACTIVE.
I think you’re having to wait for the RMP firmware’s cmd=actual to be disabled. With 10.3.6, that can occur later than with earlier releases. (Which results is much smoother/safer AmpEnable.)
I added an arbitrary delay before applying the backlash settings, and I see better behavior.
I’ll switch my “is enabled” getter to use what you/the-docs recommend. Thanks.
Also, what is the “backlash value”? The documentation describes it as the “calculated backlash compensation value” but I still don’t know what that is. How does it relate to the width/rate? Is this value some sort of industry lingua franca for backlash compensation?
The backlash value is the current value being applied in the Axis firmware.
The value is calculated each sample as the previous value + (backlash rate * sign of the commanded velocity), clipped by the backlash width.
We don’t know the etymology of these terms.
I noticed that RapidSetup displays this quantity for each drive. Is it likely that I’ll ever be able to see it when it’s not zero? I suppose if you set the rate to something very slow (e.g. thousands of samples), RapidSetup would update frequently enough for me to see something.
Yes, I would expect you could see it in RapidSetup. Or you could try recording it with RSIAxisAddressTypeBACKLASH_VALUE .