I have an issue with numerical data acquisition with an HSDIO board (6542) in a PXI rack.
I generate a numerical partern on 8 bits using the same board (I have also tried with another board) and I want to read them.
I generate the pixel clock and triggers signals that are plugged to STROBE and PFI inputs.
My LV code seems to operate properly when I ask for a Single Numerical record with U32: acq data = gen data.
When I want a Multiple Record 2D U32, only the first record is correct, on the next ones, the data are present but they don't start at the right moment (rising edge of the trig input).
I guess I am missing something with the board configuration but I don't get what.
Here is the diagram: task creation, channel list declaration, clock input specification, trigger (rising edge on PFI3) configuration and number of samples to acquire (32 for this test) and number of records (3). In the event loop there is one event for the start VI, one for the record (acquisition) and the last one to stop.
Here is the result:
record #1 (white) is ok (according to generation not prensented here) with 3 values 0x00, 6 values 0x01 and the reset at 0x00.
Records #2 (red) and #3 (green) are shifted (on the left) by respectively 2 and 4 values. But this shift is totally arbitrary: depending on the number of samples to acquire it varies a lot and I didn't find the pattern.
And yes, the generation is larger (100 values) than the record (32)...
I didn't find any clues in the help or on the net.
Thank in advance for your answer!
Which clock is used by Default? You have set 50MHz frequency, shouldn't there be also a constant by selecting the clock?
Have you tried also to measure at different Frequencies (although 50M should be OK for all clocks).
Actually the 50MHz value is the default one for the HSDIO VI "ni HSDIO configure sample clock".
But I use an external clock, specified by the constant "STROBE" and I physically link one generation channel (with a specific clock) to the STROBE input on the board.
I guess the this clock frequency is not used in the VI, but it is not possible to know since the VI uses a dll call function.
I tried to modify this clock value: it has no effect on the measurement nor on the issue I point out.
I don't know how important is for your project to use the clock configurations that you have chosen, however, there is an example of dynamic generation and acquisition for PXi devices in Labview, could this be useful?
The name of this example is "Dynamic Generation and Acquisition-Demo.vi". Could be found at Help>Find Examples.
Actually, the data I need to acquire come with a specific clock I use as an input to be fully synchronized.
And yes I used the exact example VI that you mention to creat my VI.
I only changed the sampling clock configuration and trigger configuration (external trigger, rising edge). And also the record VI mode (Single record WDT to Single record U32 or Multiple record U32).
As I said in my initial message, with a single record, I got the exact dataset I generate. My issue concerns multiple recording VI and configuration.
Thank you for your help, it is most welcome ! 🙂
you have faced a very interesting problem.
1 may be a naive question (sorry in advance). Is the device acquiring correctly for each channel separately?
In order to check if the error comes not from the program, I would suggest running the program with a PXI clock.
Alternatively, you might try to change the data representation to 2D Wfm.
What do you mean by "each channel"? I generate a signal on 8 bits and read it on the board. All bits are ok, since on the first record all the values generated are good. And they are still good on the following records. Juste at the wrong timing "place".
I tried the 2D WFM: same issue.
But your idea to test with an internal PXI clock in very interesting. I will try as soon as I am back to my lab.
I really think that the trigger confirguration has an issue (in my code, don't think on my board since I tried on 2 different ones, or in the driver).
As I understood, you are generating a signal and by means of wires measuring it with the same device on 3 different channels?
If we leave possible software problems aside, then the problem might happen due to wire length (for example). Then it would be good to check each channel. This might be done by switching the contacts. If previously it was Signal 1 wire was connected to channel 1, Signal wire 2 to channel 2... You connect signal wire 1 to signal channel 2.