Passing data between parallel loops in a re-entrant VI

[blackburnite]

So I'm working on a test system with three independent stations that all function the same way so I have a "Test Engine"  re-entrant VI that runs on each of the stations.  In this VI there are several loops which I need to pass data between.  Just to give a brief idea of the structure, there are 4 loops, a User Event loop, Controller loop, Test Sequence loop, and Status loop.

The User Event loop no surprisingly handles user events for that station and passes messages to the control loop

The Control loop manages messages specific to the test station as well as messages from the main tester app such as "Stop All stations, etc"

The Test Sequence loop, waits fora "Test start/Stop" from the controller loop and then executes a series of test scripts sequentially

The status loop continuously monitors the station conditions and sets holding flags depending on the conditions to allow or prevent certain actions by the user

Normally, for a smaller, simpler VI, I would use queues or functional globals to do this, no sweat, but because this is a re-entrant VI, I can't go the functional global route and using queues would require a more complex design than your typical producer/consumerand which would require more work than the benefit it would provide.  Right now, the best methodmyself and and the other guys I work with have come up with, is to use local variables and hide the FP controls.  Anyone who has used LabVIEW for awhile knows the general issues withthis so I'm wondering if anyone has ever encountered a similar problem with passing data between loops in a re-entrant VI and how you might've solved it?  Thanks,

- Will

[Hooovahh]

Spend the time up front to allow for a good communciation between "actors".  It sounds like you are describing an actor design without using that word.  Make no mistake that the Actor Framework is not the only design pattern that makes actors.

I highly suggest a lossless communication protocol like a Queue or a User Event for passing critical data between actors, and a functional global (VIG, LV2 Global) for making data available in the application which is not time critical, and should be a write in one place, and read in many other places.

I'm not quite sure why you are resistant to use a Queue.  You say it will add complexity to the design, and it probably will, but it also has the ability to make your application work better by being more modular, and reusable.

[GerdW]

Hi will,

you should use queues as in a small VI!

Just give your queues names depending on the instance of your reentrant VI…

[stevem181]

Hi Will,

Contrary to popular belief, you can use a non-reentrant functional global in multiple clones.

You just need to ensure that each clone can only access its own data. Here’s how:

1. Create a required numeric input on the clone. Let’s call it “clone index”.

2. Assign a number to each clone’s “clone index” on the block diagram starting at 0.

3. In your functional global, use the “clone index” to only allow access to data for that clone.

You could have the functional global simply hold an array of the original data.

Use the index you get from the clone to select the correct element to read or write.

Be sure to consider the access rate for the functional global. Fast loops or large amounts of

data could cause lags between instances of your “Test Engine”.  The same is true for other

“Test Engine” subvis – which might benefit by being clones, if they are not already.

As for queues -don’t miss out on their many benefits.

It doesn’t take too long playing with them before they make sense and are easy to implement.

And the forum is here to help if you have problems.

steve

[blackburnite]

In general, our test engine is set up very much along the lines of a set of actors and ultimately I would like to go through and overhaul the whole framework to use a more modular queue based approach.  Regarding using indexed global variables, we do use these where speed isn't an issue but as mentioned, for circumstances where we would need to read/write data to the global, across multiple instances simultaneously, an indexed global often isn't fast enough.

In the short term however, I just wanted to check on the forum to see if anyone had come up with something that could work as a quick fix, but I definitely agree that in the long term, a solid comunication architechture is something we'll be spending the time to hammer out.  Thanks for the feedback!

[billko]

---

@blackburn.will wrote:

In general, our test engine is set up very much along the lines of a set of actors and ultimately I would like to go through and overhaul the whole framework to use a more modular queue based approach.  Regarding using indexed global variables, we do use these where speed isn't an issue but as mentioned, for circumstances where we would need to read/write data to the global, across multiple instances simultaneously, an indexed global often isn't fast enough.

In the short term however, I just wanted to check on the forum to see if anyone had come up with something that could work as a quick fix, but I definitely agree that in the long term, a solid comunication architechture is something we'll be spending the time to hammer out.  Thanks for the feedback!

---

I'm not sure what your experience level with test setups are, but my experience is that there will only be one time - like right now - to hammer things like this out.  No matter about your best intentions; you'll probably never get another chance.  Unless, of course, the fragile quick fix breaks and you have to bring out the hammer anyway.  Which, of course, will cost you time and money now because now your equipment is down and you are using a test station to debug on, plus regression testing because you are rewriting major portions of the test to accomodate the new, more robust code.

[Hooovahh]

Just here to say I agree. Spend as much time up front. If done well it will save lots of time and money later.

[mikeporter]

Absolutely take the time to get it right the first time! In doing this work (LV development) for almost 30 years I have yet to see even one single case where a quick and dirty solution actually saved time over any time scale.

By the time you are done with the initial development they take longer. Then testing and qualification takes longer. And that's just over the immediate short term where you are trying to save the time.

Maintaining them also takes longer.

Mike...