Robot BX100 with E controller on its own jumps between program steps

Quote from siwy61

During work, robot sometimes jumps between steps in program or even between programs.

This is such a random statement to make, just what context are you referring to:
- During normal running.
- When the process is interrupted by an external influence.

What you are describing above is a process interruption and the result (error) from not using a proper restart from interruption procedure.

I suggest you contact the supplier of the system as they will be best served to assist you as they have programmed and integrated it and explain how to recover/restart when an external influence such as safety device has interrupted the process.

The only thing I can recommend is to go to aux function 0502 (System Switch) and enable the DISP.EXE function as below.
This will indicate current step and reduce the 'jumping steps' you are referring to initially as there is no evidence of step jumping in your provided log.

Well, I don't know what else to suggest.

If they stop and restart the process in a manner outlined by whomever has integrated it, then there is no problem as that is how they have integrated it.

If they interrupt the process at random points, or outside of the procedure outlined by whomever has integrated it and errors are produced then they are introducing these errors by externally influencing the application in areas which it hasn't been programmed or integrated to handle/monitor for.

Unfortunately the forum will not be able to answer that without application and integration knowledge of your current application and equipment and from the sounds of it, program and possible application modifications would need to be applied in order for the system to handle these 'random external influences'.

So only speculations can be made.

The deviation JT4 error suggests it could be attributed to:
- Brake of JT4 has failed.
- Operator may have manually moved the robot to a different location before restarting.
- Operator may have jumped steps before restarting.

If the above is indeed the case and it is not JT brake failure, then the answer is simply to follow whomever has integrated it restart procedures based on the cell loading procedure (complete restart).

Just by your initial post, it suggests the client is reporting something to you as 'they see it' or you are reporting something as 'you see it'.

That system switch should assist the client/you further in the future to assist with future interruption issues.

Further investigation about the circumstances in which these 'issues' are occurring outside of the normal operation procedures would be required and decision on whether this is equipment failure, or external factors and decide on a plan of action going forward and that is what I get from your posts.

That's the best advice I can provide at this point...........

So with the limited information I can suggest is the following:

Take a save/full and look at the program execution log as it will tell you exactly what line of code the robot is executing and why it might be jumping to another line/program.

From my experience things that make the robot code jump steps are:

Goto commands

Program calls

Interrupts to a label or program ( remember interrupts stay active unless Ignore is used)

Programs hitting a Return statement

external reset from dedicated input like priming PG0 on step 1

Operators changing step number or manually priming a program from the teach pendant. ( This can easily be checked by looking at the operator log to see if they are doing this)

ShAdOwDrAgOnS has highlighted additional specifics which influence a jumping perspective and what is mentioned in this thread are 3 specific different variants that influence this:
1. External signal influence (like external program reset)
2. Programmed influence (like interrupts, subroutine calls and returns, PC Task functionality).
3. External operator influences (Move the robot from current position, selecting different steps).

I don't know quite what else to suggest here as this issue appears to be externally influenced.
It suggests to me you may be getting misdirected due to the 'jumping' you are seeing and may be assuming this 'jumping' is the problem where in fact this 'jumping' is normal due to Kawasaki and how it has been programmed and integrated.

You also have the instance to consider that upon safety device activations and without any safety PLC like a Cubic S unit or alternative, then a category stop (usually 0) should be applied, causing engagement of brakes and removal of motor power which will stop the controller executing any further commands specifically motion segments.

Are we looking at:
1. A problem that has suddenly appeared on a mature system that didn't exist before.
2. A problem that is occurring during commissioning.
3. A problem that is occurring because operators are not following implemented procedures.

It really only comes down to 4 things really:
- Obtain specific Kawasaki knowledge through training and specifically target your application.
- Understanding your system integration for continuance after safety device activation.
- Following the correct procedures implemented.
- If the procedures are incorrect, review what can be done to improve them.