VeriStand

cancel
Showing results for 
Search instead for 
Did you mean: 

Syncing DSA cards with custom FPGA

I'm working with a customer that has a DSA card (a 4497) and an FPGA, along with other SC Express DAQ cards. The FPGA is using a custom personality created using the FPGA I/O interface tools. We can't get the signals from the FPGA, DSA and other cards to sync up.

The best results so far have been using the FPGA as the master, but the DSA card lags behind it. We were told by NI that the DSA card needs to be the master. We tried doing that, using the following configuration:

Config.png

We fed the same sine wave into three cards, and got the following result:

Signals.png

Our NI contact suggested that we modify the FPGA template library code to change how it handles timing, but I'm loath to modify an official library that they specifically tell you not to modify.

 

Does anyone have some advice about how to sync up these signals?

 

Thanks in advance.

0 Kudos
Message 1 of 11
(4,196 Views)

Bskertchly,

 

Before we dive fully into the issue, I would like to get some context to the issue to help determine what the best course of action is to this system. Therefore I have the following questions:

 

  • Can you post your FPGA code for the NI-7842, so we are able to get a better sense of what is happening with the FPGA.
  • How are you getting the signal into VeriStand, are you using a custom device or using the default integration into VeriStand?
  • What is the sample rate that you are running the FPGA card at?
  • Can you also post the data logs from acquisition, the raw data? This can be the .tdms files off of the target.

 

Please let me know the answers so we are able to find the best solution for you.

Sarina
Applications Engineering
National Instruments
0 Kudos
Message 2 of 11
(4,149 Views)

You must need some way to tell the FPGA to be the slave, can you show that?

 

Is the delay constant or does it change on each run?

 

That size of delay suggests that there isn't really any sync happen. Some uS delay could be expected as the DSA cards have some inherent filter delay of around 40 samples but that doesn't explain what you are seeing (and I think recent DAQmx driver accounts for that delay in sync signals for you, not certain though)

James Mc
========
CLA and cRIO Fanatic
My writings on LabVIEW Development are at devs.wiresmithtech.com
0 Kudos
Message 3 of 11
(4,143 Views)

StarSarina and James_McN,

 

Thanks for looking into this. I'm attaching the FPGA code. We're using a custom device to publish the data from the FPGA, but I've been asked not to post the code since it contains proprietary information.

 

I'm trying to gather the raw data logs, but they're huge, and the client is in a remote location, so it may take some time.

 

As you can see from the FPGA code, the FPGA is told to use external timing by VeriStand through the Use External Timing channel, which should be set by VeriStand based on the System Explorer config.

 

The delay between the DSA card and the other DAQ cards is constant, but the FPGA delay varies.

0 Kudos
Message 4 of 11
(4,132 Views)

So the fact it varies means that it isn't bad synchronisation (i.e. some sort of lag, delay or similar between the cards). Its no synchronisation at all at the minute.

 

Unfortunately it has been a couple of years since I played with Veristand synchronisation so I'm a little rusty. There is a good whitepaper at http://www.ni.com/white-paper/14637/en/#4.HardwareTimedSinglePointwithXNETTimeSingleChassis that is worth checking there aren't any settings your missing but I can see any.

It does say it prefers to use FPGA to drive the primary control loop timing. You might want to make sure that this is set to use the DAQ as well  (I guess because it is chassis master it should).

 

Also just be sure, I'm assuming these graphs are from the single point mode not the custom device waveforms? The custom device waveforms look to be free running so won't be synchronised.

 

 

James Mc
========
CLA and cRIO Fanatic
My writings on LabVIEW Development are at devs.wiresmithtech.com
0 Kudos
Message 5 of 11
(4,111 Views)

Just noticed this in that whitepaper:

 

*When using R series FPGA devices it is important to enable the PXI Chassis Clock Synchronization setting in "RIO Device Setup" in your start menu. This is by default off and can cause drift when using an FPGA device in certain configurations.

 

Might be worth checking as well.

James Mc
========
CLA and cRIO Fanatic
My writings on LabVIEW Development are at devs.wiresmithtech.com
Message 6 of 11
(4,109 Views)

Thanks, James.

 

We can't use the FPGA to drive the timing, because the DSA card doesn't support it.

 

The graphs are from the waveforms. The waveforms are timestamped by the custom device by taking a timestamp when the samples are received, then subtracting the number of samples times the dt to get back to the beginning of the acquisition. If the FPGA is using external timing to send the data over the DMA, then this should be enough to at least keep the offset constant between runs, if not make the delay negligible.

 

The FPGA template relies on VeriStand to set these three parameters:

2016-10-05_10-26-05.png

I think my problem is that those three channels aren't being set correctly due to a problem with the configuration. I can't seem to find any documentation on how VeriStand decides what those parameters should be based on the System Explorer configuration.

 

I'm reading that whitepaper to see what I can find.

 

Thanks again for your help.

0 Kudos
Message 7 of 11
(4,098 Views)

Ah but are the waveforms coming from the loop below that? Where it is sent to the custom device element that is accessing this?

 

The loop you have shown there is the data that comes in through the NI FPGA XML definition which is all single point timed I believe.

 

Below there is this datastream:

2016-10-05_16-38-24.png

 

This is going to start as soon as the FPGA starts. There is nothing stopping it. This also means it won't wait for the DSA card either hence the lead time.

 

If this data also needs to be synchronised you need to make it start when the sample clock starts. If you put this look in a flat sequence structure then you can add a frame before that waits on the first sample clock pulse. I think this should just work if you put the wait for next tick in the first frame (outside of the loop, we don't want to time the loop, just wait on the start).

 

I hope that makes sense and my assumptions are right. Let me know if not.

James Mc
========
CLA and cRIO Fanatic
My writings on LabVIEW Development are at devs.wiresmithtech.com
0 Kudos
Message 8 of 11
(4,094 Views)

That makes perfect sense! I'm going to have our client test it, but I definitely think you're on to something here. Thanks for the help, and I'll come back here and mark your answer as the solution if this works.

0 Kudos
Message 9 of 11
(4,089 Views)

@James_McN wrote:

Just noticed this in that whitepaper:

 

*When using R series FPGA devices it is important to enable the PXI Chassis Clock Synchronization setting in "RIO Device Setup" in your start menu. This is by default off and can cause drift when using an FPGA device in certain configurations.

 

Might be worth checking as well.


don't forget this. Really important

Stephen B
0 Kudos
Message 10 of 11
(4,074 Views)