Posts by 95devils

    What are you wanting to use the scanner for? Path correction?


    If I remember correctly, there was a special software version, a -27 version. Additional boards had to be added like the NCP-02. Parameters had to be turned on. It was expansive to accomplish.

    After you delete the CAPTURE tag on line 22, add another instruction right below line 22. In the INFORM LIST under ARITH is the GETS. You want to write the instruction as GETS Px010 $Px001. This should then work the same as the job with the CAPTURE tag.

    Most likely cause of this is, the controller you are trying to load the job into doesn't have new enough software. The CAPTURE tag came out approximately software YAS4.40.


    If that is the case, you are going to have to kick it old school with the GETS.

    On the Rm2-750 maximum payload is over 1600 lbs. The maximum unbalanced load is over 500 lbs.


    How much do the fixtures weight?

    Is the 200 lbs the weight of the fixture and the parts loaded?

    If underweight the servos should be able to hold it, especially how new to system is.


    Less than a year old should still be under warranty. I'd have Yaskawa out to look at it as long as it is not overweighted.

    I see the NPOS don't match the number in the job.


    The job is referencing P010, P030, P035, and P036. Only P010 is in the header.


    The header is referencing P001, P021, P022, P026, P027, P028, and P029.

    You only need 3 positions but 4 MOVC instructions. This is provided you want the start and end positions to be the same. Additional positions can be used due to something not being perfectly round.


    MOVC start position

    MOVC somewhere on the arc

    MOVC somewhere on the arc

    MOVC end position same as start position


    Yaskawa requires a minimum of three MOVC instructions to do an arc. Other manufacturers do it with a minimum of 2 circular move instructions. The only difference here between Yaskawa and other brands is getting to the first position. Yaskawa records it as a MOVC but is treated as a MOVL.

    I imagine you are using this for a restarting condition for safety. What I have done in the past is write this in the ladder.


    STR #50076 Jog Operation Inform

    OR #01220 Universal/General Purpose Input #969

    AND-NOT #11220 Universal/General Purpose Input #969

    AND-NOT #50117 Cube #32

    OUT #01220 Universal/General Purpose Input #969


    If someone has jogged the robot and it is not in a safe cube (32), I seal up Input 969. The macro jog can't have an IF condition so I will use JUMP and *LABEL to skip around it. JUMP *LABEL IF IN#(969)=OFF. You don't specify controller generation so there may be other ways such as an IFTHEN, etc.


    I quite often also use #50075 in series with #50076. This signal indicates that the job to be executed has just been edited, searched, or manipulated with the cursor ON. This can be used for determining starting conditions after editing.


    The job will pulse Output #(969) to break the seal.

    If you disconnect the encoders, yes, you will have to recalibrate.


    To make calibration easier you could take the three axes to 0 first with no fixtures installed. You could lose a couple of pulse counts at best if the brakes a good.


    You could plug batteries into the encoder before you disconnect the cables and not have to recalibrate.

    In the original post you said "positional values associated with the weld lines only become affected" - are these positional values defined by position variables?

    Position variable values that are used in a JOB are stored in the jbi file when jbi file is being saved. The value of each position variable that gets stored in the jbi file while saving will be the value it is at the time of saving and not what it was the last time you ran that job. So for example if you run JOB1 and it uses P001 variable with whatever values and after that you run JOB2 that also uses P001 but with some other values and you then save JOB1 then the saved JOB1.jbi file will have the P001 values from the JOB2 because these were the values in P001 at the time of saving.

    Now when you load a job into the controller and the jbi file has position variable values stored in it, they will be overwritten in the controller! What's why I never upload a job file into the controller while the robot is operating because I use a lot of touch sensing, the values are stored in position variables and uploading a job will overwrite these position variable values. I learnt that the hard way - years ago I uploaded a job into a controller that was operating. The job I uploaded was not the one that was running at the time but the robot collided with the workpiece because a position variable got overwritten.


    There is a way to avoid this - when you use a position variable in a job with indirect addressing. So instead of writing SFTON P001 you write SFTON [P1]. That way the position variable values will not be stored in the jbi file and thus they will not be overwritten in the controller when loading that job from external memory.

    Spot on, probably the case, or accidentally loaded the VAR.DAT file. Glad you took the time to explain this.

    If you open the CIOPRG.LST, on line 2 and line 5 there will be information about the application the controller is set up for. Examples: ARC, MATERIAL HANDLING, SPOT, ARC+ARC, etc.


    The ladder you are trying to load in has to have the exact application as the controller is set up for.