Anybus Communicator - Consume Message Timeout

Anybus Support
#1

Hello,

I have an Anybus Communicator setup to translate RS-422 serial communication from a Sick LMS500 LiDAR laser scanner to a profibus PLC network. There are 2 pairs of produce/consume messages on the device. One gets measurement data on a 50ms period, the other asks for the laser device status on a 1 second interval. Both commands were tested, and the data expected is being sent and received.

The measurement data appears to be consistent and does not time out. The laser device status has a timestamp that we are using as a watchdog for the system. It appears to be very inconsistent. Below is a trend from our signal database.

Coil%20Car%20Laser

For some reason, the status command is either not being sent consistently, or not being received consistently. Is there any recommendation for what to look for to resolve this issue?

ECCS - Generic Data Mode - Binary (CoLa B).cfg (16.0 KB)

I have also attached the config file that is currently deployed.

If anyone has any suggestions they would be of great help.

Thanks.

#2

Hello @TButchart_AMDofasco,

My first though is you will want to track down where the info is getting lost.

Where is this trend from? Is this showing data that the PLC is reading off of the device? Where are the times being generated? Have you used the logging feature in the Configuration Manager to see if it shows similar inconsistencies or missing transactions?

Deryck

#4

Hi Deryck,

This trend is showing the data as seen by our PLC. The time stamp is generated by the laser scanner and we are just using the update of the “seconds” component to view a constantly updating data field.

The other command sends and receives without issue, so from a connection stand point I believe we are good. The only thing that could be off is the second command, but as far as I am aware if it answers/responds even once it would be in the correct format.

I have connected to the communicator with ACM. Using the node monitor I was able see the fields updating and then lining up with our PLC trend, it stops, and again will randomly pick back up.

I am going to try the data logger on the laser and see what exactly is being seen at the device end.

Regards,

Travis

#5

I think taking a log would be the next step here. you should be able to see the serial data stream in as the communicator sees it. This should point to what side of the device the issue is on.

Deryck

#6

Was able to capture logs.

First log captured both commands and were both sending and receiving.

Log - Both Commands Working.txt (28.0 KB)

Second log was captured during a message timeout.

Log - Device Status Failure.txt (28.1 KB)

For the second log, I set both cycle rates to 1 second to see if there was a collision issue or if the high rate of the measurement setting was causing an issue. It still did not work as intended. It will not allow both of these commands to run concurrently. I have tried both commands separately and played with various rates and individually, they are rock solid. The laser’s log confirms both the request and responses are accurate, but the status command is still timing out and then restarting at completely random intervals (can’t detect any pattern of timeouts)

I was under the impression the device was capable of handling concurrent serial commands. Am I simply not able to run these two commands in unison?

#7

@TButchart_AMDofasco,

Is this a query response system? On a second look at the configuration i noticed you are using generic data mode. If produce 1 is always expecting Consume 1 message and produce 2 is expecting consume 2 each respectively right after the produce messages I think you might want to switch to Master mode for the device. This might give you more consistent results. Master mode is setup for query response where it sends one message and waits for the corresponding response back. Where generic data modes does not expect a specific response. Try switching modes and see if this clears up the time out issues.

Deryck