DIO with PCI-6534

[Chris Houlberg]

I am attempting to use a PCI-6534 to continuously stream data out of a port and into another port.  I am having trouble figuring out how to control the data flow.  The DAQmx commands I am using are as follows:

To Configure the Output Data Task I execute the following:

DAQmxCreateTask("OutputTask", &hOutput)

DAQmxCreateDOChan(hOutput, "Dev0/Port0", "OutputPort", DAQmx_Val_ChanForAllLines)

DAQmxCfgSampClkTiming(hOutput, "/Dev0/Dig0/SampleClockTimebase", IO_RATE, DAQmx_Val_Rising, DAQmx_Val_ContSamps, OUTPUT_BUFFER_SIZE)

DAQmxExportSignal(hOutput, DAQmx_Val_SampleClock, "/Dev0/PFI6")

DAQmxCfgOutputBuffer(hOutput, OUTPUT_BUFFER_SIZE)

To Start the Output Data Task I execute the following:

DAQmxWriteDigitalU8(hOutput, BLOCK_SIZE, 0, 1.0, DAQmx_Val_GroupByChannel, cOutputBuffer, &lSamplesWritten, NULL)

DAQmxStartTask(hOutput)

To Continue the Output Data Task I repeatedly execute the following:

DAQmxGetDODataXferReqCond(hOutput, "OutputPort", &lXferCondition)

if(lXferCondition == DAQmx_Val_OnBrdMemHalfFullOrLess)

{

DAQmxWriteDigitalU8(hOutput, dwOutput, 0, 1.0, DAQmx_Val_GroupByChannel, cOutputBuffer, &lSamplesWritten, NULL)

            Put new data into cOutputBuffer for next DAQmxWriteDigitalU8()

}

To Configure the Input Data Task I execute the following:

DAQmxCreateTask("InputTask", &hInput)

DAQmxCreateDIChan(hInput, "Dev0/Port2", "InputPort", DAQmx_Val_ChanForAllLines)

DAQmxCfgSampClkTiming(hInput, "/Dev0/PFI3", IO_RATE, DAQmx_Val_Rising, DAQmx_Val_ContSamps, INPUT_BUFFER_SIZE)

To Start the Input Data Task I execute the following:

DAQmxStartTask(hInput)

To Continue the Input Data Task I repeatedly execute the following:

DAQmxGetDIDataXferReqCond(hInput, "InputPort", &lXferCondition)

if(lXferCondition == DAQmx_Val_OnBrdMemNotEmpty)

{

            DAQmxReadDigitalU8(hInput, DAQmx_Val_Auto, 1.0, DAQmx_Val_GroupByChannel, cInputBuffer, BLOCK_SIZE, &lInput, NULL)

            Transfer data from cInputBuffer and save for next DAQmxReadDigitalU8()

}

I am getting errors indicating the specified property in the DAQmxGetDODataXferReqCond() function and the DAQmxGetDIDataXferReqCond() are not supported.  I am at a loss on how to correct this.  Any help is much appreciated.

[Raajit_Lall]

Hello Chris,

Correct me if I am wrong but it seems like you are trying to regenerate the data on the output port over and over again. If that is the case a better way of doing this would be to actually use the regeneration mode for this board.

What you can actually do it use the Regeneration Mode property node if you are indeed trying to regenerate. You can get/set/reset this property using:

  DAQmxGetWriteRegenMode

  DAQmxSetWriteRegenMode

  DAQmxResetWriteRegenMode

This way you can actually keep regenerating the data again and again instead of using the functions that you are right now. Please let us know if this is actually what you want to do and if this will help you out. If not, we can come up with something else.

This is documented in the NI-DAQmx C Reference Help.

Regards,

Raajit L

Application Engineer

National Instruments

Message Edited by Raajit L on 02-14-2007 06:59 PM

[Chris Houlberg]

Thank you for your response.  I am not trying to regenerate the data over and over.  I load new data into the cOutputBuffer before I write it out to the PCI-6534.  I do this in reverse for reading the data from the PCI-6534.  I read the data from the PCI-6534 into the cInputBuffer and then transfer the read data to a location where it is permanently saved.  Please let me know if there is a better way of doing this.

Also, currently the error I am getting is the specified property is not supported.  I believe this is the lXferCondition property associated with the functions DAQmxGetDODataXferReqCond() and DAQmxGetDIDataXferReqCond().  Any help here will be much appreciated too.

Again, thanks for your reply.

[Raajit_Lall]

Hello Chris,

The board should support that property. Do you have an error code that you could provide us?

These are the following values that you can use with this property.

Valid values

