Looping Digital Output from binary data file

[Jerry Wu]

Hi Laura,

I've come up with a working solution by breaking up the total file into multiple buffers and then looping through these smaller buffers sequentially. One thing I have observed though is that running the same program using DAQmx seems more sensitive to CPU load than the version of the program using Traditional functions. The simple action of opening up Windows Explorer will create too large of a delay between data send (probably when it switches from one DAQmxWrite function to another). On the peripheral, there is a logic that shuts off the operation when a FIFO underflow occurs. If I don't touch that computer which is running the program, then it seems to be fine. Is there any way to make my program less sensitive to CPU load?

Thanks for your help,

~Jerry Wu

[Laura F.]

Hi Jerry,

The only thing that I know of is to increase the priority of your application using the task manager, or to optimize the size of data you are writing with the DAQmxWrite function.  You may find that a certain size write works best with your application, depending on how fast you are writing the data, and particulars of your system. 

Regards,
Laura

[Larry X]

Hi Laura,

I'm in a situation similar to Jerry -- I'm trying to write a DAQmx version of our Traditional NIDAQ code that reads and writes to our external device via a 6533.  We use PCLK2 (in the old terminology) for the clock line.  I've looked at the NI sample code ContWriteDigChan-Burst.c and ContReadDigChanBurst.c, and in both cases it calls DAQmxCfgSampClkTiming followed by DAQmxCfgBurstHandshakingTimingExportClock.  But this is what you told Jerry not to do.  The sample code doesn't use DAQmxExportSignal at all.

What I'm basically trying to do is to export the internal 10 MHz reference clock for burst mode, level-ACK handshaking.  It's not clear how relevant the sample code is in this case.  Also, I'm having trouble following the renamed control lines on the 6533.  It used to be that PCLK2 was line 1 on port 4 in output mode (page 2-4 in Using Your 653X, 2001 edition); do I understand correctly that this is now port  5, line 3 (PFI5) in DAQmx?  i.e. are the former port 4 output lines 0,1,2,3 equivalent to port 5 lines 2,3,0,1 (PFI 4,5,6,7) respectively in DAQmx?

One twist is that in our Traditional code, rather than calling DIG_Block_In to read data, we used calls to DIG_Block_Check to return the number of words remaining in the input buffer, and then we copied directly from the buffer into our data structures, using the current and previous values of "words remaining" to determine where and how much to read.  At the time, we were told by NI to use Set_DAQ_Device_Info to turn off ND_LINK_COMPLETE_INTERRUPTS in order for this scheme to work.  Is there an equivalent to this method in DAQmx, or do we have to use the DAQmxReadDigitalXXX functions?

Thanks,

Larry

[Laura F.]

Hi Larry,

When I told Jerry not to use those two functions together, I didn't realize he was communicating with an external device.  Since this is what you are doing, I think it is fine to use what is in the example code. 

PCLK2 (terminal 6) is now PFI5 in NI-DAQmx.  You are correct about the renamed lines.  The old Port 4 output lines (PCLK1 and 2, and ACK 1 and 2) are now PFI 4, 5, 6, and 7.

You can use DAQmxGetReadAvailSampPerChan to find out how many samples are available before you read them, which I think is along the same lines of what you were doing before.  Then, you would only call the read function once the appropriate number of samples were acquired.

Let us know if you have additional questions.

Regards,
Laura

[Jerry Wu]

Hi Laura,

After fixing the problem with looping the input data file, I'm still seeing what appears to be errors in transmission. Since I have two NI-DAQ cards (both DIO-32-HS), I configured one card to transmit from an input file and another DAQ card (on another computer) to receive data and write to a file. The input file that I am using contains incrementing data going from "00" to "FF" and looping. I've found that sometimes a sample or two are dropped when I examined the output file, and other times a sample is repeated.

Other times, a sample "F6F7" is stuck and printed for 50+ times.

E4E5E6E7 E8E9EAEB ECEDEEEF F0F1F2F3

F2F3F2F3 F2F3F4F5 F4F5F4F5 F4F5F4F5

F6F7F6F7 F6F7F6F7 F6F7F6F7 F6F7F6F7

F6F7F6F7 F6F7F6F7 F6F7F6F7 F6F7F6F7

... so on

then it does go on with the pattern:

F6F7F8F9 ... so on

I've configured both the sender and receiver with bursthandshaking with similar parameters.

Any clue on what's wrong?

Thanks,

~Jerry Wu 

[Laura F.]

Hi Jerry,

I don't have a very good idea of what might be going wrong.  What rate are you using for this operation?  Can you give more information about how you are configuring this operation?

Will you be eventually using burst mode to communicate with a different device?

Regards,
Laura

[Jerry Wu]

Hi Laura,

The cards are set up to send and receive 16-bit samples at 20 MHz delivered/received on the rising edge. Burst handshaking is set up with continuous samples, active high clock, pause when high, ready active high on both sides. The sample clock is exported/imported on PFI5. The sending buffer cycles through a set of buffers each 1.2 MB (about 0.6 Msamples). (Number of buffers allocated depends on the input file size). The output buffer is one large buffer 12 MB (6 Msamples). After the buffer is filled using DAQmxGetReadAvailSampPerChan function to check, the buffer is written to an output file.

Thanks,

~Jerry Wu

[Laura F.]

Hi Jerry,

All of your settings sound good to me.  I am going to look into this issue further and get back with you shortly.

Regards,
Laura

[Laura F.]

Hi Jerry,

Are you changing the default terminals for the pause digitial level trigger and the ready for transfer event for one of the devices?  In my research, I realized both devices cannot use the same terminals because they will not get the proper signals for when the data is ready to be transferred.  For example, for timing engine 0, the default pause terminal is PFI2 and ready is PFI6.  Then on your other device you should set up the pause terminal to be PFI6 and ready to be PFI2.  You can use DAQmxSetExportedRdyForXferEventOutputTerm and DAQmxSetDigLvlPauseTrigSrc to set non-default terminals for one device. 

I do believe you are seeing the behavior you would see if these signals were not properly communicating.  Your device can perform continuous handshaking input slightly faster than output, so you would see repeated samples sometimes.  You can see the benchmarks in the specifications document. 

Please try making the changes I suggested above and let us know if it helps.

Regards,
Laura

[Jerry Wu]

Hi Laura,

I can't seem to set the Pause Trigger source to be PFI6.

Status Code: -89136
DAQmx Error: Specified route cannot be satisfied, because the hardware does not
support it.
Property: DAQmx_DigLvl_PauseTrig_Src
Requested Value: /Dev1/PFI6
Suggested Values: PFI3, PFI7, RTSI0, RTSI1, RTSI2, RTSI3, RTSI4, RTSI5, RTSI6

Task Name: _unnamedTask<0>

Do I need to use ConnectTerm to solve this problem?

Thanks,

~Jerry Wu