Errors 4316,4317 and 4318 [PickMaster 3]

PickMaster
1

Causes for Errors 4316,4317 and 4318.

There are several causes for the errors 4316, 4317 and 4318. To check all the possible causes the following steps need to be reviewed:

  • Check all the trig/strobe wiring and see that it is connected in the right way. And that all the cables are shielded.
  • Check the computer settings
    • Check that there are no firewalls active that are affecting the time sync services (only on the IRC5 controller)
    • Check all the LAN cables. Make sure that you are using shielded cables and that all the cables are properly attached
    • Some switches are buffering data that needs to be resent. This buffering time might be to long. Try to switch to a simple hub or to set this buffer time to some shorter values. Make sure that you have the newest software running on the hub/switch
    • Check that you have the right IP address, default gateway and subnet mask (on both PC and robot controller). Note that you need to set all three values even if you are only using one computer and one robot controller on the network.
  • Triggering frequently. Sometimes the trigger distance is very short causing the system to trigger much more often than it can handle. How often a trigger can be handled depends on how complicated the models are that are used on the system. Sometimes the frequent triggering can be caused by faulty trig/strobe wiring.
  • S4C+ only: The “DSQC 540 SM-Bus lock-up and 100 Mb Ethenet problem” may cause these errors. If your controller is affected by this problem (contact your local ABB support to check this) it can be resolved by forcing the network connection to use only 10Mbit. Set either the computer network card to l0Mbit (if you are using a cross-over cable directly between PC and controller) or use a hub/switch that only supports/configure it to 10Mbit.
2

Hello,

In addition to the above, “crazy loops” in RAPID has proven to cause these kind of warnings. A PickPlaceSeq() like the one below would cause this warning (in addition to the fact that it would never perform a single pick).

PROC PickPlaceSeq()

WHILE FALSE DO

Pick PickIndex{1};

Place PlaceIndex{1};

ENDWHILE

ENDPROC

In this case would the WHILE-loop go on for ever and never stop. It will starve the main computer to perform other tasks that has lower priority than the RAPID-interpretation. A quick verification to see if this the problem in a larger and more complex RAPID program is to insert a “WaitTime 0.5” somewhere in the loop. If it solves the problem it should only be considered a workaround. Like the example above, it is usually caused by poor programming. Please consider changing the overall logic to remove unnecessary loop and instead use WaitDI or other RAPID-instructions that waits for a certain state to be present.

Best Regards, Erik