Question about DAQmx

[Daklu]

there are pure mathematicians and applied mathematicians.

Good analagy. I'm sure I come across as an ivory tower theorist at times--maybe even most of the time. I really am much more interested in the practical side of things. It's just that I need a more ivory tower approach than many others to meet the flexibility requirements in my current environment. (And as a practical matter, I really, really, hate rewriting code.)

But maybe not the tool-kit that comes from programming in those positions

Wha...? NI has a "Product Development to Manufacturing Transition Toolkit?" *Now* you tell me...

More seriously, you are absolutely correct. Although I have programmed in all those positions it often wasn't my primary responsibility and had to do it in my spare time. There are lots of specific things I don't know how to do that people with more Labview experience see as second nature, or even essential. NI Max is a one example. Until last week tasks confused me. Databases is another example. It's been over a decade since I've created any software that interfaces directly with a database (and that was in VB6.) That's practically the #1 requirement for manufacturing test systems. Fortunately, the other two developers have more overall LV experience than me and can help me out with the things I don't know. (Now I just need to wean them off procedural programming.)

A man of your calibre I'm sure will look at the possible alternatives and choose one that not only fixes the problem now, but is scalable and will (with a small hammer) fit the tomorrow.

Ouch... that's a pointed compliment.

Normally that is what I try to do. In this particular instance I'm choosing an option I know (thanks to feedback on this thread) may present scalability issues in the future. Why? It's the less-risky option right now. DAQmx is new technology for me that I don't understand well enough to be comfortable rolling my own Max interface. I could spend a lot of time learning DAQmx and implementing something that ultimately doesn't work. Instead of risking wasting that dev time, I'll abstract the Max aspect of the app and replace it with something that scales better when the need arises.

[ShaunR]

Normally that is what I try to do. In this particular instance I'm choosing an option I know (thanks to feedback on this thread) may present scalability issues in the future. Why? It's the less-risky option right now. DAQmx is new technology for me that I don't understand well enough to be comfortable rolling my own Max interface. I could spend a lot of time learning DAQmx and implementing something that ultimately doesn't work. Instead of risking wasting that dev time, I'll abstract the Max aspect of the app and replace it with something that scales better when the need arises.

I think you are just intimidated by the fact you have not used it before. 30 minutes and a few examples (there are lots) with a usb DAQ should be enough. You will quickly discover its not really that different from using VISA, TCPIP IMAQ or any other "open, do something close". Heck. Even use the express VIs and you will have most of the functionality of MAX.

Edited September 26, 2010 by ShaunR

[Daklu]

I think you are just intimidated by the fact you have not used it before.

Not so much intimidated as cautious. I've been burned too many times by details I thought would be easy. Our group has developed a bit of a reputation for over-committing and under-delivering. (Lots of reasons why... some we are directly responsible for, some we are not.) I'm trying to get that turned around with this project. Because it's highly visible and on a tight schedule, I'm hesitant to go down any rabbit hole I can't see the bottom of. I don't want to start a new code module I need to develop and maintain unless we really need it.

It's not just the DAQmx part of it, it's also that that aspect of the test system requirements aren't very well defined yet. I do know we won't be using anywhere near 192 different sensors. At most there'll be a pool of maybe two dozen possible individual signals, each with anywhere from 3-6 selectable scales, each with their own calibration info, each potentially measuring something different (acceleration, temp, etc.) We'll be capturing up to 8 signals at a time on an arbitrary terminals. The sample rate isn't known yet.

Should all that info come from the config file? Should I use a combination of Max and config files? What should the config schema look like? How will I simplify setting up a test in the future? How do I stupid-proof the config file? What are the other signal parameters I haven't thought of? There's lots of questions I don't have answers to right now. So I punted.

[ShaunR]

It's not just the DAQmx part of it, it's also that that aspect of the test system requirements aren't very well defined yet. I do know we won't be using anywhere near 192 different sensors. At most there'll be a pool of maybe two dozen possible individual signals, each with anywhere from 3-6 selectable scales, each with their own calibration info, each potentially measuring something different (acceleration, temp, etc.) We'll be capturing up to 8 signals at a time on an arbitrary terminals. The sample rate isn't known yet.

Indeed.

