Currently have a project where I am reading Boolean values from a PLC to ignition and based alarms on there states.
Using ignition 8.1.1
I am trying to poll these at 200ms but have tested by pushing out to 1000ms with no improvement.
What I am seeing is that every so often (Not all tags are doing this at the same time) the Booleans that are true momentarily go low in ignition.
This is enough to trigger an alarm.
Network architecture is remote edge gateways server as opc servers to the main gateway.
I have setup 3 duplicate set of tags.
Main, Test and Test_2
Main is communicating to the PLC via remote gateway.
Test is communicating using the same remote gateway. (These are robustly seeing the same alarm)
Test_2 is talking to plc via main ignition gateway so this is removing the layer of remote gateways. (this still sees the same problem, but its dips in values do not happen in line with the dips in Main and test tags.
This is happening from 2 PLC’s. 2 different remote gateways etc.
Each plc is being requested for less than 2000 tags. LINTs and Booleans.
The trend data for the tag which is reading bool as an OPC tag is showing dips in the value to 0.
All tags are doing this and can be seen by recent updates to last change value on the tag.
Any help would be greatly appreciated.
200ms is an extremely aggressive pace for any driver based on a TCP/IP query/response protocol. A single packet drop in your network will stall for long enough to invalidate your subscribed tags. Also, you might also need to consolidate your subscribed booleans to make driver optimization possible. For one, do not use alias tags in your processor. Or at least, never access by alias externally. Next, avoid directly accessing elements of AOIs.
You might consider switching protocols, too. I’m a bit biased on this topic, but high speed monitoring like you are attempting is what spurred the creation of my Ethernet/IP module (I/O protocol). It uses UDP traffic to be relatively immune to packet drops, and can reliably run in Ignition in the 100ms range.
Thanks for the reply Phil.
Yea I agree it is aggressive, since this morning I have started to change UDT’s to request int’s instead of individual Boolean tags. Think this is a no brainer in general.
I came across your module this morning alright, did I see somewhere that this was not yet usable for redundant gateways and it is available for version 8.0?
I have read a few posts at this stage, may be confusing with another post.
Thing that is confusing me here is the quality of the tag is not changing, it is simply forcing the bit false for 1 scan cycle. If the quality was an issue, I could work around with quality checks etc. o my scripts. Although this is still not ideal.
All tags are controller based and not alias tags.
Actually, no. Booleans in UDTs are efficiently optimized. No need to change to ints and pull bits yourself. (In Logix, all booleans in UDTs are actually embedded in hidden SINT members.)