I made a LabVIEW driver for a DAQ. The sampling mechanism is always the same:
- one flow starts the DAQ, tells it to sample data, retrieves that data and queues it. In a loop. This is called the Producer Loop in LabVIEW lingo
- a second flow reads data from that queue and shows / stores / processes it. They call that the consumer loop
The top loop - the producer - is always the same. This is the flow that tells the DQ to send samples, then retrieves the sampling data and enqueues it. I know how to turn that into an object (and have done that - will be released later).
I want to make the Consumer Loop OO
I want to focus on the bottom loop: the consumer. That one is application dependent. What do I do with that data?
In my examples, I have implemented several incarnations of that pattern:
- a simple flow that retrieves one channel and shows its data on a virtual scope screen
- a flow that samples two channels
- a flow that collects x samples and does a FFT
- a flow that collects x samples and calculates acceleration data from it
- a combination of those.
I'd like to use LabVIEW's OO mechanisms to provide a simple implementation. And allow the user to inherit from that and do what they want. If you are a LabVIEW OO expert, please chime in.
I am able to do Simple object wrapping
I wrapped the upper loop into a block. That's easy because it doesn't need inheritance or polymorphism. This is the original flow:
I wrapped that Producer Loop into a block, and added it to the driver lib. Here's what a flow looks like when using that block:
The whole Producer Loop functionality above is contained in that block. It makes the flow less busy, and takes care that that same logic can easily be reused - and kept consistent - in every process.
It's reuse, but not yet full OO. Here is the logic behind that block:
The keen eye will see that it is the same as the producer loop in the first and second image, with all inputs and outputs turned into connectors. You can see it in use in the 3rd image.
I need to fix one side effect of wrapping this object: It breaks the Stop button functionality, because its status is now retrieved when entering the block. Not at each iteration.
