Finite data storage, retrieval and display within a while loop

[jcannon]

Hi DFGary,

Thanks for the feedback... A number of people (including yourself) have also suggested the use of a command pattern for my instrument... I have viewed your link and haved searched extensively online; however, I cannot find a nice and simple example of this pattern that I can understand... I am very interested in this, but as you said, this is warping my thinking...!

Any chance you could me with a very simple example of one that describes the function/action of the elements involved (or direct me to one)?

Regards,

Jack

[DFGray]

Might be easier to try to explain it.  Start with a simple, queue driven state machine.  At every iteration of a WHILE loop, you dequeue the next state from a queue.  The queue element contains the next state and any data associated with it (commonly a cluster of enum and variant).  The state is used to select a case from a case structure and run the code in that case.  The WHILE loop contains a shift register used to store state information for the state machine, usually a big cluster.  This works well and I have used it many times.  But it does not allow you to easily change states or dynamically add states without adding elements to the case statement.  Enter LabVIEW classes and the command pattern.

LabVIEW classes are by value, so they propagate on wires.  However, the type of the wire is not as strict as most LabVIEW wires.  The actual data on a LabVIEW class wire can be either the parent wire type or any of its children (parent/children in the object-oriented sense).  So, for example, if you have a parent wire type of DAQData which includes the waveform and range settings of the DAQ card, the wire could equally easily contain data of a child class, DAQDataPlus, which includes the original data, plus the operator and test run to generate the data.  So you have sort of polymorphic wires.

But classes have functions too.  And functions can either be passed on or overridden by children of parent classes.  The override case is the more interesting one here.  Using the previous example, let's say the DAQData class has a WriteToDisk function.  This function writes the waveform and range settings to a text file.  The child class DAQDataPlus overrides this to write the waveform, range, operator, and test info to file.

Now for the fun!  When you write a function for a class, the object input can be set to "Dynamic Dispatch".  This means that LabVIEW will pick the function which matches the object type (parent or child) which comes in at run time.  So let's say that the wire contains a parent object.  At run time, it will run DAQData:WriteToDisk.  If the wire contains a DAQDataPlus object, it will run DAQDataPlus:WriteToDisk.  Now let's take this to the queue driven state machine.

The queue element is now a parent class.  Every case of the normal state machine is replaced by a child class of the parent.  The child class itself serves to select which code will be called.  The data of the child class is contained within the object, so there is not need for an extra variant (more efficient).  Your base code is now a while loop with dequeue and the parent function (usually with both a dynamically dispatched object input and a state data input).  You can now write new functionality without changing the actual state machine code.

Hopefull, in conjuction with the example I linked to above, this helps.  Try to write a simple state machine using this idea before modifying your code.  Note that you will need to coerce your children to the parent class before stuffing the queue, since the queue is strictly typed.  LabVIEW still "knows" it is a child class object.

Let us know if you need more info.  This can be a bit strange to learn, but you won't want to go back once you do.  Good luck.

[jcannon]

Crikey!!.... This looks extremely complicated for an exercise science academic such as myself... I love playing with labview and working on my instruments, but recently I been spending more timing learning the 'art' of labview than collecting data or writing papers... Which is not good...

However, I am committed to learning this 'dark magic' know as command pattern... I now use labview for basically all DAQ needs and cannot see this changing... Labview is just too damn flexible (why buy commerical DAQ software when you can write your own, which is more flexible and does EXACTLY want to want it to?)....Not to mention the $$$$ saved (albeit that time to write the code is a cost).

So I am thinking of this as an investment in my future research productivity... The TMS.vi now has a very tight deployment time... So will probably not get a chance in the next while to work on modifying this code it instrument needs to be used... However, I will keep this thread open and get back to you when I have made some progress on the QSM to begin with...

Thanks for all you help with this... You must be sick of my postings!

Kind regards,

Jack

[DFGray]

My apologies for the extremely late reply - I just returned from a family reunion.  The command pattern is actually not as complex as it sounds, but does take a bit of time to wrap your head around (at least for ordinary mortals like me).  But it does take time, so I will confirm your good choice about not using it now.

Keep on posting!  I was an industrial physicist working in a small company, and essentially the only LabVIEW programmer in that company before joining National Instruments, so I appreciate your position.  Good luck.