LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Numerical Integration Method in FPGA

Solved!
Go to solution

I am trying to implement this example of Selection of Numerical Integration Methods ( https://forums.ni.com/t5/Example-Code/Selection-of-Numerical-Integration-Methods-Using-LabVIEW/ta-p/...) in my LabVIEW FPGA mode. I am using cRIO-9045 and I have NI-9223 module. Instead of this sine wave generator in the main.vi I want to replace it with analog input of module NI-9223 ,AI0. I have connected function generator output to the analog AI0 input.

I am new to LabVIEW and can not run this program on FPGA mode. Can anyone please suggest me here what can be done?

0 Kudos
Message 1 of 20
(323 Views)

Looking at your code, I think moving to LabVIEW FPGA with your coding might be a step too far for your LabVIEW knowledge.

 

Do you understand the dynamic data type used for your sine? This is not a thing on FPGA. Even SGL datatype is something which is horrendously expensive on FPGA...... DBL does not exist on FPGA AFAIK.

Message 2 of 20
(309 Views)

Hi Abhi14ry,

Why do you need to implement this on FPGA? Can it be on the RT side? 

Like Intaris pointed out, you seem to be missing some key fundamentals of LabVIEW FPGAs and FPGAs in general. You are limited on data types and sizes when working on the FPGA. Largely you will have Numerics (commonly Signed and Unsigned Integers, FXP, SGL and Boolean). You can later put them into fixed size array or clusters to work on fun stuff.

Having said that, if you MUST implement all that on FPGA:

Code Simplification: Simplify your code to be processed on FPGA. For example, replace formula node under the Simpsons rule vi with basic functions, change data type from DBL to SGL (to start with) etc. How would you know you have something wrong? Compile the code and it will not let you if you have something wrong.

Fix every error you get while trying to compile the code until there is no more errors. Your code may still not work but at least you will have something that compiles, later you can fix your logic using simulation mode. Do not forget to switch it back to FPGA Target for compilation.

Xonmyth_1-1761858152397.png

 



Understand loop timing: You will be using while loop as you have multiplication and division in your code. Analog Input would also force you to use while loop. Since these operations take multiple ticks of 25ns clock that is on your board to complete. 

 

For reliable results, you will have to time your loop iterations. Sometimes your code will finish, lets say in 250 us other times 1ms. I would time it to 2ms (just to ensure that I am getting good deterministic results every 2ms). This is just an example.

Setting up acquisition loop: It is tempting to think that once you connect an input you will magically get desired data in your code. But that is not the case, you will again need to use loop  timing to read input signals deterministically. For that, you will have to SAMPLE your signal every x ticks/us/ms. You will have to refer to datasheet of your board to see how fast you can go. (Examples available under LabView help)

Data Transfer Within FPGA: I personally do not like to bog down my acquisition loop with rest of the code. I think this will also ease some pain for you if you acquire data in one loop and then write to target based FIFO to be read in the second loop. (Examples should be there for target based FIFO)

Also read about loop synchronization.

Displaying Final Results: FPGA runs WAY TOO fast as compared to what PC can display. FPGA does not really have a front panel like PC. So LabVIEW will internally be reading your out data from FPGA, passing through RT and then essentially your PC side will be displaying it on the Front Panel of the  FPGA VI.

Going this route will not give you reliable  results, you may see a graph but it could be clipped in a really strange way where you will questions your code. But in reality there is a data loss which makes your data look strange on the graphs on an FPGA VI's front panel.

If you must plot graphs, best thing to do is to use Target to PC FIFO. This will allow you to buffer all the data you have and then display it on the PC side. (Read about FIFO and how they work).

Again, you should be able to find an example for this under LabView help. 

To sum it up in correct order:

1) Sample Signal

2) Process Captured Signal (the thing you want to do)

3) Display results on PC side

I think if you spend a week on all this, you will be really happy with what you have achieved. You may hate life briefly in the process but that is okay, ignore that.

