Programs becoming corrupted after transferring from USB

    We have a large library of weld programs for large programs that have 2-3 hour run times.

    Since we are a high mix low volume facility, we have more programs than the teach pendant can retain. To work around this we move programs onto USBs back and forth from the pendant whenever required.

    Sometimes when we transfer the program back into the pendant from the USB, the positioner/skyhook positional values associated with the weld lines only become affected. For example the original set point may be -41.55. After transferring to and from the USB, this value is now 41.55 +/-.

    This has happened a few times now over a year.

    Any suggestions on how to counter measure or any idea why this may be happening?

  • Go to Best Answer
    Quote from quarz

    Hi. What controller do you use? It looks like a bug in robot firmware.

    Anyway you can download JOB back from robot to USB and check that the original JOB and downloaded are the same.

    Also you can try to upload JOBs by FTP

    Hello,

    YRC 1000 controller.

    I usually upload jobs both ways via FTP ethernet from my desk and USB if transfer is failing but the operators on the shop floor parallel shift many of my offline programmed jobs to create programs for an identical product but with a different width.

    • Best Answer

    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.

    Quote from Reintz

    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.

    I know a thing or two, because I’ve seen a thing or two. Don't even ask about a third thing. I won't know it.

    Quote from Reintz

    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.

    I appreciate the detailed comment!

    My programs are loaded with touch senses, I usually end up with around 60-100 SFTONs for a full program and they are set up as P001 and so on.

    The touches are performed again for each program, overwriting any previous data that may be saved from an earlier SFTON with the same label. This would eliminate the issue you mentioned from occurring, correct?

    What you are saying does make some sense. But with the amount of program transfers we do, it is hard to say if this is the root cause, because we should be having this issue much more often if it was the cause. Rather than a few times a year.


    In comment #2 on this post I mentioned we had a second program also become corrupt. With this program, every type of move point was affected and not just the weld lines. Air moves, via and departures were affected in the same way whether they are for a weld line or for a search task. My apologies, I forgot to mention this.

    Skyhook arm position set to +180 degrees is now all of a sudden -180 degrees etc. Skyhook arm position set to -67 degrees is now +67 degrees.

    Just want to update this thread in case it helps anyone else.

    Here is what I have found so far after investigating the issue further.

    The issue with S1 axis points being flipped is happening when a point gets modified. I’ve verified this while modifying points with the correct tool selected and the incorrect tool selected during step modification and the result is the same; the S1 value gets flipped from Positive value to a negative value or vice versa. I did this to confirm if this only happens with the wrong tool selected or not.

    Once I modified several points and confirmed that they all flipped from +45° to -45°. I ran through these points again, but the positioner did not rotate to the programmed -45° position, instead it remained at +45°. I cycled power and retested this an found the results to be the same. Values stayed mixed with +45 and -45 but the positioner remained at +45°.

    However, after moving the program into a USB and transferring it back into the pendant, the positioner now tries to rotate to the -45° positions.

    This is why I say I have found only part of the issue so far. My next troubleshooting step is to determine why S1 points are being modified incorrectly. When I rotate the positioner manually, the positional values are correct when moving in the Positive/negative directions.

    I've confirmed this happens to all programs whether they have been parallel shifted or not.

    This issue has been forwarded to Yaskawa Japan as no one is familiar with this.

    After contacting Yaskawa Mississauga, they were able to confirm that this issue is also present on their new lines that are currently being set up for customers. No counter measure has been found, so they have reached out to Japan for assistance.

    Thanks

Advertising from our partners