Handling Invalid Values

From time-to-time, IBEX encounters problems determining the value of a PV (e.g. because of a communication error on a device). The purpose of this page is to set out the conventions used by IBEX to indicate to the user that the value of a PV or block should be considered invalid. Blocks are, essentially, aliases for PVs. Therefore, if the value of a PV cannot be determined, the value of a corresponding block is equally invalid.

Situations Giving Rise to Invalid Values

The following situations can cause process variables (PVs) to be considered invalid.

• communication error between a device and IBEX
• a device generates a value which is outside valid range of a calibration algorithm There may be other situations which can cause process variables (PVs) to be considered invalid. If so, define them here.

Communication Errors

When EPICS detects a communication error with a device, it does two things:

1. the PV continues to hold the last-known value
2. the alarm status of the PV is changed to [what-is-the-name-of-the alarm?]

Calibration Errors

Some devices return "raw" values from sensors. Such values have to be converted into meaningful physical values via some kind of calibration algorithm (in most cases, the algorithm is merely a simple linear conversion or a table lookup plus linear interpolation). For example, a Eurotherm returns the raw voltage returned from a thermocouple, which is converted into a temperature using a lookup table.

All calibration algorithms have a range of validity - if the "raw" sensor value falls outside that range the calibrated physical value should be considered invalid. Calibration calculations are performed in the IOC, therefore, any out of range errors have to be signalled by the IOC. In this situation, it is suggested that the IOC behaves as follows:

1. the PV holds the converted value (even though it might be invalid)
2. the alarm status of the PV is changed to [can-we-invent-a-calibration-alarm?]

IBEX Conventions for Invalid Values

For each type of invalid value (described) above, IBEX will behave according to the conventions described below. There are specific conventions for different features of IBEX - the dashboard area of the IBEX GUI (i.e. the IBEX client), log files, genie_python, the Web Dashboard.

Communication Errors:

In this situation IBEX cannot read a value from a device. In practice, this means EPICS will signal a [what-is-the-name-of-the alarm?] alarm on a PV. On encountering a [what-is-the-name-of-the alarm?] alarm, IBEX will behave as follows:

IBEX GUI

1. In the dashboard, blocks will display the text "N/A" and be surrounded by a red border
2. In OPIs (which display PVs, not blocks), readback fields will display the last-known-good-value and be surrounded by a purple border. On hovering the mouse over a readback field, IBEX will display a pop-up box showing the PV name, the last-known-good-value and the alarm status.

Log & Data Files

1. In the NeXus data file, blocks will be logged with their last-known-good-value and the alarm status.
2. In the IBEX archive, PVs will be logged with their last-known-good-value and the alarm status.

genie_python In genie_python, cget is used to obtain the value of a block or PV. cget always

1. returns the value of a block or PV
2. returns the alarm status of the block or PV
3. prints a warning message if the alarm status is not [no-alarm]. It is the responsibility of the script author to check the alarm status and take any subsequent actions required.

Web Dashboard

1. In the web dashboard, blocks will display the text "INVALID" and be surrounded by a red border

Calibration Errors

In this situation the value generated by a calibration algorithm is considered invalid. On encountering a [can-we-invent-a-calibration-alarm?] alarm, IBEX will behave as stated above.