Dr. Damien's Development - The Xylophone Project VI - Sound Acquisition Revisited

[DFGray]

As mentioned last week, there was a major flaw in the data acquisition functionality. I ignored my design documents and attempted to conflate the state of the data acquisition (running or not running) with the command queue. This had predictable buggy behavior. However, there was a larger flaw. In attempting to create a singleton LabVIEW class, I mistakenly put a definition of the class into the class (queue reference containing the class was part of the class data definition). The class was also not complete from the user perspective, missing several methods.

The state machine / task handler conflation was relatively easy to repair, since the state was already being stored and used. The state is now checked at the start of the command processing loop and appropriate action taken. Commands are no longer necessary in the command processor itself, removing the race condition issue. This is an inversion of the architecture suggested by F. Shubert. In addition, access to low level commands is now limited to the LabVIEW class itself, further reducing the possibility of issues. User methods were created to allow easy use of the class. The test was updated.

Of larger importance was the change made to move the queue typedef out of the class. I experimented with several architectures to allow the user VIs to operate on a singleton LV class and not have onerous development issues. It turned out to be simplest to wrap the queue and the class in a library. A dynamic dispatch input was added to each VI to allow dynamic dispatch to work correctly on children of the class.

As you might have guessed, I am still experimenting with singleton LabVIEW classes. Comments and code are highly encouraged.

Previous Installments

• Data Acquisition Concept
• GUI Concepts
• Specifications
• Core Architecture
• Data Acquisition and Note Analysis

[F._Schubert]

Hi Damien,

great rework.  Especially having several methods marked as private is a good improvment.

To make the class singleton you have to mark the Initialize.vi as private and add a get instance.vi to the public methods, that will hold the reference to the object and calls the initialize.viif the reference is invalid.

Furthermore I suggest to move the obtain command queue in the Initialize as well to asure there is a single instance of it.

Some other suggestion:

Start the Execution Loop.vi via VI Server Run methode in the Inialization.VI and hide it from the user (private). Have the Exit command for the execution loop set in the Finalization state only.

That way even very inexperienced users of LabVIEW will have no problems of using the class.

Felix

[mrutm]

Dear all;

This is interesting project. I want to apply the AcquireSound class to general data acquisition class (analog and digital IO). What is the best method to do this? Any idea?

Thanks

[DFGray]

First, you may want to look at the final code, not this intermediate step.  It can be found here.

The best way to do what you want to do would probably be to derive a child object from the AcquireSound object and override the VIs which handle data acquisition, such as Initialize and Finalize. Unfortunately, I put the sound ID in a shift register in the execution loop, so you will probably need to override that VI, as well. You will probably want to add more data in your children, such as DAQ references.

Alternately, you can simply copy the object and rename it, then rewrite the acquisition portions to what you want.  Since you are interested in digital and analog, it would probably be easier to copy to a parent class which gives you most of the functionality, then override this with analog and digital child classes.

Be aware that the architecture given in this project is probably not optimal for large project use.  While it works, I found there was too much overhead in keeping the object and its reference around the facilitate dynamic dispatch and singleton behavior.  For future use, I would probably create the three loops I currently have, but keep the objects associated with them only in the loops and use messaging through queues to update variables.  This avoids the continuous lock-unlock cycles the current architecture has using reference objects.  However, since I have not tried this yet, I can't give you much more information.