Synchronizing data acquisition with NI 9220 and 9234

[LReck]

Okay here are some snippets of what i'm currently doing

The last loop generates a sweeping sinusoidal signal that i output via a NI9263.

I have problems configuring the Binary Counter in that i always get an error similar to the following:

"Error 6 occurred at Copy in niFpgaIPINodeCopyFile.vi:5590001->niFpgaIPINodeCopyFileWithPathLenCheck.vi:6140001->niFpgaXIPINVivadoCopyFromTempFolder.vi->niFpgaXIPINConfPage4.vi"

I mostly keep the settings in Xilinx Property window unchanged. My cRIO is connected via Ethernet

[mcduff]

So first start small. (I may make some errors here, it has been awhile since I did this.)

1. Select one of the DSA modules, “the master,” to export the clock to the backplane. See page 122 of the crio guide you linked earlier. Make sure on the module configuration you check export clock.
2. Make sure you see the node for that clock.
3. Configure the binary counter node. The Xilinx nodes can be tricky to configure, read the help. (They change as the IP gets updated) Another way is to try to make your own counter. Something like below may work in a SCTL.

• Once you get your counter working, start to generate occurrences, every nth count.
• Try to trigger your SAR module to digitizer, start with one, on this occurrence.

Once you get that working, then start to add other pieces, otherwise it will be hard to debug.

mcduff

[LReck]

Okay i went back to starting with only the counter...the rest was taken from a previously working VI that i used to acquire data from two NI9234 where i exported one of the clocks as the master clock for the other DSA module.

The runs just fine the first time i execute this on the FPGA side (although i can't seem to use Read/Write Controls on the RT side to read the counters there). "Reduced Counter" and "occurrences generated" show the same value (the 2nd one +1 because the first loop generates an occurrence after terminating). Now i'm facing the problem that when i try to run this program again, nothing happens except that "occurrences generated" is reset to zero (as intended during initialization)  

[mcduff]

It looks like you can generate occurrences at the correct rate, is that right?

What is the sample clock of the DSA and what divisor are you using?

For troubleshooting:

For now forget about sampling. Can you restart your occurrence loop over and over?

Rather than use the sample pulse method, can you just take data directly from the SAR module?

What version of LabVIEW are you using?

There is some initialization that I should have explained better. The diagram is below. A few notes:

1. A have a LED blink when initializing, not important only feedback.
2. Occurrence loop starts at the beginning.
3. Some resets, clears, sample rate settings, flushes occur in the beginning.
4. GPS can be ignored in beginning.
5. Note that I start the modules after an occurrence, not sure why I started them before, do not remember.
6. Main loop does not start until after occurrence, ensures synchronization.

Initialization sequence before data acquisition occurs

Can you do a simple test like this to see if your occurrences are at the correct rate? You can then do some statistics on the values to see how good it is. (You can change the wait on occurrence order here.)

Occurrence Loop Test

mcduff

[LReck]

The sample clock of my DSA (Module 1) is 13.1072 MHz, the lock of the cRIO is 40 MHz. My Labview version is 2016.

Adding a Reset and Run (among other things) to my RT VI i got it to run while being able to restart it without a hitch. I used a divisor of 32. 

Iterations / Occurrences = 401978345 / (4116269-1)  = 97.6560

40MHz/(13.1072MHz/32) = 97.65625

Not exactly the same but very close. But that is also because i did not exactly stop when receiving a clock-occurrence.

By looking at the data saved in a file i always see either a difference of 97 or 98 ticks between two occurrences. The mean difference is 97.6559 ticks.

Even if i take a divisor of 1024, which should give me exactly 3125 ticks between every occurrence i see a difference of 3124 ticks around every 91st occurrence. 

Also, are you starting your modules only on the occurrence to make sure your group delay is exactly as given in the datasheet?

Do you have another occurrence loop in the main acquisition loop? I'll try acquiring data from the SAR module as the next step.

[mcduff]

You should choose one of the following numbers for your divide by counter (Sorry for not be clear):

Intersection [ Divisors[13107200],  Divisors[40000000] ]
Result
{1, 2, 4, 5, 8, 10, 16, 20, 25, 32, 40, 50, 64, 80, 100, 128, 160, 200, 256, 320, 400, 512, 640, 800, 1280, 1600, 2560, 3200, 6400, 12800}

So 32 should work but 1024 would not. The number needs to be chosen such that the max acquisition rate is not exceeded for your SAR module. (32 implies 409,600 Sa/s)

Having common divisors gets the edges lined up.

Also, are you starting your modules only on the occurrence to make sure your group delay is exactly as given in the datasheet?

Starting them on an occurrence ensures they start at the same time. (Call this a trigger occurrence.) You still need to account for the group delay, and need to delay your SAR modules with a feedback node.

Do you have another occurrence loop in the main acquisition loop? I'll try acquiring data from the SAR module as the next step.

After the trigger occurrence there is one occurrence in the main loop, this is ONLY for the SAR module. The DSA loops run in a separate loop without any occurrences, on its own clock. Look at my earlier post where the occurrence is used to start the DSA modules before data acquisition begins.

mcduff

[mcduff]

I am also trying to figure out why the image of your occurrence looks strange. The tip of the triangle should be cut off, but on your images it looks like it is there.

mcduff

[mcduff]

---

@mcduff wrote:

You should choose one of the following numbers for your divide by counter (Sorry for not be clear):

Intersection [ Divisors[13107200],  Divisors[40000000] ]
Result
{1, 2, 4, 5, 8, 10, 16, 20, 25, 32, 40, 50, 64, 80, 100, 128, 160, 200, 256, 320, 400, 512, 640, 800, 1280, 1600, 2560, 3200, 6400, 12800}

---

What I said before was incorrect. This result gives common sampling rates where the edges line up, not divide by numbers. Sorry for the mix-up.

In your case you have a 9234 which has a 13.1072MHz clock and FPGA 40MHz clock. The max rate you can run your SAR using this method is 12.8kHz. 😞

13107200/12800 = 1024 counts, 40000000/12800 = 3125 counts.

If you have a 9239 it has a 12.8MHz clock that everything can use, and it will give a lot more sampling options.

Sorry.

mcduff

[LReck]

Unfortunately i am stuck with the 9234. I rewrote my program once again, staying closer to your code. I've added a State of Operation counter to see at which point my program stops. It only counts up to 3 so far. This means that my program never enters the main loop. Why did you wire a False constant to the Stop condition of your initilization counter? How does your program progress past initilization in that case?

InitilizationMain Loop

[LReck]

Okay if i remove the Wait on Occurrence in the last frame of the initilization my code runs. If i now acquire data from the SAR module directly as shown in the picture above, and also add a SigmaDeltaModule, i can obtain data from both. This is so far not including a sigmadelta-delay-compensation.

 main loop

I use a divider of 1024 for the SAR resulting in 12800Hz data acquisition. For the Deltasigma module is selected a rate of 12800Hz as well. Doing a couple of runs i get a difference of around 133 samples (sometimes 132, sometimes 134 but mostly 133). So the SAR gives me 133 more measurement points than the deltasigma. Roughly 40 of these should be due to the input delay of the deltasigma (as described in a previous post). 

If i have such a constant delay, i can just compensate for that. The thing is just, i don't know whether they really start of the same tick of Module1 master clock. So they run on the same clock but now with a fixed delay.

Therefore, the next thing i will try is just having a tick counter that will show me the delay between the two loops. I won't have time to implement that today but i'll try to make it tomorrow.