Currently, i am using ignition client event tag change script to do some processing when a particular tag called status is changed from value -1 to 1 then to 0.
However, when the tag value toggle between -1 to 1 then to 0 too fast, i notice the client event tag change script will not be triggered for this value change from -1 to 1 (dependent on tag scan rate?). Is there a way to trigger the event based on event driven instead of dependent on scan rate to scan for any value change which could be missed out potentially?
Thanks in advance for the help.
Yes and no. Ignition’s OPC drivers have a poll rate (tag group pace). If something changes in the PLC and back inside that poll window, Ignition itself will not see that change. PLC code is needed to trap and hold such events for external consumers. That is a fundamental attribute of all PLC comms.
Ignition’s Vision client has a separate poll rate it uses to get tag changes and push notifications (in project properties) from the gateway. Tag changes that change back within this additional window will also be missed at the Vision client. Consider running the appropriate processing in a gateway tag change event instead of a client tag change event.
1 Like
Can i check by running the appropriate processing in a gateway tag change event, does it guarantee that there would not be any missed events?
Gateway tag change events (the ones in the project, not part of the tag) do not drop events, short of the whole server crashing for lack of memory. So if the change is picked up in the PLC comms, it won’t be lost after that.
The key is the PLC comms. If the PLC value changes and then changes back entirely between consecutive polls, it will be missed. That is why you need PLC code to trap and hold events long enough for the OPC driver to “see” them. In critical cases, you need a handshake, not a simple timer. (Restarting the OPC driver or restarting the project right when the tag changes could exceed such a timer.)