Send the current position of the robot through profinet

To monitor current position:

Set $SCR_GRP[1].$M_POS_ENB to true

Then for current joint angles you can monitor

$SCR_GRP[1].$MCH_ANG[0 to 6]

And for current Cartesian position relative to active Frames you can monitor:

$SCR_GRP[1].$MCH_POS_X (and y,z,w,p,r)

To monitor current TCP speed:

Set $SCR_GRP[1].$M_DST_ENB to true

and monitor $SCR_GRP[1].$MCH_SPD

To send position to the PLC you can create a BGlogic program to copy the current position values from the system variables into registers. Then in your PLC program create the logic to read those register values periodically.

Unfortunately I don't think you're not going to be able to send reals over profinet. You will have to modify the plc code for this. I just recently implemented this same solution with an S7-1500 and R30iB. I ended up creating a macro that updates the plc with the current robot position.

The trick is to separate the decimal value from the whole number. Value 1 is the left side of the decimal, value 2 is the right side of the decimal. The DO (737) is an indicator to the plc that the value is negative. The plc basically will run the math in reverse and reattach the two values. Hopefully this helps.

I should note that I have the math tools option installed.

1: !******************************** ;

2: !Position Output Macro ;

3: ;

4: !This macro separates the two ;

5: !side of the decimal point ;

6: !in to two whole numbers ;

7: !******************************** ;

8: ;

9: ;

10: PR[150:Pos Out LPOS]=LPOS ;

11: ;

12: !******************************** ;

13: !Configure X Axis Output ;

14: !******************************** ;

15: R[150:MC Pos Out Var 1]=PR[150,1:Pos Out LPOS] ;

16: ;

17: !Check If Negative ;

18: IF (R[150:MC Pos Out Var 1]<0),DO[737:OFF]=(ON) ;

19: R[150:MC Pos Out Var 1]=(ABS[R[150]]) ;

20: R[151:Pos Out X Val 1]=(TRUNC[R[150]]) ;

21: R[152:Pos Out X Val 2]=R[150:MC Pos Out Var 1]-R[151:Pos Out X Val 1] ;

22: R[152:Pos Out X Val 2]=(R[152:Pos Out X Val 2]*1000) ;

23: R[152:Pos Out X Val 2]=(TRUNC[R[152]]) ;

24: ;

25: GO[1:0:Echo Pos X Val 1]=R[151:Pos Out X Val 1] ;

26: GO[2:0:Echo Pos X Val 2]=R[152:Pos Out X Val 2] ;

Quote from rumblefish

Unfortunately I don't think you're not going to be able to send reals over profinet. You will have to modify the plc code for this. I just recently implemented this same solution with an S7-1500 and R30iB. I ended up creating a macro that updates the plc with the current robot position.

The trick is to separate the decimal value from the whole number. Value 1 is the left side of the decimal, value 2 is the right side of the decimal. The DO (737) is an indicator to the plc that the value is negative. The plc basically will run the math in reverse and reattach the two values. Hopefully this helps.

I do in same way

ss.sun

You will need to take a look how your float val realized inside of your PLC. Depends how you did set up of your group of inputs.

rumblefish if you or another person reads this comment kindly answer.

I have used the similar method of separating a float value such as 123.4567 into two parts, part "a" on the left side of the decimal point i.e., 123, and part "b" on the right side of the decimal point i.e., 4567. And, then I use reverse logic to reattach the two parts ("a" and "b"). However, I have a question,

Imagine the value is 12.00053, now, part "a" = 12, part "b" = 53 instead of 00053. When I reattach, I can only get 12.53 instead of 12.00053. Is there any easy fix for the above using TP programming options. What other suggestions that can help me to receive the correct value.

thanks for your help.

Zahid

Quote from zahid990170

rumblefish if you or another person reads this comment kindly answer.

I have used the similar method of separating a float value such as 123.4567 into two parts, part "a" on the left side of the decimal point i.e., 123, and part "b" on the right side of the decimal point i.e., 4567. And, then I use reverse logic to reattach the two parts ("a" and "b"). However, I have a question,

Imagine the value is 12.00053, now, part "a" = 12, part "b" = 53 instead of 00053. When I reattach, I can only get 12.53 instead of 12.00053. Is there any easy fix for the above using TP programming options. What other suggestions that can help me to receive the correct value.

thanks for your help.

Zahid

If you use 10-5 then just use *10 multiplier in your logic.

12.00053 - initial number.

12 -> goes into register 1

0.00053 -> goes into register 2

100000 * 0.00053 = 53. Send this data to you destination device.

Before you compile these 2 numbers together, do not forget to divide 53 / 100000 to get your real data.

A common practice is to use a multiplier. For example, multiply the number by 10000 and then send it. Once its received, divide by 10000.

You have to be careful not to exceed the max value of a 16 bit register.

thank you jmd2777 that solved the issue.

Quote from scotty

If you use 10-5 then just use *10 multiplier in your logic.

12.00053 - initial number.

12 -> goes into register 1

0.00053 -> goes into register 2

100000 * 0.00053 = 53. Send this data to you destination device.

Before you compile these 2 numbers together, do not forget to divide 53 / 100000 to get your real data.

Display More

thanks scotty

Hi all! First of all i want to thank you for your time, I use this forum almost all the time

My question is: how do you separate this two values? (Left&right side of de decimal) I think that the trunc instruction it's for this purpose but, what if you don't have the math tools option? ( I assume it becomes within it)

Thanks again!

Quote from Dgsuarez86

Hi all! First of all i want to thank you for your time, I use this forum almost all the time

My question is: how do you separate this two values? (Left&right side of de decimal) I think that the trunc instruction it's for this purpose but, what if you don't have the math tools option? ( I assume it becomes within it)

Thanks again!

You can use a logic from reply above or I do a bit different way. I use MOD/DIV as I remember. I do not have Roboguide next to me know for test, I hope it works:

!R[100] - initial num
!R[101] - integer part
!R[102] - float part

R[101] = R[100] DIV 1
R[102] = R[100] - R[101]

Thanks for your quick reply scotty ! I will try it!

Integer part:

R[101] = R[100] DIV 1

Decimal fractional part:

R[102] = R[100] MOD 1

For negative R[100], both will be negative.

Doing a bit of threadcromancy on this topic, b/c I just ran into something odd the first time I encountered a robot using these variables.

Short version: this was a brand-new R30iB+ running V9.3 with a non-synchronous 7th axis, and it was "inheriting" some BG code that copied $SCR_GRP[2].MCH_ANG[1] into a Register, and from the Register into a GO. I tested it by jogging the 7th axis, and everything worked as intended.

But I didn't do any programming -- I was only on-site to do the hardware and core software setup, the customer had their own programmer coming in a week or two later to generate and install their offline programs.

And that's where it gets weird -- when they ran a program, the R and GO did not update. But when jogging the axis, they did update.

It gets stranger: I booted up my virtual copy of that robot in RG, and tested it for myself. And in RG, the R and GO failed to update in either jog or program execution. So, it was behaving differently between the real robot, and a virtual robot built from a backup of that robot.

The core issue was that I hadn't known I needed to set $SCR_GRP[2].$M_POS_ENB to True. As soon as we did that (in both the real and virtual robots), they both worked entirely as intended.

But the discrepancies are very odd, and something to look out for if anyone encounters this in the future.