Fanuc GESNDDAT and Arguments

    Hello,


    I have a R30iB controller running a handling application. The robot is controlled by a ControlLogix PLC, and most normal IO is exchanged between the robot and PLC (DI, DO, GI, GO). There are three programs that are running that used AR[1] through [AR]10 and these appear to be linked to programs called from the PLC via GI's and GO's. What I don't understand is how the AR's are sent and received by the robot. Within what appear to be native Karel programs (sendsysv, senddata, getdata), I keep seeing calls for a program called GESNDDAT, and the AR's are being passed in and out of that. What does GESNDDAT do? Where can I find where these AR's are modified programatically? I have done a TP ASCII dump and don't see where these Arguments are modifed or changed at all, yet when my programs are running I'm seeing them update. Thanks

  • HawkME

    Approved the thread.
    Quote from ROBOT_G

    That doesn't look like a Fanuc program at least i've never seen it before.

    I had never seen this before until now. It's on all 13 of the robots running on my line and appears to be related to whats effectively zone requests (allow some robots into an area, don't allow others until the robot clears the zone).


    This is what the ASCII dump of the "getdata" program looks like.


    /PROG GETDATA Macro

    /ATTR

    OWNER = MNEDITOR;

    COMMENT = "Get PC Data";

    PROG_SIZE = 286;

    CREATE = DATE 10-10-14 TIME 11:38:12;

    MODIFIED = DATE 99-06-01 TIME 14:21:38;

    FILE_NAME = SENDDATA;

    VERSION = 0;

    LINE_COUNT = 2;

    MEMORY_SIZE = 658;

    PROTECT = READ;

    TCD: STACK_SIZE = 0,

    TASK_PRIORITY = 50,

    TIME_SLICE = 0,

    BUSY_LAMP_OFF = 0,

    ABORT_REQUEST = 0,

    PAUSE_REQUEST = 0;

    DEFAULT_GROUP = *,*,*,*,*;

    CONTROL_CODE = 00000000 00000000;

    /APPL

    /MN

    1: !Get Data Macro ;

    2: CALL GESNDDAT(AR[1],1,AR[2],AR[3],AR[4],AR[5],AR[6],AR[7],AR[8],AR[9]) ;

    /POS

    /END


    The senddata and sendsysv look the same except AR[10] is passed on senddata and only AR1 through 6 are sent on sendsysv. The other odd thing is that on the sendsysv program, it's Calling GESNDSYS:


    /PROG SENDSYSV Macro

    /ATTR

    OWNER = MNEDITOR;

    COMMENT = "Send PC SysVar";

    PROG_SIZE = 274;

    CREATE = DATE 10-10-14 TIME 11:56:24;

    MODIFIED = DATE 99-06-01 TIME 14:23:06;

    FILE_NAME = SENDDATA;

    VERSION = 0;

    LINE_COUNT = 2;

    MEMORY_SIZE = 646;

    PROTECT = READ;

    TCD: STACK_SIZE = 0,

    TASK_PRIORITY = 50,

    TIME_SLICE = 0,

    BUSY_LAMP_OFF = 0,

    ABORT_REQUEST = 0,

    PAUSE_REQUEST = 0;

    DEFAULT_GROUP = *,*,*,*,*;

    CONTROL_CODE = 00000000 00000000;

    /APPL

    /MN

    1: !Send SysVar Macro ;

    2: CALL GESNDSYS(AR[1],AR[2],AR[3],AR[4],AR[5],AR[6]) ;

    /POS

    /END

    It's a Karel program called by a TP program. You pass the arguments into the TP then it passes them into the Karel program. You have 3 paths to figure it out.


    1. Look at the program calling the TP program and see what it's passing for arguments.


    2. Obtain the source code of the be Karel program.


    3. Obtain documentation for the karel program.


    Most likely it is a Fanuc made Karel program, they will have documentation.

    its a fanuc program


    in the handlingtool manual under advanced functions section 14.46.4


    Send SysVar( )

    The Send SysVar macro is used to send the value of a system variable (whether integer, real,

    or string) to the PC's Event Handler. The request code determines what data is being sent and

    what the PC is supposed to do with it.

    Table 14–126 lists and describes the Send Data macro. Send SysVar Sample Teach Pendant

    Program shows a sample teach pendant program that uses the Send Data macro.

    Table 14–126. Send SysVar Macro Description

    MACRO ITEM DESCRIPTION

    Syntax: Send SysVar(request_code, wait_sw, status_reg, "name1" [,"name2" [,"name3"]])

    request_code - This item determines which event is triggered on the PC. It can be a

    value between 0 and 255.

    Wait_sw - This item is a wait switch. Valid values are either 0 or 1. If 0, do not wait for

    an answer form the PC.

    If 1, wait for an answer from the PC. The default value of wait_sw is 0.

    Status_reg - This item is a register which stores the value of either the answer or the

    error status for which the teach pendant program is waiting. Valid values are either 0 or a

    register number. If 0, no register is used, and no answer from the PC is reported back to

    the teach pendant program.

    If wait_sw = 1 , then the teach pendant program waits for the PC to answer, but the

    answer value is not placed into a teach pendant register. If an error occurs in the macro,

    the teach pendant program is aborted.

    If status_reg is not 0, this is the register number used to report the PC's answer or error

    status to the calling teach pendant program.

    If wait_sw = 0, the teach pendant program will not wait for the PC to answer and the

    register will only be used to report errors. R[number] is set to 9999 if an error occurs.

    Parameters:

    Name1 through Name3 - These items are STRING values which are used to create one

    system variable name whose contents are then sent to the PC. Each string can be up

    to 16 characters long; however, since some system variable names are longer than 16

    characters, the optional parameters Name2 and Name3 can be supplied. Send SysVar

    appends them to Name1 to form a single system variable name.

    Thank you all for the responses and help so far.


    What I still don't understand is what is passing data into the AR's. The AR values themselves are written to some individual registers in some routines that are then used to jump to LBL's that control specific DO's. These DO's are sent over ethernet to a PLC which then turns on DI's that allow the robots to enter and exit cells. I have done a full ASCII dump of all TP programs and cross referenced the AR's and I only see them used to write to the above mentioned registers, and these functions. Yet I'm seeing the AR's change values dynamically based on robot movement. So it's like somehow these AR's are being updated but I can't figure out how.


    Tried to attach a screenshot of my NotePad++ cross reference of the AR's but it wouldn't let me attach photos. Pasting the text version of the cross reference below, and you can see they appear to only be used to write to registers within my TP programs, but nothing appears to write to them from the TP programs that I can see:


    Searching for all AR's using syntax "AR[" in my search:


    TP Programs ASCII\getdata.ls (9 hits)

    Line 24: 2: CALL GESNDDAT(AR[1],1,AR[2],AR[3],AR[4],AR[5],AR[6],AR[7],AR[8],AR[9]) ;


    TP Programs ASCII\reqmenu.ls (2 hits)

    Line 24: 2: CALL GESNDEVT(AR[1],1,AR[2]) ;


    TP Programs ASCII\senddata.ls (10 hits)

    Line 24: 2: CALL GESNDDAT(AR[1],AR[2],AR[3],AR[4],AR[5],AR[6],AR[7],AR[8],AR[9],AR[10]) ;


    TP Programs ASCII\sendevnt.ls (3 hits)

    Line 24: 2: CALL GESNDEVT(AR[1],AR[2],AR[3]) ;


    TP Programs ASCII\sendsysv.ls (6 hits)

    Line 24: 2: CALL GESNDSYS(AR[1],AR[2],AR[3],AR[4],AR[5],AR[6]) ;


    TP Programs ASCII\sv_adjst.ls (2 hits)

    Line 22: 1: CALL ACSET(AR[1],AR[2]) ;


    TP Programs ASCII\zone_exit.ls (8 hits)

    Line 40: 15: R[80:Zone 2 Request]=AR[1] ;

    Line 41: 16: R[81:Robot Safe Zone]=AR[2] ;

    Line 42: 17: R[82:OP45 DN Request]=AR[3] ;

    Line 43: 18: R[83:Screw Request]=AR[4] ;

    Line 44: 19: R[84:Press Request]=AR[5] ;

    Line 45: 20: R[85:Snap Request]=AR[6] ;

    Line 46: 21: R[86:OP50 Request]=AR[7] ;

    Line 47: 22: R[87:Reject Request]=AR[8] ;


    TP Programs ASCII\zone_request.ls (8 hits)

    Line 40: 15: R[80:Zone 2 Request]=AR[1] ;

    Line 41: 16: R[81:Robot Safe Zone]=AR[2] ;

    Line 42: 17: R[82:OP45 DN Request]=AR[3] ;

    Line 43: 18: R[83:Screw Request]=AR[4] ;

    Line 44: 19: R[84:Press Request]=AR[5] ;

    Line 45: 20: R[85:Snap Request]=AR[6] ;

    Line 46: 21: R[86:OP50 Request]=AR[7] ;

    Line 47: 22: R[87:Reject Request]=AR[8] ;


    TP Programs ASCII\zone_wait.ls (8 hits)

    Line 40: 15: R[80:Zone 2 Request]=AR[1] ;

    Line 41: 16: R[81:Robot Safe Zone]=AR[2] ;

    Line 42: 17: R[82:OP45 DN Request]=AR[3] ;

    Line 43: 18: R[83:Screw Request]=AR[4] ;

    Line 44: 19: R[84:Press Request]=AR[5] ;

    Line 45: 20: R[85:Snap Request]=AR[6] ;

    Line 46: 21: R[86:OP50 Request]=AR[7] ;

    Line 47: 22: R[87:Reject Request]=AR[8] ;

    Quote from HawkME

    ARs are temporary and different instances for every called program. You see what they are by looking at the program that calls the program with the ARs. You have to go up one level.

    Thanks for the tip. I did eventually find out where these AR's are being modified. I guess this was more about my ignorance of AR usage than anything else. So I'm guessing the GESNDDAT and Sendsysvr are effectively Karel programs that handle the AR mapping between TP programs?

Advertising from our partners