Multiple DAQ usage

[Leatherneck1957]

Please check out my VI and make recommendations and comments. I'm trying to learn how to use multiple USB DAQ devices for times when I need more I/O than one DAQ can give me. This was my first attempt. Pretty simple I admit. Also, for expediency I just copied the relevant stuff to make two paths. But I think I later I would just make a sub vi and use the sub vi twice. Anyway, let me know how I could have done it better. Maybe a different architecture fits the problem better. 

Thanks in advance for your insight. 

[Cepera · Accepted solution]

You seem to be using Measurement Computing hardware. Few people have MC ULx libraries installed. Otherwise, the code is good enough, except that I would lay it out more neatly in order to improve readability. Other things to consider, given that all your data acquisition and processing parameters are identical for all DAQ devices and channels:

• You can concatenate readout arrays into one array and perform your scaling arithmetic on an array, and then either present the results in an array of indicators or at least index the result array as far downstream as possible.
• You could probably benefit from combining task references into an array and process them in a loop (with parallelism, assuming that MC ULx does not serialize calls to DAQ Read). The output of the DAQ Read loop would then be a 2D array which you can scale as an array and present results on a 2D array of indicators.
• If you used NI hardware, you would be able to combine multiple DAQ devices into one task and then treat them as one virtual device, I think. Maybe a similar option is supported by the ULx library; I am not familiar with its capabilities.

[Leatherneck1957]

Very good information. Being new, I would have not thought about combining things using arrays. As for the Measurement Computing hardware, you are correct. The only reason I used them was because our resident LabVIEW expert won't use anything else; so we had a couple on hand. He also use's frame's a lot! something that I thought we should use very sparingly, because it overrides data flow.. The other thing he uses all the time is a library that is not supported anymore by LabVIEW; DAS16. So I'm trying to not use him for advise when it comes to LabVIEW programming. He is very one way and will not change or entertain the new paradigms. I mean he gets things done, but I don't want to get bad habits. That being said, I will get some NI DAQ's and go from there. His reasoning for using MC is price. Price should be considered, but shouldn't be the only factor in decision making. Anyway, I really appreciate your time. I will think about how to implement your suggestions.

Regards, 

Mark.

[GiantDeathRobot]

Some fun information: Measurement Computing is a subsidiary of NI, they were acquired in 2005. It looks like ULx (MC's driver) follows a pretty similar API to DAQmx (NI's driver), which wouldn't be too much of a surprise. So if you're looking for examples of how to use it, you could get a rough idea from the DAQmx examples.

Also, roughly how much experience with LabVIEW do you have so far? The majority of LabVIEW programming falls into a riff on a handful of architectures. So if you get familiar with things like state machines, Producer-Consumer, etc., you'll be well on your way to not getting into bad habits. A couple other ways to keep improving:

• If you have an active license for LabVIEW, you should have access to NI's self-paced online training, which has most of the basic LabVIEW classes.
• If you're in the Boston area, NI holds classes in their regional office fairly often. (I taught a few of these when I was an Applications Engineer, and always enjoyed talking with the students about what they were working on, so it's a good place to get some extra insight from the people you'll call for help if things go wrong.)
• Once you get a little more practice, there are a couple Boston LabVIEW User Group meetups throughout the year where LabVIEW users get to talk about what they're working on and share ideas. 

And, of course, we're pretty friendly folk on here too.

[Leatherneck1957]

Well, I'm new this year to actually having an opportunity to develop some LabVIEW skills. I have used programs written by others for many years. I actually convinced my boss to purchase LabVIEW core1. So I am working through that book right now. Thanks for your help. I will stay active on this group and let everyone know what I'm up too as I progress through the course. I also have a project to work on, that is probably above my head, but I'm diving in anyway. So there will be a fair amount of learning and applying right away. Trial by fire I guess. Well, thanks again for your input. The first book has already started talking about state machines, and event programming. I have heard of producer/consumer architecture but have no experience with it; yet. 🙂

Regards,

Mark.

[Leatherneck1957]

The information about performing the arithmetic on the array data was very helpful. I just didn't think about doing that. I have since incorporated that idea into my VI and when I save the data from the sensor I convert the raw sensor data (which is a voltage from .5v - 5v), to a pressure from 0 to 15 PSI; the light is getting better. Thank you so much. Things that are probably obvious to you, are still in the dark for me. Thanks again. I am studying the Core1 book currently and I am reading books that I have bought. But there is no substitute for the experience that the members of this group.