So Lets say you use MAX. They create 24 "tasks", set up values for scaling and calibrate each channel (probaly a good 1/2 days work). Then they want to change something on one of the tasks. Do they modify the original task? Or do they create a new task, set up the new scales and re-calibrate on the premiss that they don't want to "lose" the old settings because they might come back to it?.So now we may have 48 tasks

Lets say they they keep to 24 tasks. Then they come to you and say "right, we want a piece of software that logs tasks 1,3,5,and 9 except on Wednesday, when we'll be using 1,6,12,8". How do you store that information in MAX?

Should all that info come from the config file? Should I use a combination of Max and config files? What should the config schema look like? How will I simplify setting up a test in the future? How do I stupid-proof the config file? What are the other signal parameters I haven't thought of? There's lots of questions I don't have answers to right now. So I punted.

That's up to you. You'r the only one that knows what tests and what's required. I think what you will find (personally) is that you start off using MAX then as things progress you will find more and more you need to have more external control until you reach a point where you have so much code just to get get around MAX that it is no longer useful and, in fact, becomes a hindrance. But by that time you are committed. Thats just my personal experience and others may find it different.

We actually use several files. One for Cal data, one for general settings (graph colours, user preferences etc, etc), one for each camera (there can be up to 5), one for DAQ (basic config) once for drive config and one for test criteria. The operator just selects a part number (or a set of tests if you like) from a drop down list and can either run full auto, or run specific test from another drop down list filtered for that product (well. Not filtered since it it just showing the labels in the test criteria file ). But having a directory structure makes that really easy, since all it is doing is selecting a set of files.I think that type of interface would be a bit further down your life-cycle. But the building blocks started out just as you are currently doing and all that we did was put them altogether in a nice fancy user interface (it even uses sub-panels to show some of the original UIs we created when testing the subsystems).

Edited September 26, 2010 by ShaunR

[Daklu]

I appreciate the feedback Shaun. This is the kind of discussion that makes LAVA so valuable.

So Lets say you use MAX. They create 24 "tasks", set up values for scaling and calibrate each channel (probaly a good 1/2 days work). Then they want to change something on one of the tasks. Do they modify the original task? Or do they create a new task, set up the new scales and re-calibrate on the premiss that they don't want to "lose" the old settings because they might come back to it?.So now we may have 48 tasks

Good questions. Here's what I have in mind...

In my project I have one task, 8 channels, and 8 scales. As near as I can tell users can't edit those in Max so this is effectively a default setup. I believe any custom setting will require a new task, channels, and scales to be set up in Max. New tasks are created only when significant parameters are changed, such as the number of signals being captured or changing the input terminals. Each Max scale will apply to a specific signal from a sensor, so there will be up to 24 of them. (On second thought... there'll be one scale for each setting on each signal, so there could be a lot of them.) I'll have a global virtual channel for each DAQ terminal giving me 8 of those. I think those scales and virtual channels will be sufficient to cover all combinations.

When the test engineers are setting up a test they can go into Max and look at the Task details to see which terminals should be connected and change the sampling rate if they want. Then they go into the individual channels and modify the settings and scale to match the sensor signal they have connected to that terminal. There are a lot of scales to choose from but they are edited rarely, such as when I get an updated cal sheet for a sensor. If I'm thinking about this right, this should give the test engineers a lot of flexibility without completely overwhelming them. Are there any gaping holes I'm missing?

Lets say they they keep to 24 tasks. Then they come to you and say "right, we want a piece of software that logs tasks 1,3,5,and 9 except on Wednesday, when we'll be using 1,6,12,8". How do you store that information in MAX?

Starting and stopping tasks during the test is out of scope right now. If they *do* come to me with that request, I'll roll my eyes, sigh loudly, and make them feel bad for even asking.

I think what you will find (personally) is that you start off using MAX then as things progress you will find more and more you need to have more external control until you reach a point where you have so much code just to get get around MAX that it is no longer useful and, in fact, becomes a hindrance. But by that time you are committed.

That is a concern. The application doesn't actually use Max though. The app only cares about the Task. Max is just the interface for configuring the Task that will be run. I think I can design the app in a way that will make it easier to insert a new module that provides an alternate way to configure the Task for a given test.

[ShaunR]

In my project I have one task, 8 channels, and 8 scales. As near as I can tell users can't edit those in Max so this is effectively a default setup.

