How do I programmatically test all active channels in LabVIEW?

[ThomasO]

I have gotten as far as detecting connected modules and getting a list of all channels associated with the modules.  my problem is as follows, I want to be able to hook up wires to any channel and have labview do the following:

1)find all the modules. done.

2)find available channels on each module. done.

3) ping each channel to see if it has a value withing a range that tells me the wire is hooked up.  having trouble here.  I will describe below.

4) configure DAQmx based on the results.

many channels take multiple inputs. thermocouple, voltage, strain, RTD, resistance..........    i can get potential measurement types based on the module with property nodes.  when i go to create a channel in DAQmx, i cant just wire in a measurement type.  i have to choose what kind of measurement when i place "create channel" in the block diagram.  I might be able to get around it by making a case structure for every module or every measurement type, but if I do that, then i need a case for every module or measurement type made because that is the potential output of the property node.  i was hoping to modify the "create channel" vi to take a measurement type input, but no success.

long story short is that I am sure there is an easy solution, but I am missing it. 

I included what i have so far.  it's a bit of a mess as I was shotgunning ideas.

[G-IV]

Hi Xx_thomas_xX,

I'm not sure that this is something that LabVIEW is setup to do without doing some legwork.  

You are going to need to create a task, test it, if it is out of whatever bounds you expect, close the task, make a new task, test it, rinse and repeat.  

Can I asky why you need to do this?  There may be a better option that we can think of.

G-IV 

[Kyle97330]

I agree with the above poster that there's not really a way to do this in LV without doing all the legwork you're reluctant to do.  There's probably a better way.

I have a system using a compact DAQ with various different modules in it that I didn't want to hard-code to have to be in certain slots, so I wrote a routine similar to this one to first find module 9425, then find 9481, etc etc. but what you seems to want to do is to be able to just randomly plug in any NI DAQ in the world and then attach a wire to any input at random and then get data from it.  That seems like far too wide of a scope.

As an additional note, unless AI.PhysicalChans is the exact same on all of your modules, you're going to have a 2D array that some entries will be blank on and will cause errors.

Also, you never need to wire the N input of a FOR loop using auto-indexing unless you deliberately want to run the loop less times than the full input array has indexes.  Since you want to run them all, it's unnecessary.

[ThomasO]

I did take the "create task" and modified it to take an input of "measurement type" . LabVIEW did NOT like it. It fails and i am relinking to the top level program fairly often. 

The reason I am doing this is I want to be able to have several test harnesses connected in a production setup.  by hooking up a harness, Labview can determine the product type and necessary testing based on which one is active.  Right now, it is RTDs and Thermocouples, which is a simple matter. Scan for one of 2 box types, scan the channels, figure out what i hooked up, and that determines test parameters.

What I was hoping was to do this dynamically.  then i can adapt it to any test.  I could hook up any box and any channel and perhaps have a dropdown for active channels, or whatever.  It would make it more applicable in more situations.

the biggest advantage to this, right now, is to reduce user error for those that are less familiar with configuring tests and reduce setup time. If i can make a front panel that only takes a serial number and does the rest automatically by hooking up the part, that would be great for production.  If I am going to do that for one piece of equipment, I was wanting to make a more generalized sub vi that has more potential with less setup while I am at it.

[Kyle97330]

What if you:

1. Plug in test setup

2. Open NI-MAX

3. Right-click Data Neighborhood and click Create New

4. Choose to make a NI-DAQmx Task

5. Choose all parameters for the readout needed

6. Assign it to a device

7. Name it in a meaningful way

8. Repeat for all measurements you want to take

9. Save configuration and exit

Now, in LabVIEW, add a front panel control of the type DAQmx Task.  Your user picks the task from that selection.  Use the task name and/or the multitude of DAQmx property nodes to determine which type of IO function to route it to and go from there.

[ThomasO]

that would probably work, I just really wanted the user to not have to do anything.  make it so simple, my 8 year old can do it.  

1) copy number from part onto screen

2) plug it in

3) press go

literally no configuration. I already have a working program that automatically configures the test setup based on program name.

1) channels used

2) RTD type or thermocouple type

3) default test parameters based on program name.  you change it only for R&D programs

4) automatic filename and path creation

its pretty close to what you describe. I was hoping to make it even easier.  I got the idea from the module finder that i got from these forums.  essentially it finds a box then runs the test on that box.  the primary function of this module is to accomodate chassis with different serial numbers or designations in MAX.  so as you deploy executables, they dont get hung up when you send equipment out for calibration.  it has an issue with multiple boxes of the same type, but it doesnt matter at this point.  it also allows the cal lab to calibrate the equipment without needing a full  labview license. 

so i took that idea and thought, well, if we have OEM harnesses for testing, then we can hook them all up, which reduces wear and tear on the box terminals and the D sub 9 connector on the bottom. then, instead of choosing the part/program/harness/RTD type/etc., just make it figure out whats hooked up and configure it automatically.  

[Kyle97330]

By any chance do these test setups have any universally unused digital in pins?

If so, and they have N unused digital in channels, you could make a crude ID system using binary to be able to check which of the 2^N different harnesses you have plugged in.

Failing that, at some point you have to start believing that your end user isn't a complete idiot and just ask them to tell the software which one they plugged in...

[ThomasO]

They do not. just analog in channels.  As I said, i could pare it down to just what im using, i was just hoping to make a universal sub vi that i can drop into other setups as well with no reconfiguration.  

Secondly, im not designing it with the end user being an idiot.  Its about having fewer steps to perform  and increasing throughput.  The automation does also prevent simple operator error. those errors are fixable, but its nice to not waste four hours of testing.  I'm going for a "ronco" wind tunnel.  "set it, and forget it". minimal input, minimal upkeep.  we already reduced the operator contact time from continuous contact down to ten minutes every 4 hours.  Pretty good.  Now my goal is to reduce the training time by making it ridiculously easy to run.  The training time will be spent interpreting the results.

The impression I am getting is that it is not practical, so, for now, I suppose i will just make one that handles the boxes we use and add in functionality as we expand.