ERROR (-1407)Servo unit error

  • Hi Team,
    I hate to ask for help but this one has had me stumped for the last week.
    It isn't urgent in any way, but I'm keen to know your thoughts.

    I'm Getting the following Error:

    • Error:
      ERROR (-1407)Servo unit error
      ERROR (-1100)CPU error(Code=00008008)

      Task(STP1)Stop SIG=00008008 [FAULT(PARALLEL )] PC=3016fdd8 ================================================================
    • I'm Getting it only on some Arc instructions, it appears only when they are used consecutively.
      The program is autogenerated from GCODE so the conversion is probably a factor.
    • If I cycle power and start cycle, the program carries on and eventually faults again on another C2Move instruction further on in the program.
    • It appears to be repeatable. The following snippet shows the culprit area.
      LMOVE TRANS(190.225,81.728,-5.500)
      C1MOVE TRANS(192.399,81.070,-5.500)
      C2MOVE TRANS(193.843,79.316,-5.500)
      C1MOVE TRANS(195.287,77.562,-5.500)
      C2MOVE TRANS(197.461,76.904,-5.500)
      LMOVE TRANS(200.771,76.904,-5.500)
      LMOVE TRANS(200.944,77.182,-5.500)
      LMOVE TRANS(192.372,94.712,-5.500)
      LMOVE TRANS(188.160,103.518,-5.500)
      LMOVE TRANS(187.815,103.574,-5.500)
      C1MOVE TRANS(184.864,100.599,-5.500)
      C2MOVE TRANS(181.831,97.707,-5.500)
      C1MOVE TRANS(178.680,94.941,-5.500)
      C2MOVE TRANS(175.384,92.351,-5.500) <-Program Stops Here
      C1MOVE TRANS(173.793,91.197,-5.500)
      C2MOVE TRANS(172.176,90.079,-5.500)
      C1MOVE TRANS(170.525,89.012,-5.500)
      C2MOVE TRANS(168.831,88.014,-5.500)
      C1MOVE TRANS(165.522,86.204,-5.500)
      C2MOVE TRANS(162.171,84.475,-5.500) <- If started again, program Stops Here
      C1MOVE TRANS(158.745,82.895,-5.500)
      C2MOVE TRANS(155.225,81.538,-5.500)
      C1MOVE TRANS(152.546,80.622,-5.500)
      C2MOVE TRANS(149.854,79.742,-5.500)
      C1MOVE TRANS(147.134,78.953,-5.500)
      C2MOVE TRANS(144.375,78.309,-5.500)
      LMOVE TRANS(142.523,77.911,-5.500)
      LMOVE TRANS(140.662,77.555,-5.500)
      LMOVE TRANS(139.078,77.325,-5.500)
      LMOVE TRANS(137.494,77.095,-5.500)

    What I've Tried:

    • Swapped robot over to a completely different Controller Unit. (Same Data file) Same Fault.
    • Simulated program in PC-AS. No issues.
    • Changing CAM settings to produce less unnecessary ARC movements.(work in progress)

    What I've Read (my understanding):

    • The servo error results from the 1GB Board telling the 1HA board that a servo error signal has occurred. The following is listed as the main cause:
      · The servo system error has occurred. (I believe this is the case.)
      · Disconnection or connect defect of the harness between the power sequence board (This is internal to the controller I believe, so I have eliminated by changing controller)
    • The 1GB board 'Detects encoder hardware and communication errors,
      outputs a servo unit error signal (SVER) via the RS-485 interface to the 1HP board. The 1HP board then
      controls powering down the controller.'

    My Thoughts:
    The issue seems software related, It doesn't like something about these consecutive commands.
    When I got the machine, the circular option wasn't on it and had to be enabled.
    It is possible that the auto generated program is creating Arcs that can't be processed/executed properly.

    Do the boards have firmware that can be flashed to the latest versions?

    Its not the end of the world, but I'm curious why it's happening.
    I'm interested if anyone has any insights on what could be going on?

  • Place your Ad here!
  • Well I think you may struggle with resolving this for the following reasons:

    1. Controller was originally specified for automotive production for handling or probably spot welding.

    2. You are using technology (>20 years) which was designed for handling and spot welding applications.

    3. You are using a robot system which is no longer supported by the OEM.

    4. The robot is designed for a substantial payload attached.

    5. Your circular moves my not be achievable using the accuracies/distances between points involved .

    6. These maybe saturating the motion planner (ie distances between points).

    7. Error Code 1100 is always very specific to area of processing problem which Kawasaki can only reference too - as this product is no longer supported, then support from Kawasaki may not even be available.

    8. I very much doubt CAM processes are based on a 20 year old Controller.

    9. From my list, the SV software is at the latest version.

    10. I cannot cross reference AS software as it is North American Spec.

    I would be tempted to:

    - Convert some of your locations to joint angles and see if the same error exists.

    - If so, then I would suspect points 5 and 6 are more than likely the route cause.

    You could adjust the limit of coincidence by current position and see if this helps.

    - On C Controller this is default at 3mm, reducing this value may help.

    - This is held in Maintenance Aux 920 spec 1.

    There is no Joint Angle Posture references either ( I hate CAM processes for this), everything is mapped around the Tool Coordinate, so the starting postures are not necessarily correct.

  • Looking a little further into this, the results I get in PCROSET is a failed to create arc on step 528.

    The other thing I have noticed, is your tcp is pointing upwards (ie machining from underneath).

    Is this correct?

    My test with your current result in the following profile with an error generated at step 528 for cannot create circle.

  • Yes, when running another simulation I also got that error at the same point.

    However the major error occurs on line 130. (only on the Real Robot)
    If I create a new program with just the snippet of instructions listed in the first post, it still stops on that C2 Move instruction I've marked in Red. (which is the left triangle like shape on the path in your screenshot)

    Sorry, I Think I've lost track on what has changed with my program, I know it completed a successful simulation once but I may have altered some Cam parameters and regenerated it since.

    PC-Roset is the best for C-series simulation?
    The Scene viewer on my one looks primitive in comparison.

    Today I'll offset the base coordinates and rerun the snippet to ensure its not a cable fault at a certain arm position.

  • PC-Roset is the only OLP that supports the C Controller....but also no longer supported.

    KROSET has the paint version available.

    It is still a strange setup you have with your TCP vectors as surely the physical tool volume would be colliding with the workpiece............???

    Personally running C1 and C2 concurrent moves - arc to arc is not a method I would adopt.

    C1 to C1 to C1 are perfectly acceptable and this maybe could attribute to the issue as a C1/C2 Move is a circular calculation.

    Personally I think your CAM processes is struggling when it comes to ARC creation.

    I can see in some areas various LMOVES are being used to create an ARC and then in other areas C1/C2 MOVES are being used.

  • I'll admit that my TCP isn't quite setup correctly, I think I've compensated with my base coordinate.

    I'll attempt to recreate the program manually by simplifying it.
    Once I know what works I'll attempt to write a program/script/fusion360 post processor to covert GCODE to AS logic.

    As Always, Thanks for your help

  • I'll admit that my TCP isn't quite setup correctly, I think I've compensated with my base coordinate.

    Accurate and incorrect tcp values will have an impact when it comes to motion planning and is a fundamental element required prior to programming and path generation and I would recommend this is carried out.

  • Error Still Occurred with correct TCP setup, however I've had luck with using the ABB robot post processor in Fusion360, then converting it to AS language. It seems to output only linear moves which gets around my problem.

    Proof of concept pictured. Will put more effort into the setup now I know it works.


  • I wouldn't have expected correcting the TCP would solve the problem, just when it comes to motion planning as the Z vector was 180 degree's out, you could experience future motion limit errors or possible collisions as Z values when using TRANS is relative to Z direction which is normally Z+ for TCP's on Kawasaki.

    However, I think what you've done has highlighted the C1/C2 move elements with question marks.

    This could be reported back to your CAM process supplier and see if this is a potential issue within their processing.

    Good to know though, thanks for sharing............:top:

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

Advertising from our partners