programmatic data routing in queued state machine

[dookaloosy]

Hi,

I am trying to find out if there is an easy way to implement programmatic data routing in a queued state machine (QSM). I am acquiring signals from multiple instruments, using the QSM architecture, then organizing them into arrays depending on the experiment being performed. The general idea is to allow the user to build and save a custom experiment using primitive commands, then pass the sequence of commands through a queue to the QSM which interprets and executes them.

I want to know if there is a simple way within the QSM architecture to generalize this programmatic treatment to acquired data, e.g. a command like "read data from buffer X into array Y", with X and Y determined at run-time. To bring it one step further, can arrays sizes and types be specified at run-time? That would allow the user to create and size data structures within the same "design-an-experiment" paradigm.

Some background: a previous version of the code was very crude, based off nested do-while and sequence structures that could be turned on or off by the user. Each experiment could be turned on or off, and was hard-coded with fixed routing to pre-defined data structures. As a result, massive changes to the code were required to perform the same general experiment slightly differently, e.g. cycling through devices in a different order. I'd like to re-code the test software for generality to avoid this.

Thanks

[dookaloosy]

Hi again.

I've been doing some more reading and digging. It appears that my needs may be served with a scripting language known as Luaview.

I'd like to know if anyone has worked with the Luaview package for a similar purpose, and what advice you can give.

Thanks.

[RavensFan]

I've never heard of "Luaview".

What do you mean by "buffer" X?  Where is this buffer?

If you want to programmatically direct data to different array indicators or from different "buffer" controls, put into your queue cluster a 2 references, one for the "From" and the other for the "To".   Then you can used property nodes in your consumer loop where you you unbundle the From reference, To reference, and  Read from the Value of the From reference writing to the To reference.

[dookaloosy]

I am using an architecture similar to that here: http://expressionflow.com/2007/10/01/labview-queued-state-machine-architecture/

The buffer could be a shift register to hold measured data from one or more instruments, placed within the events consumer loop (labelled as "state machine" in the previous link).

Alternatively, a buffer could be implemented as a "data queue" with an additional "data consumer loop" within the same VI. Once data is acquired, a message is sent containing the data to the data queue, where it would then be processed by the separate data consumer loop.

The problem with a non-scripting approach is that I run up against the fact that LV is a dataflow-oriented language, and indicators and wires peg down the code structure. For example, if I do test A, I would like to store measured attributes Y but not Z, as a function of X. If I do test B, I would like to store Y but not X, as a function of Z. That is, the type and dimensionality of the stored data changes depending on the test. I could design many different indicators to do so, for all the possible tests I would like to perform, but that seems truly inelegant.

[RavensFan]

Don't forget enums.  You could have an Enum with Test A, Test B, and Test C.  You can pass that enum into the queue (it would be part of the queue cluster).  The consumer loop would use that enum to drive a case structure.   For test A, perhaps it pulls the data from shift register X and shift register Y and sends them to a single XY graph.  For test B case, inside the case structure the data gets pulled from Y and Z, goes out the tunnel and goes to that same XY graph.

If you want to vary which graphs they go to, then perhaps part of the cluster is a reference to an XY graph.  You could enqueue a reference to graph A, or graph B.  When it gets dequeued, that reference tells the property node which specific graph to work on.  It doesn't "peg" the data to any specific indicator.

I just think you are underestimating how much programming flexibility you have in LabVIEW without needing to resort to the extremes of scripting.  Look up examples on property nodes and references.

[dookaloosy]

---

I just think you are underestimating how much programming flexibility you have in LabVIEW without needing to resort to the extremes of scripting.  Look up examples on property nodes and references.

---

That's an approach that I've definitely considered too.

I agree that LV is flexible. Part of the reason I asked about Luaview is because the nature of my "design-an-experiment" application involves creating a UI where the user specifies a test recipe. Essentially, I'd be writing a scripting language and intepreter frontend to the QSM. I worked on it a couple hours today and coupling the QSM with a human-friendly UI is relatively trivial but tedious work. I figured someone has had to have figured this out, hence Luaview.