Setting up an axis with positionmodulo, where the physical resolution pr turn is not a integer in drive-increments causes the position to drift when multiple turns are performed on the axis.
Motor: 4096 inc/rev
Gearing 640:28
TechUnits: 360 dgr modulo =>
.iRatioTechUnitsNum = 63
.dwRatioTechUnitsDEnom = 16384
.fPositionPeriod = 360
.dwOneTurn = 93623 (Wich is not precise)
.iRestNumerator = -9
It is clear that after 63 full turns you will have a integer-no of incrments:
No increments = 36063 / (63/16384) = 36016384 = 5898240
And the AXIS_REF.iTurn also reaches this number (63) before roll-over, but the
position in AXIS_REF.fActPosition still does not track correctly.
Axis started in:
.dwActPosition = 0 inc
.fActPosition = 0 dgr
After running for some time:
.dwActPosition = 834859476 (Raw 32bit position from drive)
.fActPosition = 89.151 dgr (Not correct - I think)
If I perform modulo calculations on that I get: 94.049 dgr as ActPos as correct
position.
But if I calculate by using .dwOneTurn I get: 89.15dgr as ActPos!
Clearly CoDeSys is not tracking the modulo residuals correctly .....
When the roll-over occurs the variable .iPosOffSetForResiduals get updated every modulo turn, the resudual value shifts by dwOneTurn.
But when .iTurn rolls over .iPosOffSetForResiduals does not get corrected by
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2008-03-03
Originally created by: Nicolai_Hanssing
3S Software has acknowledged, reproduced and solved the bug described above. The residual issue is solved by Hilmar Panzer in SM_DriveBasic.lib ver. 1.9.4.1 wich has yet to be released.
To make sure your not affected by the bug, just confirm that your modulo-value in drive increments are a whole noumber. This can be read out from the AXIS_REF.iRestNumerator == 0.
Regards
Nicolai Hanssing, M.Sc.
Delta Elektronik A/S
Denmark[/b]
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Originally created by: Nicolai_Hanssing
Setting up an axis with positionmodulo, where the physical resolution pr turn is not a integer in drive-increments causes the position to drift when multiple turns are performed on the axis.
Motor: 4096 inc/rev
Gearing 640:28
TechUnits: 360 dgr modulo =>
.iRatioTechUnitsNum = 63
.dwRatioTechUnitsDEnom = 16384
.fPositionPeriod = 360
.dwOneTurn = 93623 (Wich is not precise)
.iRestNumerator = -9
It is clear that after 63 full turns you will have a integer-no of incrments:
No increments = 36063 / (63/16384) = 36016384 = 5898240
And the AXIS_REF.iTurn also reaches this number (63) before roll-over, but the
position in AXIS_REF.fActPosition still does not track correctly.
Axis started in:
.dwActPosition = 0 inc
.fActPosition = 0 dgr
After running for some time:
.dwActPosition = 834859476 (Raw 32bit position from drive)
.fActPosition = 89.151 dgr (Not correct - I think)
If I perform modulo calculations on that I get: 94.049 dgr as ActPos as correct
position.
But if I calculate by using .dwOneTurn I get: 89.15dgr as ActPos!
Clearly CoDeSys is not tracking the modulo residuals correctly .....
When the roll-over occurs the variable .iPosOffSetForResiduals get updated every modulo turn, the resudual value shifts by dwOneTurn.
But when .iTurn rolls over .iPosOffSetForResiduals does not get corrected by
'iRestNumerator' as it should since:
iRatioTechUnitsNum * dwOneTurn = 5898249 = fPositionPeriod*dwRatioTechUnitsDEnom - iRestNumerator
Am I completely of the bat here?
Or is this a bug in CoDeSys Softmotion?
Nicolai
Originally created by: Nicolai_Hanssing
3S Software has acknowledged, reproduced and solved the bug described above. The residual issue is solved by Hilmar Panzer in SM_DriveBasic.lib ver. 1.9.4.1 wich has yet to be released.
To make sure your not affected by the bug, just confirm that your modulo-value in drive increments are a whole noumber. This can be read out from the AXIS_REF.iRestNumerator == 0.
Regards
Nicolai Hanssing, M.Sc.
Delta Elektronik A/S
Denmark[/b]