I'm not sure about that. From the last time I used MAX. It was a case that in the project you create a MAX database file which is deployed with the installation (under the build specifications >>New installer>>Hardware Configuration). If that is the way you are thinking, then your "default" will only be applied every time you install as well as deleting any changes or additional tasks. Additionally. Once it is in MAX, I'm unaware of a method to "lock" a task so that it cannot be edited (jump in here JG) .

However, if you create that task dynamically (delete if exists, then add it again) every time you run your software, you will have a task that can be reset to default just by re-running your program (or by pressing a button). And if you do that you have the major component of the file system/database implementation

I believe any custom setting will require a new task, channels, and scales to be set up in Max. New tasks are created only when significant parameters are changed, such as the number of signals being captured or changing the input terminals. Each Max scale will apply to a specific signal from a sensor, so there will be up to 24 of them. (On second thought... there'll be one scale for each setting on each signal, so there could be a lot of them.) I'll have a global virtual channel for each DAQ terminal giving me 8 of those. I think those scales and virtual channels will be sufficient to cover all combinations.

This bit, I think, will cause them to moan quite a lot as well as being extremely error prone. If you had a way to "copy" the default then I don't think it would be so bad, but I'm unaware of a way to do that in MAX.

When the test engineers are setting up a test they can go into Max and look at the Task details to see which terminals should be connected and change the sampling rate if they want. Then they go into the individual channels and modify the settings and scale to match the sensor signal they have connected to that terminal. There are a lot of scales to choose from but they are edited rarely, such as when I get an updated cal sheet for a sensor. If I'm thinking about this right, this should give the test engineers a lot of flexibility without completely overwhelming them. Are there any gaping holes I'm missing?

Well. You could update the scales directly from the spec sheet (or an automated derivative) to make yours and their lives easier.

Starting and stopping tasks during the test is out of scope right now. If they *do* come to me with that request, I'll roll my eyes, sigh loudly, and make them feel bad for even asking.

No abort button ? What I meant was actually covered in your previous description, where they have to create a new task.

That is a concern. The application doesn't actually use Max though. The app only cares about the Task. Max is just the interface for configuring the Task that will be run. I think I can design the app in a way that will make it easier to insert a new module that provides an alternate way to configure the Task for a given test.

Indeed. Your application is relying on the most error prone part of the process (configuring MAX). This is what worries me. But I'm not sure what module you would want to write to configure DAQmx, since the whole purpose behind using MAX is so that you don't have to is it not?

[Grampa_of_Oliva_n_Eden]

Long thread little time to read, excuse rep's.

I gave up on MAX config years ago since maintaining it was labor intensive (abandoned in LV 6.1).

Since then I explicitly (most of the time, yes sometimes small bugdet projects warrent short cuts) do all of the configs myself as driven by config files. Yes I have to write all of my own config code but I would rathe have the power than have my hands tied (A customer has an app developed by a third party since then out of buisness. Scaling in MAX is used but since teh scale factor they need has hmmmm... 6 leading zeros before the number but MAX only shows 5... can't fix MAX!).

Doing my own scaling let me log the raw scaled along with scale factors (used by govenrment agengies that want to track back measurements with calibration etc).

I don't have to be an expert at DAQmx but I exploit the wizards. Craete a task in MAX that gets close. >>> Creata a DQXmx constatn on diagram >>> Choose the teas you created >>> Choose "Generate Config and code". LV will wire up a diagram with the proper flavors and properties for you. I then suck these into my code.

Hints:

Input and Output Properties can have the same name but you can't set an output property for an input channel. So watch for input vs output.

Add clear error eneuciations so that when someone goofs your config they will get a story to go with it.

Ben

[ShaunR]

What should the config schema look like? How will I simplify setting up a test in the future? How do I stupid-proof the config file? What are the other signal parameters I haven't thought of?

I thought a bit about this. Below is an example of a simple "possible" DAQ config file.

One thing you can do to poke-yoke the file is have a "default" button which reloads (but does not save) the original config you decide on. That way they can always get back to a known "good" config and have "commit" and "Save" buttons, One which is temporary and will not be retained between launches of the software but allows them to "play", the other saves over the previous file. You can also do other stuff like having excel macros or create an interface for entry checking etc, but its not really necessary. Its really up to you. Its very flexible and scalable.