I would appreciate opinions on the architecture of a design I'm currently working on. Its predominately a Labview issue, but has some TestStand interactions so bear with me.....
***Environment...
TestStand 4.1 development
Labview 8.5.1 full development
Windows XP
I'm writing a Teststand test system using the parallel model with three sockets. All three sockets share several common hardware resources (DMM, DC source, barcode scanner etc).
My design allocates a Labview VI to each item of hardware, with the relevant TestStand socket calling these VIs when it requires the instrument resource. I start each of these VIs in the TestStand "process setup" callback in a new thread.
To allow TestStand to control these "instrument" VIs I have setup a Queue/Notification between each VI and TestStand. Each of these VIs are based on the queued statemachine architecture - I have a command Queue that I use to pass commands and settings from TestStand to the instrument VI (DMM measurement commands, DMM trigger settings etc). My queued state machine continually services these commands as they arrive on the queue. I also have a notification that these VIs use to send data back to the TestStand sockets (DMM measurement results, I/O statuses, commandt acknowledgements etc).
Hence to my question on architecture on the Labview side of things......
I have two ways of passing my command data structures, and my notication results between TestStand and the instrument VI.
Approach 1/ My queue is a simple enum that describes the command desired (e.g. set dMM trigger), but the actual command data (trigger settings for instance), is contained in a functional global variable. The relevant TestStand socket sets the functional global variable settings, and places a command enum onto the queue. The instrument VI actions the command and puts the result (the DMM reading for instance), into another functional global. It then sends a simple enum acknowledge back via the notification to the TestStand socket. TestStand then reads the functional global if any data is required.
Approach 2/ This design still uses a command queue and a notification reply from my instrument VI, but does away with the functional global variables. Instead the queue and notifications are comprised of clusters. For instance my DMM command queue has a cluster comprising a command enum and a trigger cluster. My acknowledge notification has a cluster comprising an acknowledge enum and a result cluster (voltage, underrange, ovverrange etc).
I'm currently preferring approach "2", as it does away with messy functional globals and is quite elegant. I've built a prototype system using approach "2" which appears to work well. However my questions are...
1/ What sort of processing overhead am I adding to my TestStand to server VI communication? My queue and notification clusters can get quite complex. My gut feeling is using a modern processor, the queue/nofication overhead would be trivial compared to say a DMM measurement acquisition - but am I correct?
2/ Is it valid to attach a labview waveform datatype to my notification? Labview lets me build such a structure without error, but I'm a bit confused as to whether a dynamic structure such as a waveform datatype can be used in a notification definition (i.e. passing a waveform data array to the "element data type" connection of a "ObtainNotification" VI). Does the notification automatically allocate/deallocate memory space as the waveform array grows - or is this in breach of a notification definition?
Thanks for your advice...
