Send the current position of the robot through profinet

    I have a fanuc robotics, the control cabinet is R30IB mate plus, has complete profinet communication with PLC, the next need robot sent via profinet robot the current position, how to implement?
    Send the real type (32 bits), does anyone know how to implement it, thanks.

    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.

    You need to do next:

    $SCR_GRP[1].$M_POS_ENB set to TRUE

    then you can get data from:

    $SCR_GRP[1].$MCH_POS_X/Y/Z/W/P/R

    or you can take angle positions:

    $SCR_GRP[1].$MCH_ANG[1-9]

    current speed

    $SCP_GRP[1].$MCH_SPD


    if you want to transfer through Profinet, then just take data convert to integers values and send via GO. on PLC side just collect the data and represent in a way you want.

    Thank you very much, have according to you said method through GO successfully sent the current position.
    But, PLC program has been completed and cannot be changed, PLC side receive 32 for floating point number.Excuse me what method can be implemented by PROFINET directly to 32-bit floating point Numbers?

    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 :smiling_face:


    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

    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.

    thanks scotty

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


    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 :smiling_face:


    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:

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

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

    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.

Advertising from our partners