IndRMove - Sometimes ends at correct spot, sometimes at 180 degrees

bwinter714

Hi, I have a simulation I'm using to demonstrate how IndRMove works to a company that bought some equipment I integrated and they're trying to program.

I'm having trouble simulating it, and unfortunately, I don't have the real robot to determine if it is an issue with RS or this is how it actually will work if they used this example code. I have done this in numerous other systems and haven't ever seen an issue before. 

Code is below (removed TPWrite statements for clarity):

        ActUnit M7DM1;

        IndCMove M7DM1,1,200;

        WaitUntil IndSpeed(M7DM1,1 \InSpeed) = TRUE;

        WaitTime 5;

        IndCMove M7DM1,1,0;

        WaitUntil IndSpeed(M7DM1,1 \ZeroSpeed) = TRUE;

        IndRMove M7DM1,1 \ToRelnum:=0 \short , 50;

        WaitUntil IndSpeed(M7DM1,1\ZeroSpeed) = TRUE;

        waittime .5;

        IndReset M7DM1,1 \RefPos:=pTableZero \Short;

So depending on how fast I rotate, the axis will end up at different positions at the end of the 5 seconds obviously. But based on that rotational speed and where it ends up, the table will do different things when the IndRMove is executed. Sometimes, it goes right to the correct spot of a relative 0, and sometimes it moves to an incorrect spot of a relative 180. I have attached videos showing this. I would expect that anytime I execute to a relnum of 0, the axis position ends up at a multiple of 360. 

Also, I have tried the \fwd and \bwd switches, and it never crosses the 180 mark. If I use fwd and the orange box on the table ends up in the blue zone, it rotates forward (CCW) but stops at the red line at 180 degrees. If it ends in the brown zone in the picture it goes to the right spot. Vice versa for \bwd. 


I know I can easily figure out if it is at the right spot by checking the remainder of the current position / 360 and make a decision about how to IndReset based on that, but am I missing something? 

I tried attaching videos of it in action using the same code but 2 different speeds, but it isn't letting me attach them here. The link to them are here: https://photos.app.goo.gl/LXinPs2qCDSm43zG9

Thanks for the help! 

-Brian 

Forge_Engineering

Hi Brian, 

We have a rotator as well although I didn't integrate the system,
ours doesn't have this issue when running the same code.
What happens if you stop the IndCMove, use IndReset and then IndAMove to get back to 0, 
Does it still have the same issues?

Reagrds,

Harry

bwinter714

Hi Harry, it has been a while since you commented, I'm sorry I must not have had notifications turned on. But I have installed this system in the field, and the robot behaves the same way using my original code.

Doing what you suggested, doing an IndReset and then an IndAMove just unwinds the axis. 

What I ended up doing is getting the modulo, and I execute an IndRMove either forward or backward so it goes towards the true 0 depending if it is >180 or not. It seems to work, however, the resolution is not very good. I found that I am off by +/- 1.7 degrees each time, and the error stacks. I have checked that the transmission settings are correct, and when I use the robot pointer at the zero position of the table and rotate M7 a full revolution, it is exactly 360 degrees.  I know the resolution suffers the higher the count, but that's pretty egregious for the amount of rotation we are talking about. 

I'm very confused as to why it is behaving this way! 

Do you think I should get the modulo, then do an IndReset and use the \RefNum:= *modulo* and then use an IndAMove to get back to zero? It just seems like there is something else going on here, I haven't ever had to do this before. 

-Brian

Forge_Engineering

Hi Brian, 

Did you use the \RefNum and \Short arguments in your IndReset the first time when you said the axis just unwinds? When it unwinds does it just do 1 revolution, or actually unwind all the revolutions? And is the direction for this last movement back to 0 important, or can it go in either direction? 

I would have thought that:

IndReset Mecunit, AxisNo, \RefNum := 0, \Short;
IndAMove MecUnit, AxisNo, \RefNum := 0, 50, 

would do the trick. 

I'm still surprised it behaved the way it did with IndRMove. 
If it says it's doing 360 degrees in one revolution then it shouldn't be an issue with the configuration,

Harry

bwinter714

Hi Harry, thanks for the reply! I wasn't using the switches, my mistake, it doesn't unwind itself anymore, but the table model jumps 180 degrees the instant I use the IndReset function, and which in practice, sets the table to be 180 degrees out of position. This is a big deal, it's in an aircraft repair facility... 

I have left a link to the video of it running and what happens to the table. Test code is pasted below:

  PROC TestTableReset()

        VAR num nCurrentPosition;

        ActUnit M7DM1;

        Waittime .5;

      

        IndCMove M7DM1,1,132;

        WaitUntil IndSpeed(M7DM1,1 \InSpeed) = TRUE;

        Waittime 10;

        IndCMove M7DM1,1,0;

        

        WaitUntil IndSpeed(M7DM1,1 \ZeroSpeed) = TRUE;

        

        Waittime 1;

        IndReset M7DM1,1 \RefNum:=0, \Short;

        

        waittime 1;

        

        IndAMove M7DM1,1 \ToAbsNum:=0,100;

 

    ENDPROC

Link to video:
https://photos.app.goo.gl/Lm8KM81k22LdpaXh8

I agree this is strange behavior, and very frustrating! 

Thanks!

-Brian 

Forge_Engineering

Hi Brian, 

There is no way that IndReset should have that kind of behaviour, it shouldn't cause any movement.
Thanks for sharing the video; from looking at the values before and after the reset it seems like IndReset is reducing to the nearest 180.
My guess is some kind of mismatch in the machine configuration causing the controller to display angles correctly at 360 degrees per revolution but somehow be operating in 180 degrees per revolution.
I'll see if I can recreate the same behaviour on my system, otherwise I'm all out of ideas, short of setting up the system again. 
Regards,

Harry

Forge_Engineering

Hi Brian, 

I was able to recreate the behaviour you have by changing my "Transmission" Settings under the "Motion" Configuration.



I set my transmission High/Low gear ratio different to my transmission gear ratio value, half the value basically.
From reading into it, the robot uses the transmission gear ratio when the axis is in coordinated mode, and uses the ratio between transmission gear high and Low when in independent mode (IndRMove etc.).

My guess is that in this case using Ind Move commands rotates with a different gear ratio to normal and when IndReset is executed the controller looks at the motor encoder value to figure out what the joint angle should be based on the Transmission gear ratio. The difference in transmission ratios causes the joint angle to change when moving from independent back to coordinated mode. 

No idea why it works this way, but our rotator is configured so that Transmission gear high and transmission gear ratio are the same, and transmission gear low is set to 1. 

Hopefully you have the same issue and this fixes it, 
Good Luck, 

Harry

bwinter714

Hi Harry, that was it! I just looked and you are 100% correct, my Transmission Gear High is somehow set to 1/2 of the Ratio! I was actually thinking about that this morning after dropping my son off at school, I seemed to remember seeing something like that and was going to investigate it today, but you beat me to it! After setting the ratios to be the same it works exactly like it should. I was kind of figuring it had something to do with the configuration somewhere, as you mentioned that is not what should happen with an IndReset command. 

Cheers Mate! AUS is at the top of my list to visit, if I'm ever up your way I owe you a few pints! 

-Brian