Knowledge Base

Summary

This article describes how to set up cyclic monitoring of bus devices in Elvis.

Different levels of monitoring are conceivable:

1. Line OK?
   The goal is to ensure that a line is functional (voltage present, line coupler in order, no line break). This is achieved by cyclically checking the presence of one device per line (preferably the one furthest from the line coupler).
2. Do you have any participants?
   The goal is to make sure that a participant can be reached. The check is the same as for “Line OK?”.
3. Participant “runs”?
   This goes beyond the presence. The functional readiness of the participant is checked. This check is device-specific.

Hint: The simplest and most secure method is a completely different one: querying a group address that is only connected to one communication object of the device to be monitored (the communication object must be readable and the group address must be entered as the sending address). Of course, it is best if the device offers a special diagnostic object. In the case of actuators, the feedback objects may be suitable. In order for a failure of Elvis to be noticed, ReadTimeout must be set in the connection settings!

Details

In order to query a participant, a data point must be created for him. In the Address column, enter: “#pa”, where pa is the physical address, e.g. “#1.1.17” (depending on the intended check, a component is added to this address, see below).

Such data points can only be queried. The data point will not report any change in value on its own. Therefore, a query must be assigned to the data point, usually probably a cyclic query.

Query for presence

If only the presence is interesting, then “#pa” is sufficient. The data point should be of type “Switch”. After the query, the ActualValue of the data point will be True (True, On, -1) if the device exists, otherwise False (False, Off, 0).

You can display this ActualValue on the interface, include it in a recording and/or define it as an alarm: since the alarm is to be triggered when the device is not present, both alarm limits must be set to -1.

Request for operational readiness

As indicated, this is a device-specific topic. Often, you can reach your goal with one of the following queries:

• “BCU1 Status”
  For BCU1 devices without an additional processor, you can query in the $60 (system status) memory location whether the application program is running (in this case, this memory location has the value $2E = 46). The application program will not run if a system error has occurred (e.g. defective EEPROM) or, in the case of modular devices, if the application module is not plugged in.
  The address must be set to “#paM60″ for this query. The data point should be of type “Counter”. After the query, the ActualValue will contain the contents of the $60 location.
  If you want to define the data point as an alarm, set both alarm limits to 46.
• “BCU2/0701 Status”
  In the case of BCU2 or BIM M112 devices without an additional processor, the execution status of the application program can be read out via a “property”. This has the value 1 when the application program is running.
  The address must be set to “#paP3.6″ for this query. The data point should be of type “Counter”. After the query, the ActualValue will contain the contents of the property.
  If you want to define the data point as an alarm, you set both alarm limits to 1.

Import Macro

To make it easier to create the data points, a configuration macro is available that generates the data points from a CSV file. The CSV file must contain the physical address in the first column; if a second column exists, its content is entered as data point text.

You can easily generate such a CSV file from ETS 3: open the “All Devices” window, make sure that the first two columns are Address and Description (if not, reorder via drag and drop), and export the content with the menu command File > Data Exchange.

The use of the *. PHD file is possible, but it does not contain any texts.

Download Macro