Advertising

HIGH SPEED UNCOMMANDED MOVE - KAWASAKI CP180

  • Hey everybody,


    We came across a very interesting scenario and I'm wondering if anybody has had any experience with this.


    I was working on some code for a Kawasaki CP180L 4-axis robot. First run, so initially, I wanted to step through the code to ensure the movements did not collide with anything and there were no errors. The teach pendant was in repeat mode, movement speed 20% and STEP ONCE was ON.


    On one particular move, the robot accelerated at a huge speed, to a random location and halted sudenly once it exceeeded its set working zone. The interia was enough to move the entire steel pillars beneath it by about 500mm. I'm sure if the pillars weren't there it would've tipped the entire robot over.


    The log spat out the following:
    "(E1339)[MC1]P-N high voltage.(Servo board1)"
    "(E1124)Deviation error of Jt 1."


    After the adrenaline subsided, we continued the code to determine what had happened and the robot moved to its intended position.


    I am not sure why this occured, how it occured and we weren't able to repeat it.


    Has anybody experienced any high speed, sudden movements and can give some insight as to why this occured?


    Below is a screenshot of the errorlog file in which the move occured.


    .ERRLOG
    1 - [17/07/03 11:23:53 SIGNAL:00 MON.SPEED : 20 REPEAT mode]
    (E1339)[MC1]P-N high voltage.(Servo board1)
    OPERATION1:[17/07/03 11:23:52] ( STPNEXT 1: )
    OPERATION2:[17/07/03 11:23:45] ( STPNEXT 1: )
    OPERATION3:[17/07/03 11:23:23] ( HOLD->RUN )
    OPERATION4:[17/07/03 11:23:21] ( STP_ONCE ON )
    OPERATION5:[17/07/03 11:23:19] ( RUN->HOLD )
    OPERATION6:[17/07/03 11:23:08] ( HOLD->RUN )
    OPERATION7:[17/07/03 11:23:04] ( SIGNAL 7 )
    OPERATION8:[17/07/03 11:22:55] ( RUN->HOLD )
    OPERATION9:[17/07/03 11:22:42] ( STP_ONCE OFF )
    ROBOT1:
    PROGRAM:pick Step:51 Cur_Step:52 STATUS:RUN
    Interpolation Type:LINEAR S_parameter:0.987163
    Current Pose
    JT1 JT2 JT3 JT4 JT5 JT6


    -23.515 -2.787 -2.635 19.609 0.000 0.000


    Command Pose
    JT1 JT2 JT3 JT4 JT5 JT6


    -0.213 -0.630 -0.291 0.742 0.000 0.000


    End Pose
    JT1 JT2 JT3 JT4 JT5 JT6


    -98.873 2.732 -61.232 188.892 0.000 0.000


    ------------------------------------------------------------------------------
    2 - [17/07/03 11:23:53 SIGNAL:00 MON.SPEED : 20 REPEAT mode]
    (E1124)Deviation error of Jt 1.
    OPERATION1:[17/07/03 11:23:52] ( STPNEXT 1: )
    OPERATION2:[17/07/03 11:23:45] ( STPNEXT 1: )
    OPERATION3:[17/07/03 11:23:23] ( HOLD->RUN )
    OPERATION4:[17/07/03 11:23:21] ( STP_ONCE ON )
    OPERATION5:[17/07/03 11:23:19] ( RUN->HOLD )
    OPERATION6:[17/07/03 11:23:08] ( HOLD->RUN )
    OPERATION7:[17/07/03 11:23:04] ( SIGNAL 7 )
    OPERATION8:[17/07/03 11:22:55] ( RUN->HOLD )
    OPERATION9:[17/07/03 11:22:42] ( STP_ONCE OFF )
    ROBOT1:
    PROGRAM:pick Step:51 Cur_Step:52 STATUS:RUN
    Interpolation Type:LINEAR S_parameter:0.987163
    Current Pose
    JT1 JT2 JT3 JT4 JT5 JT6


    -23.589 -2.815 -2.682 19.595 0.000 0.000


    Command Pose
    JT1 JT2 JT3 JT4 JT5 JT6


    -0.212 -0.627 -0.290 0.737 0.000 0.000


    End Pose
    JT1 JT2 JT3 JT4 JT5 JT6


    -98.873 2.732 -61.232 188.892 0.000 0.000

  • AD
  • Hello,


    After you wrote the code, you can test the program în teach mode. Please press the deadman switch + A + Go. The robot will move untill you have presșed this combination.


    Please use the k-roset simulator în order to test the program. Please check the as version and the servo version, you should have the lastest, but is not mandatory.


    Thank you,
    Alex!

  • Quote

    On one particular move, the robot accelerated at a huge speed, to a random location


    That should never happen and sounds like it was a 'making buttons' moment for sure....... :icon_eek:


    BOTH errors have been time stamped at the same time, but the deviation error of jt1 was registered first.
    - You can also see this with the location data difference between the 2 errors for the current pose.


    So, I would assume, the P-N Voltage too high is the result of the problem and not part of the problem.


    The initial error of deviation is consistent with positioning feedback (ie the robot has discovered it is NOT where it is supposed to be) - Why?
    - Could be mechanical, gearbox, sticking/dragging brakes etc - usually related to external forces pushing against the robot.
    - Causing a difference between the commanded position and actual position (fed back from the encoders).
    - Saying that, could be the encoders themselves, but any encoder related error usually results in immediate stoppage.
    - I would check out JT1 integrity (2 motors drive JT1) regarding the encoders - cables, shielding, proximity to power cables (any possibility of interference/noise), earthing of the robot, encoder connections to the 1TB board (board that sits on top of the main power block), just eliminate those.


    The other area I would consider (and this where the problem could well be) is where you started in relation to where you were going, what was the commanded instruction and were you possibly close/moving close/through a singularity - specifically JT4 start angle and target angle.
    - I know with 4 axis robots, singularities can result in some unexpected motion especially when using LMOVES to a joint angle between Northern/Southern Hemispheres, so I would certainly check your locations, type of local precision point/transformation value and whether its a J or L move.

  • Which software version is installed in the robot? You can find the version in the first part of a backup, or with the ID command.

  • Interesting problem. No solutions from me, only insights from many years working with various brands of bots.


      • Your description sounds like servo boards received erroneous signals from encoders. I have had bots wear out their wiring harnesses over time. It was determined that the servo boards received erroneous transient signals which caused erratic unpredictable movements. You don't mention the vintage of your arm, but if old and used a lot, this is a possibility.

      • This is less of a problem nowadays than it was years ago, but I always considered pulling all cards, wiping, cleaning, de-static-izing, and re-seating. This has helped me in the past eliminate false transients.

      • If you are physically within the robot's working volume while it is in REPEAT mode, then...well, let's just say that is a really, really bad idea.

  • Kawaguy backup is attached


    TygerDawg band spanking new CP180 with probably less than 10 hours of use


    kwakisaki the movements involved the robot working very close to its minimum joint limits - an approach which would transition to a pick location. That's where is behaved erratically. If it was a north/south issue or a close moving JMOVE it should have done the same thing when we ran it again but it worked perfectly the 2nd time around. We tried multiple times, doing exactly the same thing, to replicate and record the erratic movement (to avoid doing it again) but we could repeat the behavior - it worked as it should hence the confusion.


    Another programmer has had a similar experience with the CP180 by stepping through the program with step once ON and in repeat mode but as with us, it was only once off.

    Files

    • errlog.txt

      (1.91 MB, downloaded 8 times, last: )
  • Interesting, so to clarify:
    - This only occurred when using STEP ONCE
    - Another programmer has experienced exactly the same thing with STEP ONCE
    - Attempts to replicate the problem have failed.
    - Appears when in STEP CONT no problem - Is this an assumption as you cannot replicate it in STEP ONCE?


    Nothing really jumps off the page regarding the programmed/locations prior to Step 51 of the pick program (according to the error log).
    - But the issue you mentioned appeared between approach and target locations.


    So, what comes to my mind is this:
    1. Did the robot attempt to move to a calculated position - which was incorrectly calculated.
    2. Did the robot attempt to move to a location that it was not told to goto - This I find hard to believe.
    3. Did the robot attempt to move to a calculated position, which was correct, but the before posture of the robot (angles) resulted in a transform via an alternative route.


    No. 1 and No. 3 is where I would be looking: (assuming there is no software related bug).


    In your pick program you have an overall accuracy of 200.
    - So I can see how this would influence STEP ONCE and STEP CONT as STEP ONCE moves to the actual location, STEP CONT invokes the accuracy for continuous path - therefore you will receive a trajectory difference.


    - If your calculated locations (transformation) is based on a joint angle (if you have software limitations imposed on a specific joint angle), the planner will take this into account when it comes to calculating not only the XYZ but the orientation values in order to get there, I noticed JT4 has been restricted to +270 and -90.


    - So it is possible that the 'actual target' lies on a boundary which enables the planner to create a trajectory with completely differing O and T results, but when in STEP CONT, the accuracy value is applied so that this O and T value results in only 1 trajectory.


    So in all, the only suggestions I could offer if this problem is related to the above:
    - Consider adjusting JT4 software limitations (if your external harness/environment/EOAT will allow).
    - Consider the accuracy values used.
    - Consider using different approach variables instead of constantly overwriting the approach between JMOVE and LMOVE to it.
    - Use the DEST/#DEST command around your targets to 'grab' the calculated values before and after, then maybe you could individually test these locations outside of the main routine to see if you can replicate it and be able to analyse the transform data.

  • @Kadburysaki


    For me it looks like a software issue, which is solved in newer versions. I had a similar issue, when I used CHECK-GO in CHECK ONCE and without release CHECK GO switch to CHECK CONT, the robot moved to the first point, and from there it moved in exact opposite direction to the end of its motion range. Please ask your distributor for the latest software and update instructions.

  • Hi Guys, i am having a very similar issue, although i can repeat it every time. the joint spins around at such high speed.

    while holding in the dead man if i push Deadman + Go/ Deadman + back /Deadman + rec/ Deadman + a + write

    in the teach mode.


    when operating any program it does not have an issue.


    i have in inherited these robots from a previous project and i am self teaching my self how to use them.




    44 - [20/03/17 06:55:20 SIGNAL:00 MON.SPEED : 18 TEACH mode]

    (E1124)Deviation error of Jt 6.

    OPERATION1:[20/03/17 06:55:18] ( Motor power ON )

    OPERATION2:[20/03/17 06:55:17] ( ALLERESET )

    OPERATION3:[20/03/17 06:55:09] ( STEP CHANGE )

    OPERATION4:[20/03/17 06:55:09] ( ZRECO 1:pg991,63," )

    OPERATION5:[20/03/17 06:54:54] ( STEP CHANGE )

    OPERATION6:[20/03/17 06:54:54] ( ZRECO 1:pg991,62," )

    OPERATION7:[20/03/17 06:54:14] ( STEP CHANGE )

    OPERATION8:[20/03/17 06:54:14] ( ZRECO 1:pg991,61," )

    OPERATION9:[20/03/17 06:53:34] ( ZRECD pg991,61 )

    ROBOT1:

    PROGRAM:pg991 Step:63 Cur_Step:63 STATUS:RUN

    Interpolation Type:JOINT S_parameter:0.999825

    PC1 PROGRAM: z.arc Step No: 3 STATUS: RUN

    PC2 PROGRAM: z.cell Step No: 83 STATUS: RUN

    PC3 PROGRAM: pc1 Step No: 7 STATUS: STOP

    Current Pose

    JT1 JT2 JT3 JT4 JT5 JT6 JT7

    -108.813 49.396 -82.134 -54.089 -3.249 -60.089 -2000.000

    JT8

    -2000.000

    Command Pose

    JT1 JT2 JT3 JT4 JT5 JT6 JT7

    -108.813 49.397 -82.139 -54.089 -4.821 -359.885 -2000.000

    JT8

    -2000.000

    End Pose

    JT1 JT2 JT3 JT4 JT5 JT6 JT7

    -108.810 49.399 -82.158 -54.089 -5.786 59.731 -2000.000

    JT8

    -2000.000



    .***************************************************************************

    .*=== AS GROUP === : ASE_030300X2B 2015/07/12 12:45

    .*USER IF AS : UASE030300X2B 2015/07/12 12:45

    .*USER IF TP : UTPE030300X2B 2015/07/12 12:43

    .*ARM CONTROL AS : AASE030300X2B 2015/07/12 12:44

    .*USER IF AS MESSAGE FILE : MASE0300X2BEN 2015/07/12 12:45

    .*USER IF TP MESSAGE FILE : MTPE0300X2BEN 2015/07/12 01:36

    .*ARM DATA FILE : ARME030300X2B 2015/07/12 12:43

    .*KERNEL : _KNL102500000 2015/02/23

    .*DRIVER : _DRV104200000 2015/01/30

    .*RFS : _RFS100800100 2012/07/27

    .*=== SERVO GROUP === : SVE_080000045 2015/07/14 11:54

    .*ARM CONTROL SERVO : ASVE080000045 2015/07/14 11:47

    .*SRV DATA FILE : ASPE080000045 2015/07/14 11:48

    .*ARM CONTROL SERVO FPGA : ASFE08000000A 2015/04/01 09:29

    .*

    .*Cpu board type : 1VA

    .* [Shipment setting data]

    .*There is no Shipment setting data.

    .***************************************************************************

  • i believe i fixed the issue.

    i turned off this pc program * PC3 PROGRAM: pc1 Step No: 7 STATUS: STOP*


    since its been turned off i have not been able to replicate the issue



    .PROGRAM pc1() #0

    ; pc program check

    ;-------------------------

    loop2:

    WAIT TIMER(1)==10

    index = index+1

    HERE pose[index]

    WAIT TIMER(1)==0

    GOTO loop2

    .END

    .PROGRAM pg0() #65

    ;main routine

    ;PC Program control

    ;------------------

    ; waiting for pc program to start

    SWAIT 2001,2002; pc programs are running

    ;

    ;

    WHILE SIG(-2107) DO ;while robot not home

    ;Go home(Z axis moves first)

    GROUP 0

    POINT homepose = #HOME(1)

    IF DZ(homepose)>DZ(HERE) THEN

    HERE tmp

    POINT/Z tmp = homepose

    TDRAW ,,-200

    LMOVE tmp

    END ; if

    SPINAXIS 7

    RTSET 0

    SPINAXIS 8

    RTSET 0

    HOME

    BREAK

    END ;while

    ;

    ;

    PAUSE

    WAIT SIG(2200) AND SIG(1010) ; ready for program selection

    .exist = EXISTPGM($pg_selected)

    IF .exist THEN

    SCALL $pg_selected,.error

    ELSE

    PRINT 2: /C11

    PRINT 2: " Program: ",$pg_selected+" does not exist!"

    PRINT 2: "Check PG thumbwheel setting before restarting"

    PAUSE

    END ; if

    .END

  • This thread relates to CP180 Palletiser and software version issue.

    Your issue is not related to this thread, you are not using a 4 axis robot, but 6 axis with at least one external axis.


    Your issue is completely different and may require further analysis, if you keep experiencing it, please create a new thread stating:

    - Controller Type

    - Robot Type

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account
Sign up for a new account in our community. It's easy!
Register a new account
Sign in
Already have an account? Sign in here.
Sign in Now