Setup Screens

[iyeager]

I'm developing a pure data acquisition and storage .vi for our company and I want to incorporate some setup-type screens for the engineers doing the testing. The acquisition is being done using a cDAQ-9174 and all current 4-20mA analog inputs. However, there's thirty-two inputs possible and if they change where a sensor is plugged in or need to add a sensor I don't want them having to break into the DAQmx code to change the way the program works. I also don't want to acquire and display thirty-two inputs if they're only using four of them. Having twenty eight zeros up there would get annoying.

I've written a .vi that has the setup info in it, pretty self-explanatory, but I'm not sure how to than take this info and use it to configure the DAQmx physical channels. I'd also like to be able to update this information in the middle of the test, in case a sensor craps out or they find they missed something. I've attached the .vi, but I'm also not sure how to accomplish that since you initialize prior to running any loops?

So, basically stated, I'd like to be able to use the array of strings created by this .vi. Relate the individual string to a physical channel, than apply that channel to a DAQmx node. And have this all happen without having to shut the program down and restart it. Is it possible (of course it is) and any ideas on how to do it? The other .vi I attached (Test1.vi) was me beginning to try to get the information from the subvi, but running into a brick wall.

Any help would be greatly appreciated.

-Ian

Test Setups.vi

Test1.vi

[egraham]

Ian,

I'm not sure if you're still working on this, but it sounds like what you're tring to do is allow the user to configure the setup of the channels to acquire. This should be simple enough using the DAQmx functions like create task, creat channel, etc.

This could be done in a VI at application startup before the main application loads. The output from that VI could be a cluster containing the data for your channel configuration. Is that what you're going for?

The information could be updated easily enough during the middle of a test, but the application would continue to acquire data from all originally configured channels until you stopped the loop in charge of data acquisition and restarted it so it loads the new channel configuration. If the loop needed to continue to run and acquire data you could just wait until the next application startup to remove the unecessary channels or implement a reload button. If it's just a matter of hiding information in the middle of a test, hiding indicators is simple to implement with property nodes.

Eric

[iyeager]

Ian,

I'm not sure if you're still working on this, but it sounds like what you're tring to do is allow the user to configure the setup of the channels to acquire. This should be simple enough using the DAQmx functions like create task, creat channel, etc.

This could be done in a VI at application startup before the main application loads. The output from that VI could be a cluster containing the data for your channel configuration. Is that what you're going for?

The information could be updated easily enough during the middle of a test, but the application would continue to acquire data from all originally configured channels until you stopped the loop in charge of data acquisition and restarted it so it loads the new channel configuration. If the loop needed to continue to run and acquire data you could just wait until the next application startup to remove the unecessary channels or implement a reload button. If it's just a matter of hiding information in the middle of a test, hiding indicators is simple to implement with property nodes.

Eric

Eric,

Yep, still working on it. I actually went a different route. I'm using a MAX created task as the input to the DAQmx nodes and I've given them access to MAX so that they can configure the channels, scales, etc. It seems to be working so far, I haven't encountered any issues yet. Any hiccups you see in this logic?

-Ian

[Dan DeFriese]

Eric,

Yep, still working on it. I actually went a different route. I'm using a MAX created task as the input to the DAQmx nodes and I've given them access to MAX so that they can configure the channels, scales, etc. It seems to be working so far, I haven't encountered any issues yet. Any hiccups you see in this logic?

-Ian

Have you looked into to pointing the user(s) to Signal Express? It sounds like you're reinventing the wheel here.