Hello guys,
I have a general and genuine question regarding motion control in B&R systems:
Absolute or relative motion is considered complete (DiscreteMotion = 0, Standstill = 1, MoveActive = 0, etc.) when the theoretical position from the setpoint generator is reached.
However, in some cases, the motion may still be physically active due to lag error (for example, caused by incorrect motor dimensioning).
So my simple question is: why are the theoretical values evaluated rather than the actual (measured) ones?
Thank you
Best regards
Michal Malek
Hi Michal,
the simple answer is: because you will never reach exactly the target position. It will always move a little bit around the set position (control theory). If you want to check the actual position also, you can use for example MC_BR_ReadCyclicPosition with ValueSource = mcVALUE_ACTUAL.
Best regards
Waldemar
Hi Waldemar,
Youâre certainly right, and it makes sense regarding the target position recognition. And of course, I can determine the exact state of the axis in many other ways.
However, itâs quite confusing when the axis output state shows standstill (no movement, in position, etc.), while in reality, the axis is still moving, as shown in the following picture:
Certainly itâs little bit exaggerated but the axis in full movement(!) has output state standstill!
Regards
Michal
Hi Malek,
in the trace it looks like you get the standstill bit if the axis is in standstill⌠Can you show the cursor and the values, please. For me it looks fine
Thx Waldemar
Hello,
You are both correct in a certain way.
Normal the LagError-Limit is considert to be the limit between Act-Position and Set-Position. And we asume that the Act-Position follows the Set-Position in this Limit.
This limit should be as small as the process allows.
With this consideration the Standstill is reached with Set-Position and we assume then that Act-Position is in this Area were it is allowed to be (LagError =>Position Threshold/Window).
We can clearly see that the Lag-Error behaviour of this axis looks not in the normal desired way. And yes there is a movement due to the controller active at the position, Waldemar marked.
I think your LagError Limit does currently not match the limits the Application would have to stay in for normal operation as you mentioned the drive is to small.
For ACP10 i remember there was a Setting âT_in_Posâ
But for MappMotion i think this Setting was removed, because every machine is allways to slow and should get faster⌠so there is no time to wait.
With a proper Axis Dimension and propper LagError Setting the normal behaviour of the system should be fine.
But for the untypical behaviour were the LagError is set to huge Values to prevent the Error while moving. I think you have only the possibility to use a other indication of knowing when the position is reached. (Read ActPosition and Compare to TargetPosition with Threshold)
Edit: Another option is to reduce the dynamic of the profile so the smaller motor can follow the created movement profile and the lagError can also set to normal values. The movement would be longer and represents the real movement. The Standstill would also occure on an more optimal timing.
Greetings
Michael
1 Like
Hi Waldemar,
I get the standstill bit exactly when the axis reaches the standstill condition but based on the value from the setpoint generator (ActPosition), not the actual position (ActPosition - ActLagError).
In reality, the axis is still in motion, as the lag error indicates.
Regards
Michal
Hi Malek,
as Michael wrote, your lag error behavior is not good. you should tune your axis and set the lag error limit to a proper value. How high is the lag error? and what is your position error limit? Did you tune your axis? Do you have a hanging load? If so then you need a integrational part in your controller.
Best regards
Waldemar
2 Likes
Hi Waldemar,
The lag error behaviour undoubtedly reflects a lack of voltage, and this cannot be corrected by any controller settings (although the axis has been tuned).
You are certainly right about the behaviour (this trace is for demonstration purposes only and, as I mentioned, is a bit exaggerated), but that doesnât address the original question.
Iâm just curiousâam I the only one who finds this irritating?
Regards
Michal Malek
Hi Michal,
I fully understand your irritation. I think a parameter like âinPositionWindowâ would be helpful here.
Best regards
Hello Michael,
I fully understand your points and agree that the majority of applications do not tolerate virtually any lag error, and therefore the current concept is satisfactory.
However, there are some applications (and I have personally worked on several) where things donât go perfectly, as one would ideally desire, and some lag error must be accepted.
Moreover, once you allow for any lag error, you must also accept a settling time that deviates from the ideal (sometimes significantly).
As I mentioned above, I know how to manage this in non-typical applications, but I still find it difficult to accept as âcorrectâ when the outputs can be clearly incorrect.
Regards
Michal Malek