P/C Tags - are they synchronous?

TheWaterboy

Lifetime Supporting Member + Moderator
Join Date
May 2006
Location
-27.9679796,153.419016
Posts
1,906
Using L61 and 10 L32's

I am pulling (pushing?) 10 DataValues and 10 IDvalues to 10 different PLC's using a Produced/Consumed tag. I'm doing this using only 2 Tags so the data is sent sequentially, i.e. ID1,50...ID2,75...ID3,100 etc.

In each L32 machine, in ladder I use an EQU and when the IDValue matches the PLC number, I MOV the DataValue to the PLC's register that needs it.
So like Token Ring, every PLC sees every value and ID but only copies the value when the ID matches.

When I graph the data stream from the L32 I see random drops to zero and I'm looking for a reason. I was sequencing the values at a 100 ms rate and I just changed that to a 500 ms rate to see if that is part of the issue.

My question is: Are the tags sent by a P/C connection sent (well, received and presented to logic) at the same instant, or is it possible I am getting the previous PLC's data for a split second as the ID changes first and the value has not yet updated?
I can put a delay in the proper place if I need to, but is it really that tight?

Now this doesn't explain a zero value, but its my best guess at the moment.
 
Produced/Consumed Tags are asynchronous, similar to I/O. They're handled independently and there's no guarantee that a given controller will Produce two different tags immediately after one another.

There is very little additional overhead involved in Producing 10 integers versus producing one. I strongly recommend that you put all the data into sets and add one additional tag to serve as a watchdog.
 
I am looking very closely at the graphs of data and I am now convinced that there are occasional instances where, for example, the ID of 4 is presented but the data is from ID 3. I can see it easily now that I know what I'm looking for.

The values are floats but these PLC's are nowhere near being constrained by overhead, I will consider your solution. Its a big job to change this.

How do you envision a watchdog tag? Other than the first 2 bytes of the PC set?
 
The simplest way of implementing a watchdog using P/C is just to have the P/C tag be a UDT where the first element is of type CONNECTION_STATUS. This creates two BOOL tags: ConnectionFaulted and RunMode. They're fairly self-explanatory - if the consumer can connect to the producer, the ConnectionFaulted element of the consumed tag will be 0, if not it will be 1. If the producer is in Run Mode, the RunMode element of the consumed tag will be 1, otherwise it will be 0. These two elements are continuously updated, even if both the producer and consumer are not in run mode.
Using that, you can do a simple "if RunMode and not ConnectionFaulted then producer = online" style validity check.


The other option is to include a "heartbeat" as part of the transmitted data. This can be a bit that toggles on/off, and if it stops toggling, you know you've lost the connection. The trick with this one is to remember that when it stops, it might stop in the on state OR the off state. So you have to watch not just for it being on or off, but that it continuously changes state. Alternatively you can use an integer that counts from 0 to [any valid number]. At the consuming end, you just have to make sure the value keeps changing.


Back to the issue at hand - one possibility that might at least solve your immediate issue without too much re-work of existing code is to look into CPS (Copy Synchronous).


A regular COP instruction just copies bytes of data from source to destination, without a care for what the data is or means or what's happening around it. Asynchronous tasks can happen during the execution of the COP. If your COP has a length of 2, an I/O or P/C data update might happen after the first element is copied, but before the second element is copied. This could have similar results to what you're seeing: ID is copied to the produced tag, consumed tag is read by the other PLC with new ID but old DATA, then new DATA is copied to the produced tag.



CPS, on the other hand, is designed to overcome exactly this issue. When a CPS executes, it locks down all the data until it's finished doing what it's doing. No P/C or I/O updates will happen until it's copied all data elements. It carries a much higher processor overhead as a result, but it's the recommended way of copying I/O data (be that physical I/O or comms-based I/O) to avoid exactly the issue you're having.


I'm imagining that in the producing PLC, you have two MOV instructions: one to MOV the ID into your produced tag, and one to MOV the DATA into the produced tag. Sometimes, the P/C tag updates in between those two MOV instructions, and that's when you have your issue.


