|
For the Sound and Vibration Measurement Hat for Raspberry Pi road test, I'm reviewing Measurement Computing's IEPE Measurement DAQ HAT for Raspberry Pi. In this (short!) post, a LabVIEW Utility block to wait for a status.
|
Most of the components I write for the LabVIEW instrument driver are direct commands. Configure the clock, set sensitivity, ask a status. The simple component in this post is different. It's a helper function that waits until a certain condition is met. In this case: wait until the two ADCs of channels 0 and 1 are in sync. It's an example of reuse. This functionality will be needed in most of the real flows, so the block can be reused. And it reuses the existing Query Clock Sync block. Double whammy. A third advantage is that you save real estate in the final flows. This little block takes significantly less space on the canvas than its implementation.
Wait for Sync
This is a pre-condition for the sampling functionality.
From the documentation:
The scan cannot be started until the ADCs are synchronized, so this function will not return until that has completed. It is best to wait for sync using mcc172_a_in_clock_config_read() before starting the scan.
That's what this block offers. It 'll loop until the two ADCs are synchronising. A later implementation may include a time-out or a number of tries. The advantage of using a Utility block is that all flows will automagically inherit this enhancement. And that you have an already tested piece of flow.
The outer rectangle is a WHILE, the inner rectangle a conditional CASE.
The block checks if the ADCs are in sync, via the Query Clock Sync block. If not (output is false), then the flow pauses for 100 ms and tries again. If they are in sync, the output is true, and this flow executes:
The block doesn't wait (anymore). The while loop exit condition is met and the block hands the execution over to the downstream flow. In a user process, you can appreciate that the complexity (admittedly simple) and screen space requirements are reduced:
