PA-Paul Posted June 27, 2011 Report Share Posted June 27, 2011 Hi Guys, I've had this "problem" several times and just wondered if anyone here can give me any new ideas. I'm writing an application that uses an NI PCIe based DAQ card (6320 if you're interested). Whilst I'm working on the application, the DAQ card is in my computer and therefore I know what its "device name" is so i can easily configure everything to work with it and use the right channel names etc. However, if I then want to deploy my application to someone else along with a DAQ card, I have no way of knowing what the device name will be in their system. If I'm now deploying this to multiple users with multiple systems for each I can't tell whether they may already have another DAQ device in their system etc and there's a risk things could get messy... So how do I get my software to talk to the right daq card? The way I've dealt with this in the past, I've supplied the DAQ card and software, and I use an ini file for the software which contains the serial number of the DAQ card. The software then finds the device name corresponding with that serial number and then populates a cluster I can the read out from wherever I need to. This works, but assumes I know the serial number of the device. I can't garuntee that the "customer" will have labview or NiMax so I also can't assume that they can access the serial number easily to enter it into a control... Is there a better way to do this? Or a more general way even... If you rename a device in NIMax, its only a local change (I think?!), which is a bit of a pain as you can't then give your device a specific name on the system. Any thoughts gratefully accepted! Paul Quote Link to comment
TomOrr0W Posted June 27, 2011 Report Share Posted June 27, 2011 If you know that there will only be one PCIe-6320, you can modify your algorithm to search by Identification.Product Type rather than Identification.Device Serial Number. Also, there is a Location.PCI.Device Number Property (corresponding to the PCI slot number) that might (I haven't tried it) work on PCIe cards (If so, you could have the user select the appropriate PCIe-6320 from a list). Quote Link to comment
crelf Posted June 27, 2011 Report Share Posted June 27, 2011 Building on Tom O's post, you can then update MAX programmatically to add virtual channels linked to the found card - using this method separates your setup code from your application. Quote Link to comment
PA-Paul Posted June 27, 2011 Author Report Share Posted June 27, 2011 I'm going to confess I've never really got my head around using MAX to setup virtual channels and the like. I create tasks in LV and then set up physical channels etc in the code when I need them (hence needing the device name etc programatically). Should I be doing something different? crelf: can you expand a little on what you mean? Thanks for the help guys! Paul Quote Link to comment
Ed Dickens Posted August 20, 2011 Report Share Posted August 20, 2011 You should be able to read a devices serial number using DAQmx property nodes without LabVIEW installed. Don't have my laptop right now so I can't verify this. If this is correct, there's no reason to change how you currently doing this. I would write the serial number to a config file key so it can be easily changed if they ever need to change the card. You could even create a utility or routine in your application to let the user select the proper card if the listed serial number isn't found in the system. Quote Link to comment
crelf Posted August 20, 2011 Report Share Posted August 20, 2011 Building on Tom O's post, you can then update MAX programmatically to add virtual channels linked to the found card - using this method separates your setup code from your application. crelf: can you expand a little on what you mean? Sure - you can save off portions of, or the whole, DAQ configuration in MAX (export to an *.nce file), then reimport it on the new system, either by using the MAX import feature, or programmatically in your LabVIEW code (there's a MAX API under the DAQmx palette somewhere). One relatively unknown feature is that importing *.nce files doesn't (have to) over write all of your MAX settings, so, if you have an architecture that reuqires it, you can load several *.nce files as you progress through your system setup (we use this technique in modular and scalable architectures that are build to run across several different hardware platforms). 1 Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.