DAQmx_Val_OnBrdMemEmpty	10235	Transfer data to the device only when there is no data in the onboard memory of the device.
DAQmx_Val_OnBrdMemHalfFullOrLess	10239	Transfer data to the device any time the onboard memory is less than half full.
DAQmx_Val_OnBrdMemNotFull	10242	Transfer data to the device any time the onboard memory of the device is not full.

You can get/set/reset this property using:

  DAQmxGetDODataXferReqCond 
  DAQmxSetDODataXferReqCond 
  DAQmxResetDODataXferReqCond

Here is a link to another discussion forum where they discuss how to use this property for the 6534 board.

 How to use the PCI-6534 onboard memory ?

Although some of the posts on that forum are in LabVIEW, similar functions are used in C and LabWindows as well. Please let us know if this still does not work out.

Best Regards,

Raajit L | Applications Engineer | National Instruments

Message Edited by Raajit L on 02-19-2007 12:32 AM

[Chris Houlberg]

Raajit,

I had read that other discussion before; however, after re-reading it I thought maybe my problem is that I just did not set up the transfer condition before getting the status.  To test this I changed the configuration of the ports to the following leaving the rest of the code unchanged:

To Configure the Output Data Task I execute the following:

DAQmxCreateTask("OutputTask", &hOutput)

DAQmxCreateDOChan(hOutput, "Dev0/Port0", "OutputPort", DAQmx_Val_ChanForAllLines)

DAQmxCfgSampClkTiming(hOutput, "/Dev0/Dig0/SampleClockTimebase", IO_RATE, DAQmx_Val_Rising, DAQmx_Val_ContSamps, OUTPUT_BUFFER_SIZE)

DAQmxExportSignal(hOutput, DAQmx_Val_SampleClock, "/Dev0/PFI6")

DAQmxCfgOutputBuffer(hOutput, OUTPUT_BUFFER_SIZE)
DAQmxSetDOXferReqCond(hOutput, "OutputPort", DAQmx_Val_OnBrdMemHalfFullOrLess)

To Configure the Input Data Task I execute the following:

DAQmxCreateTask("InputTask", &hInput)

DAQmxCreateDIChan(hInput, "Dev0/Port2", "InputPort", DAQmx_Val_ChanForAllLines)

DAQmxCfgSampClkTiming(hInput, "/Dev0/PFI3", IO_RATE, DAQmx_Val_Rising, DAQmx_Val_ContSamps, INPUT_BUFFER_SIZE)
DAQmxSetDIXferReqCond(hInput, "InputPort", DAQmx_Val_OnBrdMemNotEmpty)

Now I get error messages for the DAQmxSetDOXferReqCond() and DAQmxSetDIXferReqCond() commands.  They are they following:

For the DAQmxSetDOXferReqCond() command:

DAQmx Error: Specified property is not supported by the device or is not applicable to the task.

Property: DAQmx_DO_DataXferReqCond

Channel Name: OutputPort

Task Name: OutputTask

Status Code: -200452

For the DAQmxSetDIXferReqCond() command:

DAQmx Error: Specified property is not supported by the device or is not applicable to the task.

Property: DAQmx_DI_DataXferReqCond

Channel Name: InputPort

Task Name: InputTask

Status Code: -200452

Unlike the other discussion, I did set up the timing for a continuous transfer of data by using DAQmx_Val_ContSamps yet I get the same error.  It seems that the DAQmx Set and Get XferReqCond commands just do not support the PCI-6534 boards.  Either that or the above method of configuring the boards is incorrect.  I would have thought that there would be an example somewhere that would outline how to continuously output and input non-repeating data using the DAQmx commands but I could find none.  What am I doing wrong?

Getting desperate,

Chris

[Chris Houlberg]

I tried the suggestion you sent via e-mail and it doesn't work.

I am still having problems with my e-mail so I will also repeat my results on the forum.

What I did was eliminate the commands referring to the transfer condition, the DAQmxSetDODataXferReqCond() and DAQmxGetDODataXferReqCond() commands, and write the data out with without polling for status.  After the data was be output for a few seconds I got the following error:

Error: Write Digital Data

DAQmx Error: Some or all of the samples to write could not be written to the buffer yet.  More space will free up as samples currently in the buffer are generated.

To wait for more space to become available, use a longer write timeout.  To make the space available sooner, increase the sample rate.

Property: DAQmx_Write_RelativeTo

Corresponding Value: DAQmx_Val_CurrWritePos

Property: DAQmx_Write_Offset

Corresponding Value:

Task Name: OutputTask

Status Code: -20092

