Writing to DAQmx Channel property nodes does not update channel values

[DianeS]

Hello all,

I have a conundrum.  I have programmatically created a task in LabVIEW, and programmatically added several analog input channels to the task.  That's easy.

I would like my user to be able to edit individual channels within the task.  To this end, I've created a set of VIs which allow him to change settings appropriate to the channel (for instance, if it's a thermocouple channel, he can change thermocouple type, CRC value, etc...if it's a strain gauge channel, he can change poisson ratio, and so on).  Those VIs all work admirably, as does the VI they live in.

The specific issue I am having is that writing to the channel property nodes does not update the channel settings.  See images below.  The first image is the code that should set the new channel settings:

Note that immediately after setting the property nodes, I'm reading back their values, just to see what comes back out.

The second image is an image of the FP immediately after running this VI.  Note that the values read back from the channel property nodes did not update to match the set values, but instead retained their original configuration values:

What am I doing wrong?  I've been fighting this for a few days now and I'm mystified.

Thanks for your time!

Diane

[Bob_Schor · Accepted solution]

Hi, Diane.  About a week ago, I also had a problem changing Channel properties (not sure our situtions are exactly comparable, but ...).  My "solution" to wanting to change aspect of the Task was to simply discard the original Task and recreate all elements of the Task from scratch.

I haven't done sufficient "experiments"  to work out when you can and can't modify, but am now much more cautious ...

Bob Schor

[DianeS]

Hi Bob!

It's interesting that you say that.  My user likes to create his tasks in MAX (which I don't prefer, but there it is).  He wants to create several different tasks in MAX, then merge them into a "Master Task" at run-time.

After trying to work with the MAX tasks directly, I, too, came to the conclusion that it wasn't going to work, because writing to the property nodes appeared to have no effect.

Hence I, too, am now creating an entirely new "master" task from scratch.  I think I might be doing it a bit differently, though, because I create the new task and then try to write to the property nodes.

Maybe what I need to do is store the channel configurations in memory as clusters or some such data object, let the user modify them as needed, and then use them to create the task.

It's a bit messy.  But it might be what's required here.  Thanks for the thought!

Can anyone add some insight as to why writing to the property nodes doesn't work?  I expect Bob would be curious too.

Thanks Bob!

Diane

[DianeS]

I should specify that the task is NOT running when I'm trying to write to the property nodes.  It's merely been created.

[ben64]

I really hope somebody from NI write a white paper on this topic.

I don't know what type of custom scale you are using but I would go with the Map Ranges type. With this type you can set the scale "Map Scales Maximum value" and "Map Scaled Minimum" value properties (The pre-scaled values can also be set).

Ben64

[DianeS]

Hi Ben!

We're using linear scales.  The Map Ranges is an interesting idea...don't know if I can talk my user into that.

I, too, wish that someone from NI would either write a white paper or chime in and tell all of us why the code I showed doesn't work.  It just doesn't make sense to me to allow one to write those properties but then basically ignore the newly written values.  Is JohnP still out there anywhere?  Can he shed some light?

At any rate, in the near term, I will probably read the original task/channel configurations using the property nodes, store their channel configurations in typedef'd clusters, allow the user to modify those clusters at will, then create an entirely new task after all of the modifications have been performed, using the stored cluster values.

At 100-200 channels, I can't claim it's an efficient way to do things...but it should work ok.  I'd be interested to hear better solutions, though!

Bob, is this more-or-less what you were suggesting?  If so, I'd like to attribute the solution to you.

Thanks guys!

Diane

[Bob_Schor]

Not quite.  I tend to use the DAQmx functions to define the Channels.  Here, for example, I'm defining the Channels for a Triaxial Accelerometer, which will use the first three AI channels of a USB-6009, naming the channels respectively X, Y, and Z, setting the range to 0 .. +5 v, and using "Volts" as the (native) Scale.  [I have a similar routine that can also use Custom Scales -- it works the same way, but has the additional step of calling Set Scale to get the Custom Scale that gets wired into Create Channels].

The initial function, "Find Valid Device", interrogates all the Devices on the PC, looking for one that identifies the Device as a USB-6009 and checks the Serial Number to match a specific device that is "wired" to the Accelerometer.  This way, I don't need to know if LabVIEW considers this "Dev1" or "Dev23".  I then use this with the DAQmx Device property to get all the AI physical channels, and pull out the first three.  I create a new Task, which I name "Triaxial Cal", then in the For Loop, I set each of the AI channels, naming them X, Y, and Z, setting their ranges, and specifying Volts as the Scale.  This becomes the Task that I need for setting Timing and doing Reads from this Device.

