Kepware is acting as opc-ua client connected to Ignition opc-ua server.
I configured ignition boolean tag, to use fast tag group 100ms.
I then write True to this tag, sleep(0.5), then set to False.
Seems like kepware does not notice the trigger.
Is there other OPC-UA server settings to allow this?
Any such timing is going to be limited by the actual communications performance to the target device. For typical request-response protocols, 100ms is difficult to achieve with any significant number of data points on scan. Kepware might also be throttling the writes. You may have to study the Kepware documentation.
In general, the first write needs to be verified to have succeeded (by seeing "true" read back) before attempting to write the false. A write-sleep-write pattern is unlikely to ever be reliable when the writes are through request-response messaging. Use a state machine running from a timer event.
TL/DR: It depends on the hardware, the OPC Server, and the rest of the comms load.
Edit: I missed the Kepware as client bit in the OP.
Is the Boolean tag an OPC tag? Memory tag?
The Boolean tag, is created on Ignition.. And exposed via OPC-UA Server of Ignition.
Ignition and kepware are on the same machine.
You need to change settings of the Kepware client driver.
Increase Sampling Interval to maybe 250ms, increase Queue Size to 2 or more, and if you actually want to "see" the value change and not just receive it along with the next value change that reverts it, increase the Publishing Interval to 250ms as well.
The settings of the Tag Group in Ignition are not relevant, except when it's an OPC tag from one of Ignition's drivers, where it influences how fast the driver attempts to poll the underlying value.
The reason sampling interval and queue size doesn't actually matter in this case is a quirk of how the Exposed Tags address space is implemented. It basically ignores sampling interval because it doesn't sample - it subscribes to Ignition tags instead of doing an internal polling cycle on them. Technically not an OPC UA compliant implementation as it is, but better performance / less overhead.
Since you are stuck with a queue size of 1, the only way to see quick successive value changes is to ensure they are published to the client quick enough.
