Using #TSEventItemsReady and #TSEventSynchro OPC UA Dataitems

You can use the OPC UA-specific data items #TSEventItemsReady and #TSEventSynchro to browse and set, respectively, the state of at source timestamped variables.

NOTE: Both data items are meaningful only when time-stamping is enabled in Control Expert and activated for the specific BMENUA0100 module.

The BMENUA0100 treats the #TSEventSynchro dataitem as a Boolean OPC UA node.

Setting the #TSEventSynchro item sends a synchronize command to all at source time stamped devices of the M580 ePAC. The values returned to the OPC UA client by the devices initialize the at source timestamped variables to their current values.

The BMENUA0100 responds to the client setting the #TSEventSynchro item with one of the following messages:

  • UA_EGOOD: The synchro request was correctly sent to all timestamping devices.

  • UA_EBAD: The synchro request did not succeed because timestamping is disabled in the Control Expert project.

  • UA_EBADINVALIDSTATE: The synchro request did not succeed because timestamping was turned OFF for the BMENUA0100 module by the %MW400 feature.

  • UA_EBADINUSE: The synchro request did not succeed because the BMENUA0100 module could not reserve timestamping buffer.

  • UA_EBADDISCONNECT: The synchro request timed out and did not succeed writing values in the specified time frame.

To perform this initialization, use an OPC UA client - for example UaExpert - to perform the following sequence of tasks:

  1. Monitor the #TSEventItemsReady item which indicates the BMENUA0100 module is ready to manage timestamped variables of the ePAC buffers (including the M580 CPU, BMECRA, BMEERT), and then wait for its value to change to 1 (true).

  2. Add monitored data items configured as at source timestamped variables to one or more subscriptions.

  3. Set the #TSEventSynchro write command to update the value and at source time stamp of each item.

NOTE:

  • The BMENUA0100 reads all configured timestamped variables in the ePAC. If an event (item state change) occurs on a timestamped monitored item, that item is updated. If an item is not monitored, it is discarded.

  • It is recommended that you set the data change filter to Status/Value/Timestamp. Otherwise, it is possible that different OPC UA clients - for example clients that update values only on Status/Value changes - will display a different status and value for the same variable.

  • Because the BMENUA0100 updates values periodically, it is possible that multiple events could occur since the previous update. In that case, the BMENUA0100 displays only the most recent value.

  • Because #TSEventSynchro is sent to multiple timestamping devices, if any single device does not respond within the expected time frame, the #TSEventSynchro setting returns the response UA_EBADDISCONNECT indicating the command timed out and did not succeed. This is true even if many devices successfully respond.

  • If the subscription is edited to contain, for example, only one variable for one device, executing #TSEventSynchro causes the loss of previously returned values for previously subscribed devices and variables.

Determining the M580 CPU Channels Dedicated to Timestamping

For communication between the BMENUA0100 and an M580 CPU, where timestamping is enabled in Control Expert, 25% of the CPU channels are dedicated to support the timestamp feature. A maximum of 75% of the CPU channels remain available to carry other communication requests.

For example, for the BMEP584040 CPU:

  • Maximum number of channels: 13

  • Channels used for timestamping: 3

  • Channels used for non-timestamping: 10

Determining the Capacity of the BMENUA0100 to Read Timestamped Variables

The number of timestamped variables the BMENUA0100 can read per cycle depends on:

  • The Polling of buffer setting in the IP Config tab of the module, and

  • The capacity of the at source device, including:

    • The maximum number of TCP connections, and

    • The maximum number of supported at source timestamped variables.

The formula for determining the maximum number of at source time stamped variables for a device is:

((Max number of TCP connections) / (Number of channels)) x (Max number of timestamped variables per cycle)

For example:

  • BMEP586040: 16 max connections, 4 channels, 82 max variables:

    ((16 / 4) x 82 = 328 total variables

    If Polling of buffer = 500 ms: 656 variables per second.

  • BMECRA: 1 connection, 1 channel, 82 max variables:

    1 x 82 = 82 total variables

    If Polling of buffer = 500 ms: 164 variables per second.

  • BMEERT: 1 connection, 1 channel, 20 max variables:

    1 x 20 = 20 total variables

    If Polling of buffer = 500 ms: 40 variables per second.

Specifying the BMENUA0100 to Manage Timestamped Variables

An M580 main rack can contain two BMENUA0100 modules. However, timestamped variables in the M580 CPUs, BMECRA, and BMEERT modules can be read and managed by only one BMENUA0100 module at a time. On startup, each BMENUA0100 by default attempts to reserve and lock access to timestamped variables.

In a rack with two BMENUA0100 modules, you need to specify the one that will read and manage timestamped variables. To specify the BMENUA0100 that will read and manage variables, do the following:

  1. In the IPConfig tab for the two BMENUA0100 modules you want to have timestamping, select Activated.

  2. For the BMENUA0100 module that you want to reserve the timestamping buffer, use the WRITE_VAR block to set the %MW400 word to 2, which turns ON reading and managing timestamped variables for this module.

    NOTE: Setting %MW400 = 2 identifies the BMENUA0100 module that will read and manage variables when two BMENUA0100 modules have the Activated setting selected.

  3. For the other BMENUA0100 module that you do not want to reserve the timestamping buffer, use the WRITE_VAR block to set the %MW400 word to 1, which turns OFF reading and managing timestamped variables for these modules.

NOTE: You need to perform these steps after each change in operating mode, including cycling power ON, or loading the application, or performing an initialization.

The BMENUA0100 you specify retains control of reading and managing timestamped variables so long as both of the following conditions continue to exist:

  • At least one timestamped variable is monitored.

  • The BMENUA0100 Monitoring mode is set to either Reporting or Sampling.

NOTE:

When the Activated setting is de-selected, variables values read by the BMENUA0100 are the values in ePAC memory.

When the Activated setting is selected and %MW400 has been set to 1, variable values read by the BMENUA0100 retain the last value read when the timestamping buffer was reserved.

Monitoring Timestamped Alias Variables

The BME NUA 0100 recognizes time stamped BOOL or EBOOL Alias variables created in Control Expert, but will not similarly recognize any corresponding "Alias of" variables. An example of Alias and “Alias of” variables is shown below:

To be recognized by the BME NUA 0100, the Alias variables need to be embedded in the data dictionary.

BOOL or EBOOL Alias variables and their corresponding "Alias of" variables share both the same logical address inside M580 memory and the same EventID in the M580 timestamping buffer. Source timestamping is managed only on the Alias and not on "Alias of" variable. In other words, you need to subscribe the Alias variable (OPC UA node) in the OPC UA client to be able to receive the source timestamping from the device instead of from the BME NUA 0100 module.

Because neither the BOOL or EBOOL "Alias of" variable is seen as being at source timestamped by the BME NUA 0100 firmware, the Alias must be embedded in data dictionary. In that case, you need to add the Alias variable as a monitored item in an OPC UA subscription, in order to achieve source timestamping set by the device.