I originally used a Project-defined Task.  This worked also very nicely, but I discovered I couldn't change (some of) the settings at Run Time.  Took me a few days (and some helpful hints from this Forum) for me to abandon "Project" or "MAX" Task creation and "do it from scratch", as illustrated here.

Bob Schor

P.S. -- I should say that this is meant as a direct response to your question "Is this what you meant, Bob?".  This is how I did it, and it worked for me.  I did not try setting the Channel Properties using Property Nodes -- I have no reason to think this won't work equally as well, but, as I said, I have not compared the two methods.  I, also, am curious when/where/why one should use one method instead of the other, particularly as they seem to be equivalent.

[DianeS]

Thanks Bob...we actually tend to do things very similarly when I'm left entirely to my own devices.  I never use MAX to create tasks, I prefer to create them explicitly in LabVIEW.  My user, however, does use MAX, therefore for this project, that's what I'm working with.

I also use the Device property node to get a list of all the devices, then look for the one I specifically want (I usually put that information into an .ini file...I do like a good ini file).

In this particular case, since I do have to work with tasks already created in MAX, I use the System property node to get a list of all the MAX tasks currently available, and display those on the FP.  The user can then choose which of those tasks he wants to include in the Master task.

At this point, I give him the option to re-configure individual channels within the Master task.  In order to display everything properly for him, I need to know how the channel was configured in the first place.  I obtain the original MAX configuration using the Channel property node.

My original thought was to simply take the user's new configuration and write it back to the channel using the Channel property node, as shown in the code in my first post.  It turns out that this doesn't work.  The values input to the property node are simply ignored.  Why, I have no idea, but they are.  It is this fact that I am attempting to understand.

It also turns out that if one takes those MAX channel configurations and uses them to create an entirely new task as you show below, one still cannot write to the Channel property node after the task has been created in order to change the channel configuration.  All writes to the Channel property node are simply ignored, and the channel retains its original configuration.

Anyway, what I am now doing is just storing all of the channel configurations in a supercluster.  When the user has modified everything to his satisfaction, I will use the configuration clusters to create the Master task the same way you show below.

Does that make sense?  It's a bit wordy.  I'll put some code up later which should clarify things...right now I want to get my current code rewritten and tested.  🙂

[Kevin_Price]

Just a couple thoughts.

1. I'm not *necessarily* alarmed that the property node Reads give values that are a little different than the property node Writes.  This same kind of thing happens regularly when attempting to configure a DAQmx sample rate that isn't mathematically reproducible by the board.  (AI sample rates are restricted to integer divisors of the board's timebase.  Requesting a frequency that cannot be produced with an integer divisor causes DAQmx to substitute an adjacent one that can.  The Read will give you the *actual* frequency used, which often doesn't equal the exact frequency requested.)

  To help diagnose, try Writing a variety of different values.  If the Read value kinda sorta mostly follows the Write, you're probably dealing with some kind of similar quantization or interpolation/extrapolation error.  It may just be a side effect of the particular custom scale and the fact that there are only a small finite number of available board gains for DAQmx to apply.  The suggestion from ben64 may prove helpful here too.

2. If waiting until *all* config params are known before configuring the task works better than modifying a previously-configured-but-not-running task, the problem's probably something different than I suggested above.

-Kevin P

[GiantDeathRobot]

Hi guys,

Taking a quick stab at what Diane is probably seeing... Kevin is on the right track, it looks like you are seeing quantization of voltage range. I'm not sure which device you are using, but most of our devices have a set range of voltages which they can read. (For instance, the 632x/634x devices can do +/- 200 mV, +/- 1 V, +/- 5 V and +/- 10 V ranges.) If you were to request a max voltage of 6 V, the device would set to the 10 V range, since it is the smallest range that contains the requested value. If the default value were 10 V, it would look like the device is not responding to a change, when 10 V would be the result of any value greater than 5 V and less than 10 V. It looks like your device has a +/- 18 V, and you are trying to set it to +/- 17.5, which would be too small a change to shift measurement ranges. I'd try something like changing it to 5V and see if that changes. That should work.