Error -200489 says: Specified channel cannot be added to the task, because a channel with the same name is already in the task.
You say that the names where already defined in the project so you can't use DAQmx Create Channels.vi. Try pulling down the DAQmx Channel property node (in the second snippet) and add Analog Input Custom Scale Name (under ActiveChans, replace Physical Channel Name with it) and feed it the newly created custom scale.
Got it! [Ben -- I'm not sure I understand your last suggestion, but maybe it is what I'm about to show ...].
There are two pieces to the story. First, following up a remark I think Ben made, I realized that I might be "illegally" modifying a Task after it had been used. So I use the Task once to get "unscaled" data for Calibration, get the Calibration factors, then re-define the Task with Custom Scales.
There are a number of Key Points which I'll make "up front" -- I'm not 100% certain that all are necessary, but suspect that they might be (at least in my hands).
Here's the over-all test routine. I've "cheated" and manually entered into Triax Params a set of Calibration values from an earlier run. The first two VIs get the Unscaled data to use for Calibration, then the Task is cleared. The Triax Params are used in the next VI to set the scale, and a final sample is acquired, which should be scaled.
Here is the Set g Scale VI. Note that it gets a "fresh" Task Constant from the Project to build for its own use.
In my earlier version, I used a Function, Create Scale, but I'm not sure it did what I thought it should do. Here I just use a Scale Property Node and "fill in the same blanks" as the function.
Oops. Something really strange is going on. I was so focused on the code running without errors and with getting its calibration "set" that I didn't notice that when I set the Scale, it seemed to "stick" so that running the code again (without restarting LabVIEW) did not run with unscaled code. Indeed, both Pre and Post Sample values were the same -- either both sets seemed to use Scaled channels, or both used Unscaled channels.
Close, but no seegar ... (who remembers Pogo?).
I didn't put all the details but this is what I was thinking of.
This works for me using an USB-6001 (units from custom scale must be set).
I wonder whether the persistence of the scaling assignment relates to the fact that the task is defined in the project. Not sure whether that scaling assignment would be saved with the task if you saved the project after running the code that does the scaling assignment. I suspect it would *not* be saved if the project-based task was defined without scaling, you then ran the code to assign it, and then shutdown the project *without saving* it.
All of that to say that I tend to agree with Ben and have long been in the habit of creating all my tasks from scratch on the block diagram. I kinda suspect your most recent attempt would have worked expectedly if you were creating your task from scratch in code at run time rather than pre-defining it with project scope at development time. In that mode though, the scaling assignment would have task scope and would need to be redone on every program run.
So, in the end, I'd be inclined to capture the raw voltages, apply the calibration scaling parameters using normal math operations, then store both raw and scaled values (as well as a header with the cal params).
It's kinda seat-of-the-pants in the presence of the fancier features offered in DAQmx, but consider the debug time you've just put in. It's like those billboards on the highway, "If you lived here, you'd be home now."
I think we are (independently) converging to the same solution. It appears to me, looking at my, Kevin's and Ben's code, that for most of the DAQmx functions that NI provides, there is also a DAQmx Property Node that does a lot of the same things (Create Channel vs Channel Property, Create Scale vs Scale Property, etc. I also just got rid of the Task inside the Project and tried some (pretty crude, but effective) code that did everything from scratch. I haven't yet had a chance to clean things up enough to run everything together, but it is looking more promising -- there may be a Light at the End of this Tunnel. I should know when I come back to work tomorrow (I'll fix up the code at home).
P.S. -- time to hand out some Kudos ...
And while I am waiting for an update I will rant a bit and tell a sea story.
While the investigation to learn how to use the DAQmx scaling may be an interesting achedemic question, I will often urge my customers to do the scaling explicitly in LV. This allows us to see the values both in scaled and unscaled form and will also make tasks like "Adsting the calibration live" trivial.
I hadn't seen this earlier -- I'm doing a Kudo run (as opposed to a Cootie run), and (being an academic) was "determined to understand this", but also realize that "explicit scaling" would certainly have been quicker, easier, etc.
OK, I've got it figured out, and (as is often the case,) was "hoist on my own Petard".
I've often mentioned the excellent NI White Paper on DAQmx that you can find by search for "Learn 10 Functions in NI-DAQmx". What I did not realize was the importance of the "Create Task" function, which I had not been using. Instead, I'd taken the (convenient) "short-cut" of defining the Task in MAX or in my Project.
What I failed to realize (and have not yet found documentation that states this explicitly) is that certain DAQmx Task Attributes, in particular the presence or absence of a Custom User Scale for a Channel, cannot be changed programmatically once it is defined for a Task. My application required sampling Volts during the Calibration process, and then using the Calibration to set a Custom Scale so that subsequent readings would be in Custom Units.
Here's what I did to fix my code so that it does what I want it to do:
During this process, I noticed that there appear, in some instances, to be two methods for setting DAQmx properties. One is to use a DAQmx Function, such as "Create Scale", while the other is to populate an equivalent Property Node (such as a Scale Property Node). Other than aesthetics, is there a reason to use one rather than the other?
I'm going to mark this as the "Solution", although I was "nudged" in this direction by several of the responders (though I often saw the suggestion just after I had stumbled/bumbled to the same conclusion in my little test codes). Thanks for your help and patience.