This is what I expected.  I cannot do what the error comments suggest.  Waiting longer will subject to output to a possible pause in output which will corrupt the process at the other end.  I also cannot change the data rate as the processor at the other end only accepts one data rate.

I need to poll some status word or flag so I know when I can write the next block of data.  My only other solution is to try and write the data out and test for the above error.  If I get the above error retain the block of data and try again until it is accepted.  I am concerned that this will cause some problem in the PCI-6534 that will cause some interruption in the output.  I need a status word or flag to test to get around all these problems.

Surely someone has used this board to do continuous output before.  Surely NI has designed it to do continuous output and someone must have tested it.  How was this done?

Please respond to this e-mail on the forum.  I am not sure when my regular access to e-mail will be up again.

Thank you for your help, I am still desparate for a solution.

[Chris Houlberg]

Raajit,

I have two corrections to make to my last post.  These are typo errors due to interruptions while I was typing my reply and also due to using another computer and its old keyboard.

The first correction to my last reply is the program was run to write the data out without polling for status.  This follows your suggestion which unfortunately did not work.

The second correction is the error code was not -20092, it was -200292.  The keyboard was sticky and I did not proof read what I typed.

Still looking forward to a solution,

Chris

[Raajit_Lall]

Hello Chris,

Thank you for you response. It seems as if the error is occuring because the data is not being written to the buffer fast enough. What we need to do for this is to set up a producer-consumer loop. In the producer loop, which should be running faster than the consumer loop we will set up the chunks of data that you want to write to the buffer and in the consumer loop we will basically do the DAQmx write part of it. The reason we want to do this is so that there is never a case where we are writing something from ther buffer and the buffer is empty.

With regards to the property node that we were using earlier. It is used for handshaking and would probably not work in the Sample Clock timing mode. You could try using burst handshaking instead and see if that works (using the DAQmx timing function).

Regards,

Raajit L

[Chris Houlberg]

Hi Raajit,

The error is occurring because the data is being written too fast for the buffer to take.  I have data available all the time to write out to the buffer.  If I write it out before the buffer has room to accept it I will obviously overrun the buffer.  As the error states: "Some or all of the samples to write could not be written to the buffer yet.  More space will free up as samples currently in the buffer are generated."  indicating the data was available to write to the buffer and I overwrote the buffer.  It also indicates that as time passes more space in the buffer will be available for data.  That is why I need a status flag to test so I know when the buffer has room for the data I want to write.

As for using burst handshaking, as I stated before, I need to output the data continuously.  No interruptions, pauses or missing bits of data can be tolerated.  This should be a simple matter of setting up the PCI-6534 for continuous data out and testing a flag for space available in the buffer to maintain continuous data out.

I am beginning to come to the conclusion that this board is incapable of outputting data continuously.  Either that or the commands I used to set up the output task, channel and timing are incorrect (see above 1st post and following attempted fixes) or the DAQmx commands just do not support continuous data out .  There must be a simple method I am overlooking and someone at National Instruments should be capable of showing me the error of my ways.  I am just about to scrub this approach, return the PCI-6534 boards and SCB-68 breakout boxes to National Instruments and go with another manufacturer's product (or build my own).  We in our division buy National Instruments' products all the time.  This is the first time National Instruments has not been able to support us.

Have you used the DAQmx commands before to output digital data?  Who else at National Instruments might know something about this problem?  Who designed the PCI-6534?  I would like to talk to them.  Who wrote the DAQmx commands that this board should be able to interpret?  Is there any DAQmx command that will allow the testing of a status flag relating to the amount of space available in the buffer that works with the PCI-6534?

I do appreciate the time you have put in on this Raajit; however, I still need answers that work.

Thank you,

Chris

[Chris Houlberg]

Here is some additional information to support my conclusion that the PCI-6534 is not keeping up with the rate at which I am sending data to it.

I increased the clock rate (IO_RATE in the above expressions) from 500KHz to 10MHz and was able to output a 200 MByte file without getting any DAQmx errors.  So I conclude that at 500KHz the error I am getting is indicating that I am overruning the PCI-6534 buffer.  I need a flag to test.

In actual operation, I intend on outputting files between 6 GBytes and 27 GBytes in size.  The output rate must be constant, without interruptions, without gaps, without drop bits and without overruns.

I need a flag to test for space available in the buffer (such as HalfFullOrLess).  I cannot rely on a specific output rate that matches a specific computer capability to maintain the output without DAQmx overrun errors.  This application and the PCI-6534 will be hosted on many different computers which do not all operate at the same speed and which do not all have the same configuration and software running.

Still looking for a solution.

Thanks,

Chris