cancel
Showing results for 
Search instead for 
Did you mean: 
SOLVED

CODESYS SoftMotion: Command position rollover for modulo axes

bostroemc
Established Member

CODESYS SoftMotion: Command position rollover for modulo axes

With a SoftMotion axis configured as "modulo",  it had been observed in a variety of cases that the position command value is failing to rollover at the defined modulo.  

drive_1_configuration.png

For example, with MC_CamIn (see attached for cam definition):

mc_camin_rollover_1.png

The consequence of this is that for sufficiently large commanded position, the axis stops:

mc_camin_rollover_2.png

MC_GearInPos and MC_MoveRelative behave similarly.  

Am I missing something in the setup?

Test axis: IndraDrive, MPB-20 firmware.  CODESYS SoftMotion 4.10.0.0.  ctrlX CODESYS Softmotion Adapter 1.10.0.3.

 

4 REPLIES 4
eschwellinger
Member

Re: CODESYS SoftMotion: Command position rollover for modulo axes

for me it looks like modulo is configured in the drive too, but the SoftMotion driver expects that the drive does not do modulo handling. This will be done by the SoftMotion.

So I would recommend to check/change the position data format from “Modulo” to “Absolute” in the drive.

bostroemc
Established Member

Re: CODESYS SoftMotion: Command position rollover for modulo axes

Thanks, eschwellinger. 

It appears that it is not enough to simply switch the position data format to Absolute.  The issue is that in this case the drive's actual position is rolling over at the Maximum travel range value (S-0-0278):
 
 
 
 

2021-10-27_15h38_22.png

and I still see the physical axis come to rest once the commanded position becomes sufficiently large:

2021-10-27_15h50_02.png

I did verify that by setting S-0-0278 to its maximum value, namely 214748.3647 = (2^31 - 1) / 10000, I could force the commanded and actual positions to rollover simultaneously:

2021-10-27_15h56_31.png

In this case it looked like I was able to run in "endless" mode without error. 

Setting the max. travel range this high has implications on our absolute encoder evaluation - we'll review internally how best to handle this.

If you edit your post to include a reference to my comments here, I'll accept yours as the answer.  

 

bostroemc
Established Member

Re: CODESYS SoftMotion: Command position rollover for modulo axes

As an alternative to the workaround described above, I've found that SoftMotion parameter dwBusModuloMask may be used to force rollover of the position command at a value compatible with the internal drive modulo.  This approach will (in typical cases) allow us to retain the drive's absolute position reference  while maximizing the internal position resolution.  For example, setting dwBusModuloMask = 2^18 - 1 = 262143, we may configure the axis as follows:

softmotion_dwBusModuloMask.png

Running the cam described in the original post now yields the following.  Note that the position command value rollover now corresponds with the actual drive position. 

softmotion_MDT_rollover.png

I've tested this configuration for 4+ hours and see no problems and no position drift.  Moreover, the position is retained on program restart or power cycle.  Both forward and backward operation has been verified.

@eschwellinger:  Am I missing anything?  Was there a specific reason you did not suggest adjusting dwBusModuloMask?

Also, following the documentation I've assigned dwBusBandWidth a value of 262144 = 2^18.  What does this parameter do?   

 

eschwellinger
Member

Re: CODESYS SoftMotion: Command position rollover for modulo axes

First of all, my preference would be to set the max. travel range to 2^31-1. This is how SoftMotion expect drives to behave.

dwBusModuloMask is an internal variable, so I would not recommend to set it.

The thing with the max. travel-range and the absolute mode of the drive would be an important info for the commissioning guide.

https://www.boschrexroth.com/documents/12605/30723711/CODESYS+SoftMotion+%26+IndraDrive+%E2%80%93+Et...

Instead of using the internal variable dwBusModuloMask  I would recommend to use:

SMC_SetBusBandWidth

But as I said... usually this should not be needed.

 

 

Icon--AD-black-48x48Icon--address-consumer-data-black-48x48Icon--appointment-black-48x48Icon--back-left-black-48x48Icon--calendar-black-48x48Icon--center-alignedIcon--Checkbox-checkIcon--clock-black-48x48Icon--close-black-48x48Icon--compare-black-48x48Icon--confirmation-black-48x48Icon--dealer-details-black-48x48Icon--delete-black-48x48Icon--delivery-black-48x48Icon--down-black-48x48Icon--download-black-48x48Ic-OverlayAlertIcon--externallink-black-48x48Icon-Filledforward-right_adjustedIcon--grid-view-black-48x48IC_gd_Check-Circle170821_Icons_Community170823_Bosch_Icons170823_Bosch_Icons170821_Icons_CommunityIC-logout170821_Icons_Community170825_Bosch_Icons170821_Icons_CommunityIC-shopping-cart2170821_Icons_CommunityIC-upIC_UserIcon--imageIcon--info-i-black-48x48Icon--left-alignedIcon--Less-minimize-black-48x48Icon-FilledIcon--List-Check-grennIcon--List-Check-blackIcon--List-Cross-blackIcon--list-view-mobile-black-48x48Icon--list-view-black-48x48Icon--More-Maximize-black-48x48Icon--my-product-black-48x48Icon--newsletter-black-48x48Icon--payment-black-48x48Icon--print-black-48x48Icon--promotion-black-48x48Icon--registration-black-48x48Icon--Reset-black-48x48Icon--right-alignedshare-circle1Icon--share-black-48x48Icon--shopping-bag-black-48x48Icon-shopping-cartIcon--start-play-black-48x48Icon--store-locator-black-48x48Ic-OverlayAlertIcon--summary-black-48x48tumblrIcon-FilledvineIc-OverlayAlertwhishlist