You are not registered yet. Please click here to register!


 
 
plc storereviewsdownloads
This board is for PLC Related Q&A ONLY. Please DON'T use it for advertising, etc.
 
Try our online PLC Simulator- FREE.  Click here now to try it.

---------->>>>>Get FREE PLC Programming Tips

New Here? Please read this important info!!!


Go Back   PLCS.net - Interactive Q & A > PLCS.net - Interactive Q & A > LIVE PLC Questions And Answers

PLC training tools sale

Reply
 
Thread Tools Display Modes
Old July 18th, 2018, 03:46 PM   #1
TheWaterboy
Lifetime Supporting Member + Moderator
United States

TheWaterboy is offline
 
TheWaterboy's Avatar
 
Join Date: May 2006
Location: State of Denial
Posts: 804
P/C Tags - are they synchronous?

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.
  Reply With Quote
Old July 18th, 2018, 04:39 PM   #2
Ken Roach
Lifetime Supporting Member + Moderator
United States

Ken Roach is online now
 
Ken Roach's Avatar
 
Join Date: Apr 2002
Location: Seattle, WA
Posts: 14,174
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.
  Reply With Quote
Old July 18th, 2018, 04:49 PM   #3
TheWaterboy
Lifetime Supporting Member + Moderator
United States

TheWaterboy is offline
 
TheWaterboy's Avatar
 
Join Date: May 2006
Location: State of Denial
Posts: 804
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?
  Reply With Quote
Old July 18th, 2018, 05:18 PM   #4
Phrog30
Member
United States

Phrog30 is offline
 
Join Date: Dec 2006
Location: Montgomery, Alabama
Posts: 419
Why create a watchdog, just use the connection status.
  Reply With Quote
Old July 18th, 2018, 05:27 PM   #5
ASF
Lifetime Supporting Member
Australia

ASF is offline
 
Join Date: Jun 2012
Location: Australia
Posts: 2,647
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.
  Reply With Quote
Old July 18th, 2018, 05:46 PM   #6
TheWaterboy
Lifetime Supporting Member + Moderator
United States

TheWaterboy is offline
 
TheWaterboy's Avatar
 
Join Date: May 2006
Location: State of Denial
Posts: 804
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
  Reply With Quote
Old July 18th, 2018, 05:49 PM   #7
Ken Roach
Lifetime Supporting Member + Moderator
United States

Ken Roach is online now
 
Ken Roach's Avatar
 
Join Date: Apr 2002
Location: Seattle, WA
Posts: 14,174
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.
  Reply With Quote
Old July 18th, 2018, 06:11 PM   #8
TheWaterboy
Lifetime Supporting Member + Moderator
United States

TheWaterboy is offline
 
TheWaterboy's Avatar
 
Join Date: May 2006
Location: State of Denial
Posts: 804
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.
  Reply With Quote
Old July 18th, 2018, 07:54 PM   #9
rupej
Member
United States

rupej is offline
 
Join Date: Sep 2014
Location: NC
Posts: 411
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.
  Reply With Quote
Old July 18th, 2018, 10:19 PM   #10
Ken Roach
Lifetime Supporting Member + Moderator
United States

Ken Roach is online now
 
Ken Roach's Avatar
 
Join Date: Apr 2002
Location: Seattle, WA
Posts: 14,174
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.
  Reply With Quote
Old July 19th, 2018, 09:46 AM   #11
TheWaterboy
Lifetime Supporting Member + Moderator
United States

TheWaterboy is offline
 
TheWaterboy's Avatar
 
Join Date: May 2006
Location: State of Denial
Posts: 804
Quote:
Originally Posted by rupej View Post
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.
  Reply With Quote
Reply
Jump to Live PLC Question and Answer Forum

Bookmarks


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump

Similar Topics
Thread Thread Starter Forum Replies Last Post
Error message IdealDan LIVE PLC Questions And Answers 7 December 11th, 2017 07:40 AM
Can't delete RSLOGIX and FACTORYTALK tags AFPC LIVE PLC Questions And Answers 6 September 27th, 2017 01:24 AM
WinCC 6.2: Tags not found in WinCC Explorer Jeebs LIVE PLC Questions And Answers 0 December 11th, 2014 01:31 AM
Citect Vs WinCC - Long Doug_Adam LIVE PLC Questions And Answers 22 October 3rd, 2014 12:56 PM
RSLogix 5000 moving program tags to control tags NetNathan LIVE PLC Questions And Answers 5 February 15th, 2014 05:36 AM


All times are GMT -5. The time now is 02:08 PM.


.