DeviceNet Intermittent Issue

[Old No. 7]

We have an application where we're communicating between a 1769-SDN a 3rd party device. For the most part things work fine. We're reading maybe 8 or so addresses and writing to another 4. The issue is that periodically the data for a couple of the tags seems to get mixed up for a split second. So the data we're reading for tag1 ends up in tag2 and we see a constant (357) end up in tag 1. It only happens long enough to just see it flash on the HMI.

I'm not that familiar with Devicenet. Is there a good method for determining if the problem is on the PLC end or the 3rd party device?

 

[Jim3846]

you could trap the diagnostic info when you see tag 1 or 2 constant?

I know there is a node table that just has a bit set if its communicating. Then you have the diagnostics display on front of SDN. I think the diag display can be moved from the diagnostic area to a buffer word when it happens.

 

[plvlce]

Make sure nothing else is putting values in the tags the HMI is directly reading from (check for destructive cross-references). Most common cause I've seen of HMIs momentarily showing the wrong value is if the tag is written multiple times within a scan and the HMI read occasionally pulls data between them.

 

[Ken Roach]

In my experience, the problem is likely in the logic that is processing the Input data from the 1769-SDN. Maybe the HMI is occasionally picking up array elements mid-COP, or tags that are the destination of more than one calculation during the program scan. The Copy Synchronous (CPS) instruction, or the use of buffer tags before the HMI-read tags, are my usual solutions.

It's possible that the problem is actually in the timing of the mapping from the 1769-SDN's scanner to the backplane image, but the only time I've found such an issue was when I was using "segmented mapping", which was uncommon even in the 1990's when I was using the 1747-SDN.

The least likely reason for this problem is in the slave device, but it's certainly possible.

There is no realistic possibility that the problem is arising from corruption of signals or data on the wire.

 

[AlfredoQuintero]

Ken, what if the payload, the IO size, is larger than 8 bytes? For many years I provided technical support for the 5136-DN and DNP cards from then SST, later Woodhead Industries and now part of Molex/Koch. The IO interlock tables is an option for these devices. In the case of the SST card the way to ensure coherency or consistency is by means of the "IO interlock tables", which allow the application to lock the access of the scanner when writing the input to the PLC or reading the output from the PLC, or let the application know if the PLC is accessing the IO so the application does not access the IO data. If the implementation does not use the "IO interlocks", then for IO data larger than 8 bytes it is possible that while the scanner is reading the input from the slave, the slave application sends new data to the scanner and because this access is done through shared RAM it is much faster than CAN so it could happen that some of the data going to the scanner is old and some new data. The only solution from the scanner point of view is to make two consecutive readings, compare them and if different discard them. The device showing the issue is third party, hence likely to be using a communication adapter from HMS, Hilscher, Softing or the SST card, or something similar. If the IO data is 8 bytes or less there is no problem because the integrity is ensured at CAN level, but larger than that it would depend on whether the application is using whatever IO data consistency mechanism is supported by the communication adapter, if the communication adapter uses ISA, or PC/104, or VME or PCI to talk to the host CPU.

 

[Ken Roach]

Thanks for that perspective, Alfredo !

I mentioned the 1747-SDN for exactly that reason; you could use "segmented mapping" to put some data (like a header) into the I/O table, then other data from the same I/O connection (like the body of a string from a barcode reader) into the M1/M0 tables. It was possible to get data from subsequent packets into the Input data table in different SLC program scans, but it didn't matter because at the application level there was often an explicit handshake (like on a barcode read) or division between objects (like discrete vs. analog data from a FLEX adapter).

And certainly there could be a similar problem on the adapter side in No.7's application.

But in general, I've seen dozens of "the HMI reads a tag in between rungs that have a duplicate destructive effect on that tag" issues, and a tiny number of "the data came across the DeviceNet out of sequence" issues. So the CompactLogix program is where I would look first.

 

[Old No. 7]

you could trap the diagnostic info when you see tag 1 or 2 constant?

I know there is a node table that just has a bit set if its communicating. Then you have the diagnostics display on front of SDN. I think the diag display can be moved from the diagnostic area to a buffer word when it happens.

Good idea, we'll try and see if the diagnostics show anything.

Make sure nothing else is putting values in the tags the HMI is directly reading from (check for destructive cross-references). Most common cause I've seen of HMIs momentarily showing the wrong value is if the tag is written multiple times within a scan and the HMI read occasionally pulls data between them.

I did verify that there are not any duplicate destructive tags.

In my experience, the problem is likely in the logic that is processing the Input data from the 1769-SDN. Maybe the HMI is occasionally picking up array elements mid-COP, or tags that are the destination of more than one calculation during the program scan. The Copy Synchronous (CPS) instruction, or the use of buffer tags before the HMI-read tags, are my usual solutions.

It's possible that the problem is actually in the timing of the mapping from the 1769-SDN's scanner to the backplane image, but the only time I've found such an issue was when I was using "segmented mapping", which was uncommon even in the 1990's when I was using the 1747-SDN.

The least likely reason for this problem is in the slave device, but it's certainly possible.

There is no realistic possibility that the problem is arising from corruption of signals or data on the wire.

The data gets written from the MSG into an array and then we are MOV'ing it to another set of tags that is used in the HMI. I'm not that familiar with the CPS instruction. Is that something we should be using here?

 

[Ken Roach]

Thanks for that context !

We're reading maybe 8 or so addresses and writing to another 4.

I assumed that "reading and writing" referred to ordinary cyclic polled data exchange using the 1769-SDN Scanlist, and data mapped into the Input and Output tags using RSNetworx for DeviceNet.

If there are MSG instructions involved (especially if there are multiple MSG instructions) then there could certainly be some data integrity issues where the MSG values get updated asynchronously to the logic that moves them (with MOV instructions, or COP instructions ?) to other tags and memory.

Let's examine the simple stuff first.

What instruction moves the data from the MSG instruction destination tag to the tags that are read by the HMI ? Is it a set of MOV instructions, or COP instruction, or some math instructions like ADD, SUB, MUL, DIV ?

Is that logic executed every scan of the routine, or is it updated only when the /DN bit of the MSG instruction goes from false to true ?

I used to illustrate asynchronous data handling in classes by dealing playing cards. I think I got the point across, but it also illustrated that I am clumsy as hell with playing cards.

 

[Old No. 7]

Ken,

We're using both I/O polling and messages. The device we're using only supports I/O polling for a handful of items and the rest require messages.

The problems we see are only on the data that comes from the messages. The messages are setup in a cascade fashion with delays in between (30ms) per the recommendation of the device vendor.

At the end of the routine we use a MOV to transfer the data to the tag for the HMI. This happens every scan. We can try adding the individual MSG .DN bits to only update the data when the message is done.

 

[Ken Roach]

Thanks for that context and detail !

The arrival of responses to MSG instructions is definitely asynchronous to the program scan.

Using the false->true transition of the .DN bit to condition any data handling logic involving the response data is the first approach I would take to this problem.