I need to monitor an OPC tag in one PLC and turn on an OPC tag in another PLC. Another kicker: the source PLC tag is on for about 3 or 4 minutes but the second OPC tag can only be on for about 1 or 2 seconds.
I have never had to do something like this before. Normally it has always been PLC to DB, not PLC to PLC.
Transaction Group?
gateway script?
Any help would be appreciated.
Thanks
Well for the first part write one tag to another.
I would create a Gateway Tag Change Script.
Monitor the tag you want under Tags tab.
Script would look like:
import system
x = system.tag.read("[]PLC1_Tag")
if x.value is True:
system.tag.write("[]PLC2_Tag2",'1')Or
import system
x = system.tag.read("[]PLC1_Tag")
if x.value == 1:
system.tag.write("[]PLC2_Tag2",'1')I would reset the tag in the PLC. This would guarantee the tag gets reset within the 1 or 2 seconds.
Cheers,
Chris
[quote=“TimE”]I need to monitor an OPC tag in one PLC and turn on an OPC tag in another PLC. Another kicker: the source PLC tag is on for about 3 or 4 minutes but the second OPC tag can only be on for about 1 or 2 seconds.
I have never had to do something like this before. Normally it has always been PLC to DB, not PLC to PLC.
Transaction Group?
gateway script?
Any help would be appreciated.
Thanks[/quote]
It is never a good idea to have a less reliable device ( PC ) control a more reliable device ( PLC ). The preferred method would have the two PLCs talk direct to each other. If they are both of the same family, and on the same network then messaging should be easy.
The only time I would use a PC as a gateway between two PLCs is for status display only, never control. I’ve been in the PLC biz since the late '80s
Proof? While historically, PLCs are more stable than PCs, this isn't true/ the whole picture. I have had PLCs fail within a year, and servers that have not been rebooted in years. Redundancy at the PC level is also easier. On top of that, it is usually other issues that drop the network, ie cables, switches, workstations, etc.
We routinely move control data from external sources into PLCs. Proper precautions must be taken, such as watchdog timing, and proper control narratives, but this works, and I would not recommend anyone shy away from this.
[quote="Curlyandshemp"]The preferred method would have the two PLCs talk direct to each other. If they are both of the same family, and on the same network then messaging should be easy.
[/quote]
Agreed.
Disagree for 2 reasons. You don't know his process. This may be acceptable, depending on his process requirements. Also, see my original response. No reason to stay away from control through a gateway device, process permitting.
So? Does this mean you are better that someone who has only been in the business for 10 years. 5 years, 1 year? Does 25+ years of experience matter if it has been poor implementations, and if so, does it make you better than 10 years of proper implementations? I'm not saying anything about you personally, just wondering what you mean by this comment.
To answer the original question, we use transaction groups for this. PLC to DB, but have “target” tag as read-only. Set the destination of the source tag to be the target tag. Have it poll every second, or whatever your network can take.
A bit confrontational there Kyle. Both of you make good points. I would say that as a general rule, I would not include PCs in a control loop. However, there are exceptions to every general rule and this is no exception 
If your process can cope with the delays introduced and if you ensure data is as fresh as it needs to be (through the use of watchdogs, heartbeats etc.) then there may be a case for including a PC.
I also think practical experience is greatly undervalued. Whilst I’ve seen engineers who are stuck doing things in an old, inefficient way, I’ve also seen others without experience being too willing to throw the baby out with the bathwater and use brute force to achieve their aims. +1 for more elegance in engineering!