When the server is launched it tries to go to the live acquisition state. This means start receiving measures and showing them with in some attributes. This way you can have a gui where some attributes can be shown to see the current measures.
For example, you can say "I like to see the measures taken during 10 minutes". Then the device will continue collecting data and when it have this 10 minutes of samples it will cycle, having the same number of samples available from the last read.
But you may be interested in an usage of this laser to integrate data on time and collect it doing some steps. For example, if you have a surface to measure and you are scanning this surface with the laser to see how flat is this surface. For this you need synchronization between the movement and the acquisition.
That's why this device can go to a RUNNING state. In ON state is acquiring this live way.
The command start() will stop the live mode, clean the buffers (all of them intermediate and the one in the instrument), then it timestamps when the 'A' or 'R' is send to the instrument.
Then new data is collected during the time set in specific attributes for this purpose. At the end of the acquisition there will be launched a set of events to acknowledge the interface that this is done.
After this synchronous acquisition, the data will be available in this specific attributes and the live mode will continue (with clean buffers, remember).
Also I have test many error situations (hang intermediate device, unplug the instrument during some of the tasks of the devices, and so on), and it's reliable. Decays to fault state with an error message in the status to guide the user to set it up again.
No comments:
Post a Comment