Starting analog read corrupts analog write waveform

[dacad]

I have come across an odd condition that can occur if I am running a diagnostic routine on my system.  My diagnostic routine is basically four while loops, each containing code to control specific items in the system hardware. Two of the items are DIO's and always work no problem.

(Am running LV 2013 on Win 7 with a PCI-6014 daq)

Another contains an analog read using AI8 and the last contains an analog write on AO0.

When I run the analog write task, I am feeding in a waveform that essentially pwm's the output.  By itself it works fine.  The only parameter I edit for the waveform generation is the total duration in seconds.  I set at two seconds and I get the modulated output for 2 seconds.

The problem occurs when I try to do this and read the analog input (a simple voltage in from a pressure transducer) at the same time.

If I start the read task while the write task is running, the modulation goes away and the signal goes high and stays there, not shutting off until I force it.   If I have the read task already running (in a loop remember so I can monitor pressure)  the write task acts even more wiggy.  When I start the task it runs for maybe 100-200 ms with the modulated signal and stops.  On about the fourth start, the signal goes straight to high again and stays there until forced off.

So, is there some kind of limitation on this older hardware on reading and writing (at least a waveform) at the same time?

The write task was orginally created in front of the loop and I tried creating it in daqmx and using that but it made no diffference.  I use a daqmx timing vi to set the sample clock rate based on the same waveform with a setting of finite samples.

Any thoughts are appreciated.  This isn't stopping me from going forward but I would like to know why it's acting the way it is.

Thanks....

[josborne]

Hmmm.  Interesting problem.

I think you definitely need to find an answer to your question of whether or not you can run 2 tasks (AI & AO) simultaneously on that device.  I can't anwer that question myself.  But if you have programmed your code properly, LabVIEW will tell you if its not possible.  LabVIEW should fire an error if its not possible.  So I am curious:  Are you wiring through all your error clusters properly and checking the state of the DAQ tasks repeatedly in your loops?  I often find that in cases like this, an error is actually being generated but its not being caught by the code. 

[josborne]

Also, as a simple test you could try running some of the examples that come with LabVIEW regarding "simultaneous AI & AO".  Here is one:

http://zone.ni.com/devzone/cda/epd/p/id/1527

That might help you debug a bit.

[dacad]

Yea,  probably not doing the best job of capturing errors though I don't clear errors and usually an error will cause stuff downstream to act wiggy.

Will try to do some error checks and also likely write a super simple vi to replicate the error that I could post.

Thanks.....

[dacad]

As I have not got this figured out yet, I am posting the guilty code in hopes someone might shed some light on what is causing the issue.  Code is pretty generic in nature with only one sub vi (also attached) and a couple simple tasks for reading the analog-in.

This is on LV 2013 on a win-7 32 bit system using a PCI-6014 daq.  Analog read tasks are both on AI8. One task is configured to read the straight voltage from the transducer (0-10vdc) and the other uses a custom scale to convert to pressure.  Either one causes the conflict.

Pressing the button to start the motor run works as intended by itself.  Default values for waveform are correct for my application though total pulse time (4 seconds) can be adjusted without consequence. (Note, waveform output controls an isolated SSR that contrls the higher level voltage)

Running either option on the read pressure routine causes the analog out for the motor to wig out.  Stops pulsing and goes to a straight high condition.  If it is on first, starting the motor causes just a little blip of output for 4 - 5 clicks then eventually just sets the AO to high as well.  Continued clicking of the start eventually returns it to blip mode but not to the regular waveform that it is configured for.

I have removed all un-related code from the routine that exhibits this behavior.  I returned the analog out to creating a task in the vi as was the original approach used. I had tried a preconfigured task in MAX but it made no difference.

Small loop inside of motor state is to allow minor adjustments in power supply voltage while motor is running.  This has not even come into play at this point.

If anyone can point out the error in my ways, I would much appreciate it.  I know the power supply vi is not the most robust and I will end up changing that to something better that uses the dll supplied by the mfg.  Current code is legacy material that I inherited.  Everything else though looks on the up and up from my persepctive.

Thanks for any insight........

(just had a thought, if the ground between the two drive voltages is made common, could that impact things ?  will have to see what the internal grounding connection on the daq is)

[josborne]

I still suspect it is "wiggy" because its genetrating an error.  (Like the word wiggy by the way!)

I personally think you should be checking that small sub-loop for errors as suggested below.  Try it out.

[josborne]

Actually, after I look at that code I suggested, you will probably need to add some logic to allow the top loop to terminate the bottom one if an error ocurrs.  Try this maybe:

 

[josborne]

I can't seem to attach a VI.  So I show the image instead:

[josborne]

Attached

[dacad]

What type of error were you receiving ?   Added all the error control and this is what I got. Note though that this is generated from the task in the bottom loop.

I was getting this error previously but though I cleared it up when I removed a utility that kept the screen saver from activating. That had seemed to stop it.

So now it comes back when I try to run both the analog in and analog out tasks at the same time.

So, options for what is causing this:

1) PCI-6014 isn't capable of running the two tasks simultaneously

2) Win 7 is crap

3) New Dell computer has slow bus speed

4) Problem with code

5) Other

I really do not believe that it is 1 or 4 since I can run the exact same code (did it this afternoon) on a Win xp system w/ LV 2011 with exact same hardware and received no errors.  Could run both tasks side by side and both functioned exactly as they are supposed to.

I could try a USB daq but re-doing the wiring is a real pain.  I am hardwired through an expansion card to the 6014.  Could put a PCI-6221 in the system with the problem but that is a little painful as well and since the 6014 works perfectly on the win xp system, I really don't think it is a daq issue.

Any other thoughts are appreciated as this is a bit frustrating when something works and then simply by updating computers, it stops working.