You are viewing an old version of this page. View the current version.
The Direct Mode executes at a fixed rate which is defined by the slow polling rate setting. Every Tag that uses the Direct Tag Group will poll the PLC at the Rate setting at all times (24x7x365).
To Add a Direct Tag Group
- In the Tag Browser, click on the Timer 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, and click OK.
That’s it! 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 Tag Group.
Direct Mode Properties
|Name||Unique name of the Tag Group.|
The Tag Group executes at a fixed rate, defined by the Rate setting.
Base update rate, specified in milliseconds, at which Tags will be executed.
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.
|Read After Write|
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.
Optimistic Writes are only valid on OPC Tags. Optimistic Writes set a newly written Tag value in Ignition before receiving confirmation of the write from the PLC. This helps the operators see their newly entered value right away and is useful if you have slow a Tag Group Rate. A faster Rate (1 second or quicker) will have less need to turn on Optimistic Writes.
If enabled, written values will be applied to the Tag in Ignition immediately. Normally, the system must receive confirmation that a write was successful from the device before the Tag in Ignition's value would change. The Optimistic Writes property changes the behavior by assuming the write went through until 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 Ignition Tag does not receive confirmation that the new write was successful within the timeout, the Ignition Tag will change back 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 Ignition 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 current value. Assuming an initial value of 0, if a write of 10 is applied to the Ignition 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 Ignition Tag will change to 5.
|Optimistic Write Timeout (MS)|
The timeout period for Optimistic Writes. A value of 0 effectively disables the fallback functionality: the new value is maintained on the Tag until the next read or subscription activity.
|Publishing Interval (ms)|
The rate at which data is delivered to the OPC-UA client.
A value of -1 means automatic, allowing the OPC-UA client to determine the rate.
The OPC-UA specifications states that in cases where the sampling interval (the rate as which the server checks the data source for changes) is faster than the publishing interval (rate at which the the data is delivered to the client), the samples may be queued or batched together before publishing. This setting determines the maximum size of that queue. When the maximum is reached and a publish has not yet occurred, oldest samples are dropped first.
Note that values on Ignition tags will only ever show the latest value, regardless of what this property is set to.
Currently, there are not any features in Ignition that utilizes multiple entries in the queue, but 3rd party OPC-UA clients may be able to take advantage of this setting.
|Min Time Between Samples||Minimum time between samples (integer).|
|Min Time Units||Minimum time in units is defined as: Milliseconds, Seconds, Minutes, Hours, Days, Weeks, Months, and Years.|
|Max Time Between Samples||Maximum time between samples (integer).|
|Max Time Units||Maximum time in units is defined as: Milliseconds, Seconds, Minutes, Hours, Days, Weeks, Months, and Years.|
- No labels