Instead, you could MOV both values into an intermediate tag, and then once both values are correctly loaded in, CPS them into the produced tag. That will ensure that the P/C tag cannot update until both the ID and the DATA have been loaded correctly.
 
The Connection Status and the heartbeat are both part of this UDT and are monitored. CPS however is not used. I will dig into that now. Sounds just like you describe
 
A related example: I have an HMI that writes to an array of data. I made the array one element longer than it needs to be and that last element is always a value of 999.

To determine if the whole array of data has arrived in my PLC, I write a zero into the last element of the array when I initialize my program or the HMI connects to the PLC (a separate watchdog feature).

When that last element becomes = 999, I know that the whole array of data has arrived intact, because I know that tag writes put data into REAL or DINT arrays in ascending order. I've even tested this with a CRC routine and it works 100% of the time.

I concur with the recommendation of the CPS instruction that our colleague ASF described; that's the simplest way of dealing with data consistency within a single array or UDT.
 
Ahh, I get that. I like it.
Working on it now... on the initiating side I have several MOVs populating the P/C tag array plus the incrementing pair has its own thing. Gotta work that out.
 
Sounds like you found the problem. But I have to ask, why all the multiplexing of the produced/consume data? Why not just have each consumer get its own dedicated tag? That too would eliminate the issue and get you way faster response times, regardless of if you need them.
 
Since the topic of the Produced/Consumed Status tag came up, I wanted to mention that it doesn't always time out in a prompt manner.

Have a look at RA Knowledgebase 1043606: Produced/Consumed Connection status bit take time to update on connection loss

This might not affect TheWaterboy's system, and is not the source of his data integrity issues, but it's worth mentioning.
 
Sounds like you found the problem. But I have to ask, why all the multiplexing of the produced/consume data?

From a data comm perspective this is shaped like a "C". I don't like it (now) but it was the most effective way to proceed.

We replaced 10 discrete instruments instruments connected to each individual end PLC (as 4-20mA) with a single instrument connected to a central aggregating display that uses Modbus TCP as its comm. A Prosoft MNETC module gathers this data from the aggregator into PLC1. The challenge is that from a control and SCADA perspective these collected values need to be within the end PLC's since each end PLC is responsible for tuning to that value.

Once collected from the aggregator, PLC1 sends this package of 10 data values in an array (using CPS now) to PLC2.

PLC2 holds the P/C UDT tags connected to the 10 end PLC's and has been in used for years sending data from devices in the feed stream that would be common to ALL end PLC's. As happens so often there were only 4 unused tags in the preexisting array (knowing for certain I would NEVER need more than 4 spares... :( ) so multiplexing this 10 element array for the 10 end user PLC's was the only option I saw short of a rewrite.

Also the end PLC's are written such a way that they are configured automatically using thier static IP and so are interchangeable. The ID created from the IP address becomes an important part of the communication. Seemed reasonable to rely on it here too.

So, as you say, I may have found the problem, but getting it stopped is proving tougher than I thought. I might not have a choice but to make a big change but I haven't given up yet.

The indexing I am using in the multiplexing PLC seems to be the source of all my issues. I have synced everything else upstream using CPS instead of MOV or COP everywhere the data is relocated but I still see this intermittent wrong indexing occur. It must be in how I am doing that. Looking at that today. Man I wish there was a step-through mode on these.
 

Similar Topics

Hi All, we've recently upgraded from FTView SE v10 to v12. Since the upgrade we've been having a problem where the HMI is slow to update tags in...
Replies
0
Views
38
Hello, I have a pair of redundant 1756-L71 controllers rev 24. These controllers currently have produced and consumed tag interfaces to 3 other...
Replies
2
Views
93
Hi everyone. Quick questions. On UnityPro, I want to open and quickly read tags from a .STA files witouth opening the program. I have 30 plc...
Replies
2
Views
103
Hello everyone, I am currently working on a project that uses a Rockwell L33ER controller and the FTV Studio V13 as Supervisory computer...
Replies
0
Views
84
Hi I have been knocking my head against the wall trying to figure out why these two plcs won't talk with Produced and Consumed Tags data. The...
Replies
14
Views
417
Back
Top Bottom