NI VeriStand Add-Ons Documents
NI VeriStand Add-on: FPGA "Dynamic" Period/Frequency Measurement
Overview
The FPGA "Dynamic" Period/Frequency Measurement code allows users to perform Period/Frequency on incoming digital signals. This functionality is commonly used for Control Applications where we need that type of information at a certain refresh-rates (periodically, ideally independently from incoming signal period/frequency). Of course, Frequency/period measurement capability was already available, it's just an alternative that could be a better fit in some scenarios (but certainly not all), depending on your requirements.
The document referred below gives a good overview of the typical techniques used for Period/Frequency measurements. For each, you have the pros/cons and it's used a comparison reference.
Making Accurate Frequency Measurements
The present example, in this post, gives another option, which is a variant of the Technique #3, referred in the document above. The goal is to get a measurement refreshed at a user-configurable rate but also get the "'maximum" of accuracy at that refresh-rate.
The main idea is to accumulate the maximum number of periods of incoming signals inside the Refresh-rate period. In present example, we accumulate up to 32 periods of incoming signal and we compute period value based on that. The 32 value could be changed to accommodate different requirements.
Here are some conditions you may face and how the FPGA code behaves. For illustration purpose, the incoming signal varies between 1 Hz-50 kHz, update-rate configured to 1 ms, timeout set to 2 seconds (2000 ms):
- While incoming signal frequency is lower than Refresh-rate Frequency (1 kHz), the code waits for a full period of incoming signal and returns it as soon as it's completed. It happens while frequency of incoming signal is faster than the Timeout (2 s -> 0,5Hz). We use a 40 MHz reference clock to measure the period which gives an excellent accuracy. So, in that case, the actual Refresh-Rate is one period of incoming signal.
- If incoming signal frequency equals or is lower than equivalent to frequency of Timeout Period configured, then a Timeout Bit is set for the considered Channel. It remains set while condition expressed above is TRUE.
- When incoming signal frequency is higher than Refresh-rate Frequency (1 kHz) but 32 periods of incoming signal don't fit in the Refresh-Rate period, the code accumulates the completed periods time and when the Refresh-Rate period happens, the period computation is performed: we compute the time taken for the m periods (m < 32) to happen.
- When incoming signal frequency is higher than Refresh-rate Frequency (1 kHz) and 32 periods of incoming signal fit in the Refresh-Rate period, the code accumulates the periods and as soon as we have 32 periods received, we compute the time taken for the m periods (m = 32) to happen. So, actual Refresh-Rate is the time to receive 32 periods of incoming signal, it's faster than requested Refresh-Rate.
What can we expect (in terms of actual accuracy, actual refresh-rate) with that technique if we vary something? I created the Excel Spreadsheet joined here. Where it's really not fully validated. it's supposed to summarize respective performances for the 4 techniques: the 3 from the document referred above plus the one (variant from #3) we are proposing here. There are always variations from one customer to another.
To the question: why is "dynamic" word used? It's simply to highlight that the fact that, based on conditions, the number of periods accumulated varies dynamically to try to accommodate settings.
Where NI-VeriStand applications can be a good candidate as a user, it's not limited to NI-VeriStand as what is proposed is more a LabVIEW FPGA code with User-Defined Variables (UDVs) to configure the personality and get measurements.
Instructions for Use
The Add-on is not a "ready-to-use" in a sense that you need to adapt it to your needs (in terms of number of measurement channels, maximum number of periods accumulated, flexibility you want to give,...) AND also compile it for your FPGA target.
The code embeds a generation part to allow validation and it's, of course, not required for the measurement part (it can be removed).
The code comes with source for a NI-9025 cRIO Controller, a NI-9118 chassis and a NI-9401 digital IO module.
Installing the Code
To use the (name of add-on) add-on, unzip the add-on files and place them in (correct directory based on add-on type).
Once compiled the code could be used along with NI VeriStand Add-On - Scan Engine and EtherCAT.
Add-on Requirements to Run the FPGA code
Software
This device was created for use with NI VeriStand 2014 (LabVIEW 2014 actually). To compile the code, you need:
- LabVIEW 2014
- LabVIEW FPGA 2014 Module
Hardware
This add-on requires the following hardware.
- A NI FPGA Target with digital inputs having capability of running in a Single-Cycle-Timed-Loop.
Known Issues
- <numbered list of known issues>
Version History
1.0.0
- It's not and will never be a product, it's just a source-code example.
Add-on Requirements to Modify the code
- Bulleted list of required software. Please hyperlink to appropriate NI Software.
Support and Contact
This add-on is provided as open-source software. If it does not meet your exact specification, you are encouraged to modify the source code to meet your needs. It is not officially supported by National Instruments.
If you encounter a problem with this add-on, or if you have suggestions for a future revision, please post to the forum for this add-on FPGA "Dynamic" Period/Frequency Measurement Feedback Forum. You must use this feedback forum for support. Do not call National Instruments for support for this add-on.
National Instruments does not support this code or guarantee its quality in any way. THIS EXAMPLE PROGRAM IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND AND SUBJECT TO CERTAIN RESTRICTIONS AS MORE SPECIFICALLY SET FORTH IN NI.COM'S TERMS OF USE (http://ni.com/legal/termsofuse/unitedstates/us/).
