How do I setup my PCI-DIO-32HS for burst mode with coninuously repeated finited transfers?

[AdrianB]

I have tried many ways of trying to get my application working, and have yet not succeeded, please could someone help.
I have a PCI-DIO-32HS, I configure ports A and B as an output group, and C and D as an input group. Both groups are to communicate with my system using the Burst Mode protocol. How the communication should work (after the relevant config) is as follows:
1. Output a finite set of data (known length) - after which ACK1 should should return to its inactive high state (system is active low). My system now uses this data to generate its own data.
2. My system will then notify the DIO-32HS that it has a data set (known length) ready for transfer by pulling REQ
2 low.
3. The DIO-32HS should then pull ACK2 low until the set length of data has been received and then pull ACK2 high again.
4. A new set of data for output will then be generated, after which the VI should then begin again at point 1.

As far as I can see, this is a case of continuous transfers of finite length. If I set up the DIO-32HS for continuous transfers, the system runs but the ACK signals are not being asserted as required, resulting in a "misalignement" of my data. If I set up for finite transfers I get various errors within my VI, such as Error 10802: The requested amount of data has not yet been acquired.

The only other route that I can think of (that I have avoided) is to repeatedly configure->operate finite transfer->clear. This solution (if it even works) will just slow things down and I would like to avoid it.

Can anyone help?
Thanks,
Adrian

[Tiptop]

Hey Adrian,

As it turns out, the 653x cards (DIO-32HS included) support burst mode pattern generation. However, what you want to do does not seem to fit burst mode pattern generation. The difference comes from wanting the ACK line to be deasserted after a set number of samples. The way that burst mode works, is that ACK is asserted if the 6533 is capable of accepting more data and deasserted if it is not. It is not the responsibility of the 6533 to let the external device know how many samples it has taken. If the external device does not have more samples available, then it should deassert the REQ signal until it has more samples to transfer.

Since this does not seem to fit your application, the best solution would be to see if you can modify your device
to deassert the REQ line if it does not have more data. If this is not possible you could try continuously acquiring and making your REQ signal an input. You could then analyze your data and determine whether or not a sample if valid based on the REQ line.

Another alternative would be to use a counter/timer board or an STC counter from an E Series board to create your REQ signal, if your device is not capable of making one.

One other solution that may work well for you is actually doing continuous acquisition, but clock the data in one finite set at a time. If your device can create a digital trigger, then you could use counters to produce a finite pulse train upon a digital trigger, which is retriggerable in hardware, making it really fast and effective.

Please look here for more information on Digital I/O Applications including handshaking.

Just let us know any thoughts or que
stions on this explanation.

Justin T.
National Instruments

[AdrianB]

Hi Justin
I obviously missed something in reading the 653x manual because I thought that pattern generation is different from Burst Mode, and so I will go and do some reading here.

You said, "The way that burst mode works, is that ACK is asserted if the 6533 is capable of accepting more data and deasserted if it is not." for which I have a few questions:
1. Your explanation is in terms of an input group. Does the same apply for an output group?
2. Assuming a positive response for point 1. Is the device incapable of accepting more data when the input buffer is full (or not been read)? Thereby deasserting ACK2? And would ACK1 be deasserted when the output buffer has been emptied (i.e. incapable of transferring more data)? If this were correct th
en my system could monitor the ACK lines and not have to count.

Unfortunately I have built my system, and so I cannot implement most of your solutions. I think the only one that I could use, would be to count the elements of the array which is known, and deassert REQ myself.

However, at the moment I have come up with a working solution which I will go with, and if necessary refine at a later stage. I implemented the idea that I mentioned in the closing of my initial post of this thread, i.e.:
Continuously [configure->transfer out->transfer in-> clear configuration]

I have one more question. I was looking at all the low level subVIs associated with DIO. "DIO Start" is made up of two other lower level subVIs, namely "Clock Config" and "Buffer Control". Now in the context help for "Buffer Control" the control code has 5 options two are not implemented by LabVIEW (pause and resume which would be nice to be able to use) and the remaining 3 are Start, Reserved and Clear. Is it poss
ible to use "Reserved" which is described as an operation which stops the ongoing input or output and prepares for the next operation?

Thanks for the help,
Adrian

[Tiptop]

Hey Adrian,

1.) Yes. Take a look at the following KnowledgeBase for more information on the ACK and REQ lines.
2.) You�ve got it! If you can monitor the lines, that would be a great solution.

If you are looking at how you could use the reserve control code. Look at this example.

Best regards,
Justin T.

[AdrianB]

Great. Thanks for the help Justin. I will get back to you if I have any more problems.

Adrian

[Raminta]

"burst mode pattern generation"   ---  is there a difference between this and "regular" burst mode ?  I have an application in which I need to ~continuously~  output  multiple streams of data, where each 'stream of 32-bit values' is output using the burst mode protocol. 

For example, suppose I have 10 separate arrays of data. Each array contains 100 integers. My programs needs to continuosly output array1, followed by array2, ...followed by array5, then back to 1 through 5 again, over and over and over. Each individual array of 100 integers is output using burst protocol.  I was thinking of just calling DIG_BLOCK_OUT() in an infinite while loop, and each iteration of the while loop outputs a single array with a single call to DIG_BLOCK_OUT().  So pseudocode might look as follows:

while (forever)

{

     call DIG_BLOCK_OUT() ;   // call for either array1, 2, 3 , 4 or 5

}

But is there a different way  other than what I have above ?

Thanks in adance !

[Kenn_N]

Hey Raminta,

Please refer to this duplicate post in the future.

Regards,

[Raminta]

OK, I will look for the answer in the post you referenced.