Add a Direct Tag Group
- In the Tag Browser, click on the
- Tag Groups icon to open the Tag Group Editor.
- On the bottom left side, click the
- Add icon to create a new Tag Group, and enter the values for the following properties:
- Name -
- Enter a unique name for the Tag Group: Direct 5 Seconds
- Select the Mode: Direct
- Enter Rate: 5,000
- Click OK to save.
- Now that you have your Tag Group created, let's add multiple Tags to the Tag Group. Go to your Tag Browser, find some Tags you want to add to the Tag Group. This example uses several Ramp Tags. Right click on the selected Tags, and click on Edit
- Tag icon.
This opens the Tag Editor window. It also shows you that you have multiple Tags selected. Select the Direct 5 Seconds Tag
Group from the dropdown
You created a new Direct 5 Second Tag Group and added your Tags. Just make sure you want to poll the 5 second values all the time (24/7) when you use the Direct 5 Seconds
Direct Mode Properties
Note: If the rate is set to 0, the Tag group will not be executed.
This mode dictates how OPC values are obtained. The default mode, Subscribed, is preferred because it is much more efficient than a read.
All OPC Tags in the Tag group will be subscribed according to the Tag group rate. Values will come in asynchronously as they change.
Tags will not be subscribed, but will instead be synchronously read each time the Tag group executes. This operation is less efficient, but allows more precise control over when values are obtained. This mode is particularly useful when collecting data over a slow or expensive connection for display. When combined with the one-shot execution mode above, and a static Tag tied to a momentary button, it's easy to create a manual refresh button on a screen that pulls data on-demand.
When enabled, a read request will be sent immediately after a write request. This means that the value on the Tag will be updated much quicker to reflect the latest written value.
Enabling this property is less efficient as a single write to a Tag becomes two separate requests. This is especially helpful with slower Tag groups as the Tags will show the latest value quicker than the normal execution would allow.
If enabled, written values will be applied to the OPC Tag immediately. Normally, the system must receive confirmation that a write was successful from the device before the OPC Tag's value would change. This property changes the behavior by assuming the write went through unless the next read value or subscription update proves otherwise. Enabling this will make writes appear to execute much quicker.
Works in conjunction with the OPC Optimistic Write Timeout property below. If the OPC Tag does not receive confirmation that the new write was successful within the timeout, the Tag will fallback to the last known value. While in an ambiguous state, the Tag with have a quality of "Good (Provisional)".
This setting can be paired with the OPC Read After Write: the Tag will assume the newly written value, while an asynchronous read request is quickly sent out to confirm the write went through.
While the write is pending, values received from subscription activities will override the fallback value. Assuming an initial value of 0, if a write of 10 is applied to the OPC Tag, then the Tag will show a value of 10 until the system can confirm the new value. If a subscription update then returns a value of 5, the OPC Tag will fallback to 5.