Writing to DAQmx Channel property nodes does not update channel values

[johnsold]

Slightly off topic.  Many external instruments such as GPIB devices take a substantial amount of time to change certain parameters. It might be interesting to try a delay between writing and reading to see if that makes a difference.

Lynn

[DianeS]

Thanks for chiming in, guys!

Lynn, a time delay doesn't make a difference.  The way I originally discovered this problem was that I wrote to some property nodes to change some settings for one channel, then called up another channel and looked at it, then went and poured a cup of coffee, then came back and called up the configuration for the channel I'd changed.  Reading from the property node returned the original configured value, not the changed value.  I thought, "Huh?"  So that's when I scribbled up the code I whose image I posted.

Also, changing the set value from 18 (or so) down to 5 also has no effect...when I read the "AI max" property back, it returns 18.  So Kevin and William's suggestion isn't it, either.

The impression I am getting is that once you create a task and add channels to it, those channel configurations are set in stone and cannot be changed via property nodes.

I'll try to get some example code out later today or tomorrow.  I really appreciate everyone's putting their brainpower on this!  Thanks everyone!!

[Kevin_Price]

I've never run into the symptom you're seeing so I'm trying to figure out what might be different.  I've changed DAQmx properties before starting a task many times and it behaves very straightforwardly -- the last value written wins.  So, in search of what might be different, here's my approach:  I pretty much always start by wiring in my physical channel names to "DAQmx Create Virtual Channel.vi".  I don't typically use "Create Task" because it wants me to wire predefined MAX / project virtual channels, and I don't ever define any.  I also don't define tasks or virtual channels in MAX or LV projects.  (Mostly just a habit from learning DAQ long before such features were supported.)

Ok, I just went back and reread the thread more thoroughly.  I see that you're starting with a customer's MAX tasks and trying to change properties.  That sounds a lot like what Bob_Schor was dealing with recently.  Dunno all the ins and outs of the restrictions, but it appears that having a task (and maybe also channels?) defined at a global scope like MAX or a LV project will lock up certain config parameters so they can't be overridden at code execution time.

-Kevin P

[Bob_Schor]

Diane,

     Regarding not being able to programmatically change a Channel Configuration that has already been defined and assigned to a Task in MAX, this is basically the problem that I beat my head against for a day or two (except I was using Project-created Tasks).

     The "catch" is that you have a limited amount of "freedom" to programmatically modify a pre-defined Task.  The "solution" (for you) is to "cheat" -- allow the User to select the Task, Channels, etc. from the MAX-defined choices, then ignore what was chosen and Build Your Own.  Start by defining your own Task.  Configure it with the relevant details from the MAX Task (but give it a different name!).  Similarly, when you start with the Channels, extract the Channel Properties you want and build them into your (private) Task.  I'll wager my standard amount (one thin dime) that this will work for you.

Bob Schor

P.S. -- I thought I posted this last night at 6-something, but didn't notice (as I ran out the door) that it didn't "take".  So I'm trying again ...

[GiantDeathRobot · Accepted solution]

I do have to say, I'm still curious what the device is. I'm not coming up with one off the top of my head that has an 18 V range on it.

One other thing I wanted to double check. Are you changing both the Max and Min? Because the larger of the two is what will dictate the range. (I was setting only the Max, and seeing the same behavior you described until I sent the negative of it to Min.)

[Ben]

I think it was Kevin that taught me I  could set up multiple DAQmx tasks with different channels sets and sample rates and all would be well as long I only start one at a time. Using two tasks for example would let me switch from one sample rate to another by stopping the first and starting the second.

Additionally, I have seen errors in setting for a task only show up when I try to start the task.

So...

I am suspecting some of the setting are only used when the task is started. After that they can not be changed without starting and then restarting the task.

Ben

[DianeS]

Hi guys!

I think William has hit upon it.  I was only changing the maximum.  I had written some test code to post and was fooling around with it, and I noticed that sometimes the new values updated and sometimes they didn't.  (William, I apply a custom scale, which accounts for the funny voltage range.)  Mind you, this was using a task created from scratch in LabVIEW, not a task created with MAX.  I agree with Bob that MAX tasks have some peculiarities about when writing to the channel property node works and when it doesn't.

Bob, part of what puzzled me was that after your first post, I was doing exactly as you suggested -- using property nodes to read in the configuration of each of the channels in the MAX task, then using "Create virtual channel" to essentially duplicate each channel configuration in an entirely new task.  I was seeing the same behavior, but as William pointed out, I was only changing the max value and not both the max and min.

Ben, you're probably right, except that I hadn't started the task.  I'd only created it, as I said earlier.

I think that my best bet is to simply re-create the MAX channels in LabVIEW...which I have to do anyway, as I haven't yet come across a graceful way to merge MAX tasks into a single Master task.

I'm very familiar with task creation / configuration / etc. in LabVIEW.  I am not familiar with task creation / configuration in MAX, because I never use MAX to create my tasks.  I always create them in LabVIEW, using "Create Virtual Channel".  However, my client likes to use MAX, so MAX it is!

And after all that, my client decided he wasn't really interested in being able to change channel configurations at run-time anyway.  So I dropped the feature.  But at least I learned something.

I'm going to give William the solution, unless I can also give it to Bob?  It really was a team effort.  🙂

Thanks guys!

Diane

[Ricky77]

I found this old thread after experiencing the same issue and, after much effort, think I may have an answer and solution. It seems that when using a custom scale for a channel, the min/max are set based on the min/max scaled values and the channel min/max values (e.g., ai.max & ai.min) cannot be updated. I found this through trial and error, as I couldn't find this documented anywhere. In the example below, I set the scaled max value and then read back the channel max immediately afterwards. This confirmed that the channel max value tracks and is tied to the scaled max value and resolved my issue without having to destroy and recreate the task.

Hope it helps somebody out there as I just spent more time than I would have liked looking into this. Good luck!