Posts by Nation

    Hmm. Maybe chips from the cutting process are causing interment trips. You may be able to download the scanner software and modify the false detect rate. Some model can be setup to trip after a certain amount of time.


    Of course this will increase the response time of the system safety wise, so you may have to expand your zones.


    Would you be able to take a picture of the board with the orange connectors on the door? That will confirm is you have a CRM8A harness wired in.

    You will likely need the safe/IO and DCS position check options to do what you want. Take a picture of your DCS screen and post it so I can confirm. Or even better, DM me a backup.


    Once you have have those options, you can wire up a couple of safety inputs on that era of controller. Literally just two, but that should be enough for your application. You would then wire these as a pair into each of your light screen safety relay dry contacts.



    Once wired, you can use those to mute "Stay out" zones in front of each light screen. If the light screen is violated, and the robot is in the "stay out" zone, it will e-stop. If it is servicing the other side of the cell, it will continue on.


    I would highly recommend additional internal cell safety features though, as nothing is preventing someone from just walking or climbing through the light screen and entering the cell while the robot is operating. Something like a safety mat, or a light scanner at floor level.

    I've had erroneous fence open alarms happen when the electricians ran the light curtain cables next to the robot's servo amp cables. I put a scope on the cables, and there was all sorts of noise inducted into the light screen cables.


    Make sure your light screen cables are far away from anything high current, voltage, or both.


    Also, it sounds like your light screens are backwards, or both of them are wired up to the fence circuit. Given that you don't have DCS safe IO, I'm assuming they are wired up to the fence circuit. Does the light curtain on the A side stop the robot when it is on the A side? If so, then the fence circuit is correct. If not, you have a major safety issue.

    I personally have not done image backups over FTP. Reading the manual, it looks like the robot will connect to a FTP server, and place the image files in the root directory.


    Here is a post regarding Filezilla settings for connecting to the robot the other way, where the robot is the server, and you are the client.

    I ran a test on that robot is roboguide, and I was getting the same "overspec" alarm as you are.


    I then discovered that Fanuc sets the J3 armload as 12kg by default. That value directly subtracts from the allowed payload on J6. Set that to 0, and it will work.

    The application process on your called program must match the application process in the program doing the calling.


    Go through the details page on each program and make sure they match.

    Is this for a 3D offset?


    Either way, I think you are over complicating it. If you are shifting in a frame that is already defined, just take the offset from the camera, subtract it from your reference position, and run with that.

    I've implemented the Karel programs MATRIX and INVERSE in TP. Downside is you have to sacrifice a user frame for it to work. I picked 9.


    In the karel programs you would call it like so:

    Code
    : CALL MATRIX(89,90,91) ;

    Where PR[91]=PR[89]*PR[90].


    The TP Program functions the same way, except for the name.

    Code
    : CALL MMULT(89,90,91) ;


    Same deal for inverse. Karel version is called like this:

    Code
    : CALL INVERSE(89,90) ;

    Where PR[90]=PR[89]'.


    The TP Program functions the same way, except for the name.

    Code
    : CALL MINV(89,90) ;


    Here is the TP matrix multiply program:


    And here is the TP inverse program:


    Also attached is a .zip file of the .TP and .LS files. TP is compiled on V9.30 HandlingTool.


    Limitations/Caveats:

    • Frame 9 is used to do conversions. If you are using frame 9, modify the top and bottom of each program to use a frame that is free on your system. Also, label it as "RESERVED" or something like that.
    • Not sure if it works on JPOS rep points.
    • All index arguments must be unique. The programs use the result as a working area for calculations, and would screw up the math.
      • Don't do something like this: CALL MINV(90,90)

    Can't have matrix multiplication without inverse. I created the inverse TP program as well. Same deal as MULTIPLY. You have to sacrifice a frame. 9 again in this case.


    Same deal as the multiply. Karel version is called like this:

    Code
    : CALL INVERSE(89,90) ;

    Where PR[90]=PR[89]'.


    The TP Program functions the same way, except for the name.

    Code
    : CALL MINV(89,90) ;


    Here is the program:

    I implemented the Karel program MATRIX in TP. Downside is you have to sacrifice a user frame for it to work. I picked 9.


    In the karel program you would call it like so:

    Code
    :  CALL MATRIX(89,90,91) ;

    Where PR[91]=PR[89]*PR[90].


    The TP Program functions the same way, except for the name.

    Code
    :  CALL MMULT(89,90,91) ;


    Here is the program: