Splitting PFI lines between multiple tasks

[saratoga]

I'm trying to write to two different PFI lines.  I'd rather have them in separate tasks because they'll need to have different length wavefroms, which would make updating them at the same time difficult.  I tried this:

http://pastebin.com/27g8pKhs

Basically I setup two identical tasks, one for line 1 and the other for line2.  The first task works fine, however the second fails with:

A first chance exception of type 'NationalInstruments.DAQmx.DaqException' occurred in NationalInstruments.DAQmx.dll
Additional information: NI Platform Services: The specified resource is reserved. The operation could not be completed as specified.

Task Name: _unnamedTask<3>

Status Code: -50103

This is a little confusing to me.  If I understand correctly, it should be possible to use two different PFI lines at the same time without interfering?  I'm on a PCI-6731.

[JasoNI]

Hi Saratoga,

The issue we are running into is that the two tasks are both trying to access the same sample clock. I have included a LabVIEW example below that has the behavior you are looking for, but runs in a single task. If adapted into .NET, this may work for you.

Generate multiple channels of Digital Output with Different Frequencies and Duty Cycles: https://decibel.ni.com/content/docs/DOC-8010

Regards,

Jason D

Applications Engineer

National Instruments

[saratoga]

I don't think that is the issue.  I can make two tasks uses the same clock source provided one is digital and one is analog.  It would be very strange if somehow only one device could use the same clock actually, then you could not phase lock outputs.  

 I can do what you've done in labview fine, but its not really a solution for me since the two waveforms I want to playback are different lengths.  E.g. if one is 11,000 samples and the other 20000 samples, its difficult to do that.  I was hoping for a way to split the different DIO lines into different tasks so that I could update one without having to deal with the other.  

[fromm8]

Hello Saratoga,

Have you tried a workaround as Jason recommended? I tested some examples in LabVIEW and in those cases the sample clock was the issue. I can generate two different digital output tasks without using the timing VI (on demand) without problems or I could implement a solution like in the example linked above.

Regards

Frank R.

[saratoga]

Hi Frank,

Yes as far as I can understand that labview code I have implemented that solution in text form.  However, its not a solution to the problem I have here because it updates both channels synchronously.

Maybe a more clear example would help explain why I'm having this problem.  I basically want to drive a digital device using 1 DIO line.  At the same time, I want to generate trigger signals for a different device.  These two outputs both need to run continuously, but they'll be updated at different times as external events happen.  For example, a data transfer might be going out over the 1st digital line when suddenly I need to trigger by writing a single bit to the 2nd DO line.  Hence, I'm asking if there is someway to update one DIO line without interrupting a large transfer on the other (which would corrupt my data).  

At this point I'm starting to think it would be easier to just give up on the DIO lines and write 1s and 0s to the analog channel, but it seems hard to believe there is no way to write to two different DIO lines at the same time without changing the state of unrelated pins.

Edit:  For example, if try to edit the example above to write two different buffers sizes like I need to, I get:

" Error -200103 occurred at DAQmx Write (Digital 1D Wfm NChan NSamp).vi:1

Number of samples to write must be the same for every channel."

Which is why I can't use that example code.  

[saratoga]

After a lot of digging, it seems that what I would like to do is indeed impossible because a common FIFO is used for all DIO lines.  Therefore updating the state of one requires updating the state of all lines. 

[fromm8]

I would like to reproduce that behavior, are you working on visual basic or c#?

Frank R.