Introduction
Some function blocks need to know when to start and when to stop data processing. One such example is the storing function block that should store data only between the start and stop pulses. openDAQ should provide such a trigger to function blocks without the need for each function block to invent their own.
This should be achieved through the use of operation modes. Operation modes should contain a mode where function blocks (or devices) are not operation → eg. AO signals are not being output, File Writer function block is not writing.
Any openDAQ component should be synchronously notified of an operation mode change and should be able to react to it immediately.
Additionally, the operation modes should facilitate any standard modes available in the test and measurement industry. These are as follows:
- Idle → Configuration, no data processing (no packets)
- Preview → Configuration, all signals inactive unless they have a “Preview enabled” flag → not part of 1st iteration
- Safe Operation → Configuration, full rate data, no physical sinks are online
- Operation → Configuration, full rate, all sinks active; default state unless specified otherwise
All operation modes except for “Operation” should be opt-in.
User stories
- Storing function block receives a trigger that the operation mode is changed from “Safe Operation” to “Operation” and starts storing data. It stops storing when the mode is changed from “Operation” to another.
- An AO is active while the device is in “Safe Operation” mode. It does not output data to the physical world
- A new function block is created and is not aware of the device state during creation. After creation it receives notification of the current device state, allowing it to finalize configuration and start operating.
- Software is put into “Preview” mode, and an FFT preview is shown. It sets the FFT signal to preview mode. All signals required for the calculation of the FFT function blocks are set to “Active”, rest are “Inactive”. Inactive signals are not streaming any data.
Desing Proposal (optional)
The operation mode change on a device should trigger a callback on all the device’s “non-device” children. The final implementation of the operation mode changes should include acquisition locking of children, flushing the openDAQ system of packets, invoking the opModeChanged callback, and finally unlocking the acquisition.
As such, the steps are as follows:
device.lockAcquisition()deviceChildren.onOpModeChange()device.flushPackets()device.unlockAcquisition()
- Operation modes are defined as an enumeration in openDAQ.
- The operation mode of a device can be viewed and changed by openDAQ clients.
- The operation mode change command recursively changes the mode of the entire device’s subtree.
- Operation mode change events are available to all components.
Release Version
3.20
Who shall implement the Feature
openDAQ
Contribution
Status
Feature Planned on Roadmap
Feature Request is discussed in Working Group
Feature declined.