Mystery Error -50103

[CoastalMaineBird]

The SOFTWARE section of MAX reports NI-DAQmx 8.9.5

[Dennis_Knutson]

The readme for 9.0.2 says that the 9174 and 9178 were added.

[CoastalMaineBird]

 One or the other is raising the error.  When you combine the channels into one task, then all the channels use that sample clock and there is no resource conflict.

Well, I wish it were that simple.  Although there is no complaint when I add the strain channel into the task, it completely gorches the timing.

I'm running at 5 Hz, when I don't have the strain there, it gives me data at 5 Hz.  When I add the strain channel to the task, the READ function no longer waits on the timer, but gives me data ASAP.  So that results in 50-100 Hz, however fast my program can grab it, scale it, and plot it. 

[RavensFan]

I apologize.  When I saw the screenshot with the two different tasks and sample clocks going on, I said, "Of course, there is the problem".  It is the kind of thing that you see the rookie LabVIEWers do on the forum all the time.

Perhaps your problem isn't as simple as I first thought and involves some intricacies of the compact DAQ modules I am not familiar with.  It is weird that hadding the channel to the task messes up the timing.  But if they are two different tasks there is a conflict error.  What happens if you change the order of the channels so that the strain channel is first and the voltage channels are last?  In that case, does adding the voltage channels to the strain task screw up the timing?

I wonder if there is an error in the simulation code that causes LabVIEW to think the two modules and thus tasks are sharing a timer resource when in real hardware they are not (per Dennis).  I think it would be definitely worthwhile to try to upgrade the DAQmx drivers to the latest version and see what that affects.

[CoastalMaineBird]

What happens if you change the order of the channels so that the strain channel is first and the voltage channels are last?  In that case, does adding the voltage channels to the strain task screw up the timing?

I had thought of that, but it doesn't matter if I do the strain BEFORE the others or AFTER - the timing is still ignored and it reads as fast as possible.

If I disable the VOLTAGE create-channels call (leaving only the single strain channel), the timing is bad.

If I disable the STRAIN create-channel call (leaving the voltage channels), the timing is good.

Here's the current code - the START just starts the single task now.  There is no error reported. 

 

[CoastalMaineBird]

FWIW, MAX has the same trouble.

At 5 Hz, it ought to take 20 seconds to read 100 samples.  Instead, it takes just a blink (maybe 0.1 second). 

[RavensFan]

I see the behavior your talking about with a simulated 9172 chassis and a 9237 module vs. 9201.  The 9237 test panel returns virtually instantly while the 9201 takes about as long as it should.  My system is LV2009f2 with DAQmx 8.9.5.

I have no explanation.  Hopefully an NI person can jump in and try it out.

(Have you tried installing the latest DAQmx yet?)

Message Edited by Ravens Fan on 01-16-2010 06:39 PM

[CoastalMaineBird]

(Have you tried installing the latest DAQmx yet?)

Still waiting to download it.  It's a 3+ hour download, about 17 minutes left...

It's not on the latest Alliance distribution disks... < sigh > 

[CoastalMaineBird]

OK, installing NI-DAQmx 9.0.2 did nothing except bog down the machine.

MAX still shows the thing taking 0.1 second to record 100 samples at 5 Hz.

Changing the chassis to 9178 instead of 9172 did nothing.

Everything about NI-DAQ and MAX is way slower now.

So I spent three hours of download time for nothing.

I guess it's time to hit tech support with this. 

[CoastalMaineBird]

OK, it seems there's no way out of this box.

I thought I would go to a separate task where the strain module is measured on-demand, while the voltage channels were timed.

But no - you can't get there from here.

Leaving off the DAQ MX TIMING call on the strain channel makes it complain that "you must use a sample clock"

Using a sample clock is the original problem where it complains that the resource is already reserved.

Using a property of SAMPLE TIMING TYPE = ON DEMAND tells me that it's not a supported value for this property - I can only use sample clock.