I’ve noticed something from time to time that I can’t fully explain: I have a transaction group with one boolean value (read only) used as a flag and a second item (a string). The string is a date-time which is written to a db table. Occasionally, when the trigger activates an old value is written. I’m certain that the PLC value is correct before the flag is set. Is it possible that the values weren’t read by the OPC at the same time? Is there a way to be sure these values are synched?
Kurt
[quote=“kjwilde”] Is it possible that the values weren’t read by the OPC at the same time?[/quote]Yes. Especially if they are in separate scan classes. Not saying that’s what you have, but the possibility exists.
[quote=“kjwilde”]Is there a way to be sure these values are synched?[/quote]Yes.
There! Now that I’ve whetted your appetite, I use another PLC register to reflect the value back from Ignition. When they are equal, then I know I can set the trigger bit.
Alternatively you can increase the time between setting the value and setting the flag. setting the time to say 1.5-2 times the scan rate of the value generally ensures that the value is there before the trigger. But then you’re at the mercy of OPC timing again. It’s why I’ve been using the feedback method.
Hope this helps!
I was kind of hoping avoiding adding another item (what you call feedback). That would mean two items just to transfer 1. That’s a lot of additional traffic. I’d also thought of adding a delay before setting the trigger flag but would also like to avoid that.
[quote=“kjwilde”]I’ve noticed something from time to time that I can’t fully explain: I have a transaction group with one boolean value (read only) used as a flag and a second item (a string). The string is a date-time which is written to a db table. Occasionally, when the trigger activates an old value is written. I’m certain that the PLC value is correct before the flag is set. Is it possible that the values weren’t read by the OPC at the same time? Is there a way to be sure these values are synched?
Kurt[/quote]
I have noticed the same thing and this has caused us issues on jobsites until I realized what was going on.
Typically at an end of batch in the PLC code, data is moved to an output window and a BOOL bit is set to indicate to Ignition new data is ready for reporting.
We noticed, that eventhough the BOOL and the analog data were in the same scan class, the BOOL would trigger FALSE to TRUE before the analog values arrived.
What I ended up doing was putting a 2-3 second delay on the BOOL trigger in PLC code to ensure the data values are at the correct values before Ignition would record the data.
Yes, unfortunately, this type of stuff comes up from time to time. With the subscription based system, it’s very possible for one of the values (the boolean) to arrive before the other.
In addition to the options already mentioned (of which I would say the timer approach is most common), the other option is to change the Data Mode of the Group from “Subscribed” to “Read”. In “read” mode, the trigger will be subscribed, but when it is active, the other items will be manually read from the PLC. This is less efficient than subscribing, but effectively eliminates this issue by ensuring that you get the current value, after the boolean has been seen.
Regards,
Colby,
Thanks for the reply. In terms of efficiency (between subscribed vs read): Say with each group there’s one trigger item (which would be subscribed) and one ‘read’ item. Now lets say there are 300 of these groups total. The frequency of trigger events is very low; say once per day. Given this I leaning toward using the read vs subscribe method vs the timers. What do you think? Is the ‘lack of efficiency’ really a factor in a case like this?
Hi,
No, I think that’s totally fine. The difference in efficiency comes into play with many tags and rapid updates: with read mode, the drivers don’t know in advance what they’ll be reading, so they can’t optimize much.
In your case, I think it’s perfectly appropriate to use Read mode.
Regards,