DAQmx error -51030 when using SCXI

[LV_Pro]

I'm building a test system that is using a PCI-6040E with a SCXI chassis. In the SCXI chassis my customer has a number of boards to do AI, AO and some digital control. I configured DAQmx tasks for the various divisions (one SCXI has TC, another is measuring DC voltages, another is output some DC voltages). I created some "action engines" that perform initializations, placing the "DAQmx task name" into an uninitialized SR, to be used on subsequent calls. What happens is that if I configure each of the DAQmx tasks as a single event "when called" (I can't remember the exact wording) vs HW timed, multiple or continuous) this scheme works, but relatively slowly, pausing a good second in each of the acquisitions sub-vi's, resulting in a 6+ second loop time. If I try any of the other modes I get the -51030 error on the second vi executed (they are in a while loop connected with the error cluster chain). Some of what I'm reading almost sounds like I should open each task, acquired, close task, open next, etc., loop. If so does anyone have any idea of the overhead timewise. This system doesn't need to be terribly fast, but I'm measuring currents that I would like to know within a 100ms if they go way out of limits so I can shut down the offending unit.

As always, thanks in advance for your help

Putnam Monroe

[Sean_C.]

Hello Putnam,

Do you mean error -50103? This error occurs when you are trying to access a resource on the board which is already in use. It sounds to me like you set up a separate task for your DC voltage measurements and your Thermocouple (TC) measurements. These are both Analog Input (AI) tasks, which means they will share the AI circuitry on the DAQ device (ADC, AI Sample Clock, etc...). To avoid this error, you should include the TC and DC channels in the same task.
The reason you were not seeing this error when you configure the tasks "when called" is that one AI task starts and stops before the second AI task is called. In this configuration, the two tasks aren't trying to access the same AI resources simultaneously, so no error is produced.

See the following Knowledge Base for more details about this error. The Related Links might be helpful to you for putting TC and DC measurements into the same task:

http://digital.ni.com/public.nsf/websearch/04BEDD9E9E91ED3486256D180048116D?OpenDocument

Regards,

Sean C.

[LV_Pro]

Good Morning,
Yes I did mean -50103, a little keyboard dyslexia. My problem is that I have created a bunch of tasks to read various channels from a number of SCXI modules, some for T couples, some just voltages and two to output an analog voltage and some digital channels. I've created sub-vi's to write or read from these channels, one each per task, to take advantage of DAQmx's scaling features, etc. When these tasks are configured to perform a single acquisiton "on demand" (I'm not sure of the wording, don't have the machine with the DAQ card/SCXI chassis in front of me), they work, but slowly, going through the loop of 6 sub-vi's in about 6 1/2 sec, giving me one sample per channel every 6 1/2 seconds. This would probably be ok for the acquisition part, but isn't for the controlling of the 4 motors (just a repeated on/off on a operator set time schedule). If I try and configure them for any other method, hw timed, continuous, etc., I get the -50103 error. I guess I'm having a "senior moment" trying to understand how I should be configuring them. I wanted to do it in DAQmx so that my customer, with their LabVIEW I & II classes behind them, could support it, rather than doing it in tradional DAQ calls, but I'm missing something here conceptually. From what I've read I can stick a DAQmx Stop, after every read/write call, it appears from what I've read that this should help, but I was looking for some other's experience in this regard.

Thanks, as always,

Putnam Monroe

[LV_Pro]

Can they be included in the same task if they are on different SCXI modules? I can peel out the various channels after the Acq easily enough, but it seemed when I was configuring the task that it was limited to individual SCXI slots. I could be wrong, can't easily get to the customer's to check it out. I wish that NI would put the capability of telling MAX what the anticipated hw configuration was to allow a preconfiguration. Don't expect it to be able to simulate, like it checking what is really there, but the database of NI boards is there, let those of us that develope away from the HW to do some of the config stuff, before we get to the HW. Then again IVI lets you simulate the actual device, maybe we could have that in MAX/NI-DAQ. It would probably require a DVD to store, or a 1Gb download, but hey how long could it take over dialup?

Thanks Again

Putnam

[LYu]

Hi LV_Pro,

As mentioned in a previous post, to avoid error -50103, you should include all the analog acquisitions into one task, and the analog generations into another task. You can have different analog measurements (e.g. temperature, voltage) in one task. You can either create the task in MAX with multiple channels, or programmatically create the task in LabVIEW (see example attached on adding multiple channels to one task).

If you're configuring and clearing out the task inside the loop, this could be the reason for the slowness. You should create the task first, then loop the DAQmxRead (or DAQmxWrite for generation) VI. Try using the LabVIEW shipping examples for the code structure to perform continuous acquisition.
Help >> Find Examples
Under the "Browse" tab, go to Hardware Input and Output >> DAQmx >> Analog Measurements >> Voltage >>
ContAcq &Graph-IntClk.vi

You should be able to create a task with channels from two different modules. I was able to configure a task acquiring from two different modules in MAX without getting an error. You suggestion regarding simulating HW configuration in MAX is a great one, and the idea has been noted for future driver revisions.

I hope this answers your questions. To further clarify the situation, maybe you can post a screenshot of your code so we can better understand what's happening.

Thanks,
Lesley Y.

[LV_Pro]

Good morning all,
Essentially I have done what LYu is doing, with a "create a channel" for each the "task types" that are on the Analog In. This allows me to have an idea of where in the returned array each group's data will reside and also to perform the appropriate configuration (Thermocouple, current, voltage and frequency measurements) as I create the "groups", they are all, strictly speaking, the same task, but I wasn't able to find a way to easily build the task in MAX, it starts by having you determine which kind of task (Analog in, out, etc.) and then what type (temperature, current, etc.) which precludes having multiple types in the task. You can do this in LabVIEW, as described above. Part of my problem is that without the DAQ hardware installed on the machine that you are using to develop you can't set up any of the settings in MAX and unfortunately time on the target system is really at a premium. On my wish list (for quite a while) is the ability to tell MAX what hardware _WILL_ be installed, and have it let you do the configuration stuff. It has all the data for the supported National Instruments HW in its database. I'm not asking for the ability to simulate the HW, just to be able to do some of the configuration stuff. Many of us develop on systems other than the target one, frequently not being able to get on the target until we are ready to integrate the HW and SW. Oh well, maybe in MAX 5.0 and LabVIEW 9.1 ...

Thanks for all the helpful suggestions,

Putnam Monroe

[Stuart_G]

"On my wish list (for quite a while) is the ability to tell MAX what hardware _WILL_ be installed, and have it let you do the configuration stuff. It has all the data for the supported National Instruments HW in its database. I'm not asking for the ability to simulate the HW, just to be able to do some of the configuration stuff. Many of us develop on systems other than the target one, frequently not being able to get on the target until we are ready to integrate the HW and SW. Oh well, maybe in MAX 5.0 and LabVIEW 9.1 ... "


I don't think you will have to wait nearly that long. Look for an upcoming, soon to be released, version of NI-DAQ. I think you will be pleasantly surprised.

StuartG