HIGH SPEED UNCOMMANDED MOVE - KAWASAKI CP180

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.......

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.

Can you attach a backup made with the /alllog option:
SAVE /ALLLOG BACKUP

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