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.
Docs
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:
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.)
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?
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.
