PCI 6561 hardware buffer query

[Test3r]

Hi there,

I'm using LabView 8.5 with the 2Mb/Ch version of the PCI 6561 card. I am using one DIO channel to transmit a token to initialise and synchronise a detector on a board. The interface is digital and I'm using the LVDS clock of the 6561 to drive the board. The detector itself has 16 ADC converters that starts sending back raw data once the detector chip is configured and synchronised. My problem is that I want to access both the output and input buffers in the hardware of the PCI card. By using time stamps I need to note when the token is transmitted by the output so that I can then start looking at the input buffer and process the data from the board. As soon as the board powers up the ADC converters starts churning out data (ie rubbish) so I need to look at the input when synchronisation occurs, so therefore being able to know what bit comes from which ADC. The ADC converters on the board transmit continuously data in a round robin fashion.

I've used the Digital Waveform Editor to produce the token sent to the board. All my inputs/outputs are differential LVDS and I can see the data coming back from the board. Currently my VI uses the NI-SHDIO Express Generation and NI-SHDI Express Acquisition VIs but I suspect I need to use the niSHDIO VIs in order to access the hardware buffers. One problem with these is that the data saved is in the form of a digital waveform. Ideally I would like the data is some binary shape (maybe a 1D/2D array?) which would make manipulation a lot easier.

Any help on this would be greatly appreciated, many thanks in advance.

[JaredW]

You are correct that the Express VIs for HSDIO only return a Digital Waveform. There are two quick things you could do to get binary data without writting a bunch of code.

1) Use the "Digital To Binary" polymorphic VI to convert your Digital Wavefom into a 1D array of integers. This VI can be found in the following LabVIEW Palette: Programming -> Waveform -> Digital Waveform -> Digital Conversions.

2) Since the Express VIs are working for you, you can convert them to code generated subVIs and then modify the code to return to you a 1D array of integers. To convert the Express VI to a subVI, right click on the express VI and select "open block diagram". Be warned that once you do this, you will no longer be able to use the nice Express Configuration page. You can then go inside your new subVI and find the HSDIO VI that reads a buffer from the device. It is a polymorphic VI, so you can change it to read binary rather than DWDT.

[Test3r]

Thank you for the prompt reply!

Following your advice I've been able to convert the waveform into a binary stream and I have converted the two express VIs into normal VIs. The generation and acquisition express VIs are quite similar when you look at them in depth.

When I look deeper I find that the "niSHDIO Read Waveform" VI performs the acquisition of the signal. When I look at it in turn (hoping to access the hardware buffer) I encounter a "Call library function Node" which calls a DLL or a shared library function which is hidden from my view/access. Can I get around this by accessing the DLL/shared function? Because without knowing the DLL or function called, I can't access the hardware buffer and process the data. Alternatively, is there any other VI that allows me to access the hardware buffer(s) directly?

Another problem that I have is that I've place both the signal generation and acquisition inside a while loop. I need to provide a continuous clock (hence looping the generation) but I also need to look at the input for a longer duration (hence looping the acquisition). The problem is that each time the loop enters a new iteration, the acquired signal content is overwritten. If I was able to send my token just once and then maintain the clock, I could loop just the acquisition part or even just run the acquisition over a much longer duration.

Many thanks in advance.

[BeejalS]

Hi

I am not too sure why you want to access the dll because by performing the acquisition you are directly accessing the hardware buffer. However to see library name double click on the 'call library function node'. I have attached an image showing the popup window that appears when you do this. This displays the library name.

With regards to your second question, would you be able to post your code so I can see exactly what you are trying to do?

Best Regards

Beejal

[Test3r]

Hello,

The reason I'm interested in accessing the hardware buffer directly is that I need to see when the synch token is sent to the detector board, so that I can then start collecting the raw data that is coming back from the board. Without this knowledge, I cannot tell which bit in the raw data is coming from which of the 16 ADC converters that is sitting on the board. I suspect that I could very well be on the wrong path here (LabView generally operates on a higher level). However, I am not certain that sending the synch pattern in my code and then immediately looking at the incoming raw data will guarantee that the next bit arriving will be from the 1st ADC, the second bit from the 2nd ADC, etc. My code is currently continuously looping both the generation and acquisition which isn't a very good solution.

I am attaching my program as '6561_HW_Buffer.zip'. The generation express VI is just sending two patterns: 10101, then a pause, and then 10001. The first pattern configures the board, the second is the synch pattern. The raw data only contains the ADC data, the lack of any extra bits to avoid bit slipping means I need to retransmit the synch pattern (10001) every so often at known instances of time. Apart from that I need to maintain and transmit the onboard clock which is driving the detector board. With a steady clock and periodically transmitting the synch pattern, the program should then continuously collect the raw data from the detector board and rely on the time instance when the synch pattern is sent, to maintain synchronisation and make sure that no bit slipping occurs. As I mentioned earlier, the while loop is not an ideal solution but I can't think of another way to transmit the onboard clock, periodically send the synch pattern and continuously collecting the raw ADC data from the detector board.

Any help on this would be grateful appreciated.