Unresolved alarm (SRVO-403, DCS Cart Speed Limit (No1 : G2 Limit CTRL G2)

    Hello, Everyone

    I am the end user of the fanuc automation robot (Lrmate 2000id, R30 controller). I received an alarm "SRVO-403, DCS Cart Speed limit (No 1: G2 limit CTRL G2)" two weeks ago
    The robot was installed in 2020, and there was no problem before
    So I tried very hard to solve it, but I couldn't

    The auxiliary axis speed seems to have exceeded the limit (dcs Cartesian speed limit exceeded)
    limit : 330mm/s, when exceeding : up to 2000mm/s ~

    No alarm when robot is stationary
    The manual mode (tp on, controller t1 or t2) allows me to control the robot freely
    But when i start the robot in automatic mode (tp off, controller auto)
    The robot speed immediately exceeded the dcs limit and an srvo alarm occurred.

    When the dcs speed limit is disabled, the robot moves at high speed on the rail without stopping

    All parameters have been identified with auxiliary axis such as acceleration while moving, dcs speed limit changes, mechanical parts (rail, auxiliary servo gear, energy chain, guide roller)
    and electrical components (aux servo, pulse coder)

    There are also no alarms for electrical components.

    Someone told me that it causes the servo motor to operate at high speed due to the high friction applied to the rail while moving. Is this possible?


    and also, what are the main causes of speed exceed while moving on rail? even though the speed is already defined.


    thank you so much for your helps.

  • kwakisaki

    Approved the thread.

    300 mm/sec is pretty slow. What's the speed in one such movement command where the robot generates that fault? And what's the general override while it's executed? Many robots make up to 4000mm/sec so for example if you call a movement with 10 % speed in that command and you run it with 100% override... that's still more than your DCS allows the robot to.

    Quote from OpaBroesel

    300 mm/sec is pretty slow. What's the speed in one such movement command where the robot generates that fault? And what's the general override while it's executed? Many robots make up to 4000mm/sec so for example if you call a movement with 10 % speed in that command and you run it with 100% override... that's still more than your DCS allows the robot to.

    Thank you for your answer.


    1. when the robot generates that fault, the actual speed while robot are moving is accelerated up to 4000mm/sec

    2. in fact, somtimes it was working well and robot maintains a speed up to 310mm/sec (at top of the teach pendant, called 100% speed i can saw)

    3. general override while execution is 100%

    when the robot has run before, one could assume, there has been a change to a movement command like the original command could have been something like :


    L P[1: "point-name"] 4000mm/sec FINE or CONT


    where it was


    L P[1: "point-name"] 300mm/sec FINE or CONT


    before.

    I think you need to find either the faulty command or you need one trained programmer to adjust your DCS values. There are more options to limit the speed in DCS so maybe there is just a wrong configured option

    You should never adjust safety values to circumvent errors with DCS when troubleshooting.

    DCS errors are there to protect whatever parameters have been set for the environment.

    Those errors are telling you that something is potentially not safe and therefore get triggered.

    This is only usually applicable on a mature system of course (ie a commissioned and operating cell).


    If this occurs during commissioning/setup or/and you are proficient with DCS functions, parameters and procedures to adjust them then it can greatly assist in troubleshooting of course.


    I have bear witness to a couple of instances where incorrect troubleshooting was applied by someone not proficient with DCS and was offered advice on the procedure of adjusting DCS parameters and they circumvented the error by adjusting DCS parameters to get the system operational again which resulted in a near miss towards an operator and a major collision costing £10,000 worth of damage to the EOAT.


    I am only stating the above as this is a public forum and 'we' would like to make sure safe working practices are highlighted as a priority as Safety Monitoring Systems are there to reduce/eliminate and intervene where motion segments and processing exceed the Safety System parameters.


    Quote from OpaBroesel

    L P[1: "point-name"] 4000mm/sec FINE or CONT


    where it was


    L P[1: "point-name"] 300mm/sec FINE or CONT

    Completely agree with OpaBroesel.


    Please look into your motion segments where personnel may have added or modified instructions.

    This may well be the source of the issue.

    Especially if this problem repeatedly occurs at the same point for the motion segment in the program during automatic running.


    A previous AOA and current AOA study of program data may yield these changes offline and direct you towards where the problem may have been introduced and therefore can simply be resolved.


    It could be a PLC or HMI (external value) is being used dynamically to adjust motion segment speeds by way of IO or fieldbus etc, so if this has been integrated into the cell, then an investigation of this would be required as a possible cause too.


    Of course the DCS parameters may also be an issue with an aging system (too sensitive), but from a troubleshooting perspective a first line of approach would be to look into the obvious first:

    - Existing motion segments added/modified outside of the DCS set monitoring values.

    - External influences such as PLC and HMI data changes, component failures.

    thanks for the addition kwakisaki

    in my still limited experience i forgot to mention that explicitely!


    It should be unlikely that DCS config is the reason for that issue cause it has run before.


    Get an ASCII backup from a time where program still ran, and then do a ASCII backup from now, where it causes that issue.


    Install WinMerge or a comparable program and compare both, new with old code. Could give you a hint of where to apply changes

    Quote from OpaBroesel

    Get an ASCII backup from a time where program still ran, and then do a ASCII backup from now, where it causes that issue.


    Install WinMerge or a comparable program and compare both, new with old code. Could give you a hint of where to apply changes

    Couldn't have said it better......... :top:

Advertising from our partners