How to deal with the acquisition of undetermined number of data loggers?

[William1225]

Hi, I have several data loggers and want to connect them with PC to acquire data.

The number of data loggers is undetermined, depends on the users.

I do not want the data acquiring by data loggers in a sequence, instead of simultaneously.

I usually use the architecture of Queue Message Handler, but I not sure if it is OK to put the open VI in the consumer loop.

I tried to plot a piture to make my thought clearer.

When I start the experiment, the producer loop generate a start message to the consumer loop.

The consumer loop read the config file to get how many data loggers the user used and the COM port settings, and then open the Measure SubVI(Reentrant) to run independently.

There are two other loops used to communicate with the Measure SubVIs, one generates a notify to Measure SubVIs to write command to each other, the other listen a queue to collect the data read from the Measure SubVIs.

I felt I make the architecture a little confused, and hard to manage the Measure SubVIs.

Could someone give some suggestion how to do in better way?

[Stuart.Parkinson]

There appears to be a problem with your zip file - I cannot open it (can anyone else?)

[Bob_Schor]

WinZip says "Not a valid archive".  

BS

[William1225]

Very sorry, I used the Winrar to zip the file.

I've upload a new zip, hope it can be unzipped.

Any comment will be appreciated:)

[Stuart.Parkinson]

First question - does it work okay? Are you just after comments on the architecture or is there a problem you are trying to solve as well?

Assuming you are just looking for comments, then generally its a competent implementation of a challenging task - the re-entrant measurement vis is a good approach. You should perhaps keep references to your opened vis and close them properly on exit. I know Labview genereally does this anyway when it quits but its good practice (i'm never totally sure what it does with open refs on exit actually, but NI say close them yourself so probably should!)

I wonder if you could get away with one (or two) less loop(s). Your event loop just seems to pass the event to the second loop which then actions it. If there is nothing too time consuming in the second loop then you could probably implement most of that functionality within the event loop cases itself and lose the second loop.

Likewise, the third (notifier) loop pretty much just seems to wait for a command from the second loop and send the appropriate notifier out. Couldn't you just send the notifier directly from the second loop (which might actually now be done in the event cases, per the previous paragraph!).

Also, in your OpenVI you feed an int into a Variant to Data and convert it into and int! You could just wire the int direct to the Value property.

These comments are from a fairly brief look at the code so I may easily be missing something, but hopefuly give food for thought.

Regards,

Stu.

[mikeporter]

I see what you want to do but you are heading off in a fundamentally incorrect direction. Everything is over hardwired and under modularized. You need an architecture that is designed to be scalable from the word go.

You seem to bebe pretty familiar with LabVIEW -- otherwise you wouldn't have gotten as far as you have. My recommendation is to check the link in my signature and look at the testbed architecture I am assembling. It is based on a producer consumer pattern that is not dependent upon everything being on the same block diagram. The result is that you can expand it to do more, sometimes without even needing to modify the code.

Mike...

[William1225]

Hi Stuart.Parkinson,

Very thanks to your enthusiastic reply, I've tested the program, most functions are okay but still some bugs has to solved.

One of the bugs is just what you mentioned the reference management.

When I close the program, and then open the measure.vi, it sometimes still be running until I close the LabVIEW.

I'll keep checking what's wrong with my program.

In my thought, it's better not to put too much loading in the event case to keep its efficiency.

I also think the third loop is reduncdant, even to the fourth one(very stupid way of data collecting), it strikes me that I could implement the acquistion of multi-data loggers in the second loop recently.(deleting the third and the fourth)

The variant type is let me to transfer different type of parameters to the consumer loop, but my parameter is few.... maybe I overuse the Queue Message Handler structure without thinking over its practicality.

Thanks again to your comments.:)

[mikeporter]

The changes you are making will not correct the fundamental flaws in your software. If you really need to be able to, as the title of this thread says, deal with an undetermined number of data loggers, the code you have shown will not get you there.

Mike...

[Stuart.Parkinson]

Mike,

for my own edification, could you elucidate futhrer. It looks like spawning several instances of the re-entrant vi should work (and apparently does) and seems a sensible approach (and I've seen it used elsewhere). Why will this not work? What am I missing?

I have not had chance to look at your testbed yet which might make things more obvious, but meanwhile could you explain a little further.

Thx,

Stu.

[William1225]

Hi Mike,

Very appreciated to your suggestion, but I have some time to digest your resource.

It seemed to be useful for my case and other applications.Hope I can get your point after I finished your articles.:)