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.
Solved! Go to 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:
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.
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:
And, of course, we're pretty friendly folk on here too.
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. 🙂
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.