Troubleshooting

Tips for troubleshooting a MotoLogix system.

If your MotoLogix system is not behaving as expected you might some help in below troubleshooting tips.

MotoLogix connection

If the MotoLogix system is not working at all you should first check if the MotoLogix communication is up and running. The first step is the hardware connection (fieldbus) but then MotoLogix is also having a communication watchdog which is monitored on both Robot and PLC side.

If the connection is lost (so it was working but stopped suddenly), a robot alarm 4847 (subcode 2) occurs – but if the connection never worked since startup the robot controller does not show an alarm.

Troubleshooting tips:

1. Verify MLX.NumberOfAxis. This is the number of axes in the MotoLogix system (e.g. 6 for a single GP7 manipulator) – If it has a strange value (e.g. 256) the Endianness (byte order) is set wrong in the robot controller.
2. Make sure the FirstScan inputs on MLxCommunicationRead and MLxCommunicationWrite are triggered at startup of the plc. This initializes important data.
3. Check that the PLC IO mapping to the fieldbus slave (robot controller) is correct and has no “gaps”.

Jog motion not smooth

MotoLogix jog motion is executed by a continuous flow of jog motion commands (send by the PLC).

In most cases, this behaviour is caused by a high PLC scan time.

Now even with higher scan times (>20 ms) MotoLogix jog motion can be smooth but it requires some parameter changes on the robot side.

The jog coast time (ms) can be changed by the customer in parameter S3C 1385. Its default setting can be found in the Parameter settings of your robot setup .

Alarm codes

4847 - subcode [2]

The MotoLogix communication is monitored on both Robot and PLC side using a watchdog.

In most cases, this alarm is caused by a (sporadic) high PLC scan time. Verify this scan time in your PLC engineering tool.

Now even with higher scan times (>20 ms) MotoLogix can work fine (although the latency increases with such high scan time) but it requires some parameter changes on the robot side.

The time out setting (ms) for this watchdog can be changed by the customer in parameter S3C 1380. Its default setting can be found in the Parameter settings of your robot setup .

The time out setting on PLC side cannot be adjusted by the customer (it is set to a significantly higher value).

Rockwell safety PLC’s

In the past we have seen some issues with Rockwell safety PLC’s. Its safety logic and -communication seems to draw a heavy load on the CPU resources, resulting in unstable EtherNet/IP communication. This led to occasional alarm 4847.

Use the Rockwell Logix Task monitor tool to monitor the CPU load and make sure the report shows no communication warnings such as:

CPU Usage is very high; you may experience intermittent communication issues.

In such case you might want to increase the RPI of the MotoLogix module to free some CPU resources.

4847 - subcode [3]

The MotoLogix communication uses a checksum mechanism to detect inconsistent command data.

Possible causes for inconsistent MotoLogix data:

• FB call timing issue (see below).
• MotoLogix FB’s not all in the same task.
• MotoLogix FB’s not called between MLxCommunicationRead and MLxCommunicationWrite.
• Overwriting the address memory of the MotoLogix data packet.
• Overwriting the MLxData variable.
• Mixing MLxdata variables of multiple MotoLogix systems.

FB call timing issue

When enabling multiple MotoLogix command instances each of them will get a place allocated in the MotoLogix command buffer.

But if a user program is written in such way that the robot gets only a single move command at a time (which means that the robot motions cannot be blended), the same place in the command buffer will be reused.

In that case it is important that there is at least one plc scan between disabling the first and enabling the next. This is needed to cleanup the data and prepare the interface for the next command.

A good practice is using the CASE statement for programming your state machines and placing the FB calls below the state machine. This allows only one transition per PLC scan and prevents such timing issues.

example:

CASE state OF
...
10:
  // enabling the FB
  MLxFB1.Enable := TRUE;

  // condition to proceed after FB finished
  IF (MLxFB1.Sts_DN AND MLxFB1.Sts_EN) THEN
    state := 20;
  END_IF;

20:
  MLxFB2.Enable := TRUE;

  IF (MLxFB2.Sts_DN AND MLxFB2.Sts_EN) THEN
    state := 30;
  END_IF;
  ...
END_CASE;

// FB calls
MLxFB1(...);
MLxFB2(...);