There are some real good resources online and examples (under LabVIEW help) for almost everything that you need to do. Use them.

Xonmyth_0-1761857824691.png


X

Message 3 of 20
(266 Views)

Hello Xonmyth,

 

Thank you for your reply.

 

I am working in my internship project where I have to calculate Joule Integral(I2t) from thermal short circuit test. The test timing will be between 0.5 second to 1 second with fast switching mechanism and sampling rate .For this I need to measure this short-circuit current (around 25KA injected) from current probe and calculate its value using any of the Numerical Integration Method that's why I choose LabVIEW FPGA. I have experience in LabVIEW program but I am new to FPGA programming so I am having difficulty to implement this program in FPGAs mode.

 

0 Kudos
Message 4 of 20
(243 Views)

What do you do with the result from theintegration? Display it? Make decisions on the FPGA and control hardware with it in a loop?

 

If it's only display, then I strongly recommend you only implement the acquisition onthe FPGA, transfer it to RT (Via DMA) and calculate there, it will make your life so much easier.

Message 5 of 20
(240 Views)

To calculate Joule Integral Value (I*I* t). The result from the integration method will calculate the I2t value in real time and compare with the fixed value . When the calculated value reach the fixed value, the test will stop.

 Please share your thought and suggestion in this case.

0 Kudos
Message 6 of 20
(236 Views)

Hi Abhi,

 

do as Intaris told you: do the DAQ stuff in the FPGA and analyze the data in the RT part!

 


@Abhi14ry wrote:

The result from the integration method will calculate the I2t value in real time and compare with the fixed value . When the calculated value reach the fixed value, the test will stop.


Is it important to "stop the test" within µs or can you tolerate to stop within ms?

This will be the difference when transferring samples from FPGA to RT...

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
Message 7 of 20
(223 Views)

Okay I will try to do as Intris told me.

 

Yes, it important to "stop the test" within µs. I have NI-9401 module to trigger thyristor through driver. It should trigger and cut off the circuit immeditely.

0 Kudos
Message 8 of 20
(221 Views)
Solution
Accepted by topic author Abhi14ry

We're starting to get into more technical details. Generally on FPGA, you want to process data point-by-point, not do an acquisition of a full set of data and then process. Because of this, only certain methods transfer efficiently to FPGA. If you're recording the data first and then processing (which seems to be what the Trapeziodal and Simpson Integrations are designed to do) then you're best going the RT route.

 

Your FPGA code uses a standard while loop which has a somewhat undefined timing.  If you could create your code in a SCTL (Single Cycle Timed Loop) then your time interval is constant and all forms of integration becomes much much easier as it essentially becomes an accumulator with a single multiplicator at the end to scale. This is how I would do it, but I have over 10 years experience of programming exclusively in SCTLs on FPGA. With processing of every data point and a constant timing, Numerical Integration and Trapezoidal essentially give the same result in this context. You take the average of every datapoint N and N-1 and accumulate (add and bitshift by -1 : Average of 2).  By fixing the "reference point" to the average of the points, the mathematical description of the functions are the same.

 

But Programming in SCTL is not for beginners. If FPGA programming is significantly different to normal LabVIEW programming, SCTL programming on FPGA is twice as different. It requires a very different thought model.

 

Read HERE for some more official details. Be warned, it's a lot. This path is not a "one week" type of thing. It takes time to understand.

Message 9 of 20
(210 Views)

Thank you for your insight, knowledge, and advice. 🙏

 

I will go through the NI LabVIEW FPGA guide you provided and try to make the program and update here in NI community if faces any issue with my program.

Appreciate your guidance on:

  • Using point-by-point processing over full data acquisition on FPGA.

  • Considering the RT route for Trapezoidal/Simpson integration if I'm recording first.

  • The suggestion to use a Single-Cycle Timed Loop (SCTL) for constant timing:

0 Kudos
Message 10 of 20
(187 Views)