Move Any Control Algorithm or Simulation Model to Embedded FPGA Hardware with New Floating Point Toolkit

[AL3]

It is a difficult question.

LabVIEW makes everything simple with respect to C, C++ and mainly VHDL/Verilog. LabVIEW code portability is impressive as well as coding efficiency.

In my opinion, both worlds have their own specific characteristics, cost, performance, time-to-market etc...

We should get the most from each domain.

Cheers,

AL3

[BMac]

Thanks! To follow up on the discretization, here is a LabVIEW Real-Time application that computes the discrete transfer function coefficients for the FPGA based Proportional Resonant Controller with Leading Phase Compensation for a configurable number of harmonics. The idea is that the PR transfer function should have the appropriate amount of leading phase to compensate for the delays of the line reactor filter, analog to digital converter, and computations.

The leading phase angle adjustment is for a simple inductive linear reactor filter and resistive load, as well as a configurable digital latency expressed in 40 MHz clock ticks. The line reactor filter transfer function model could easily be updated for any line reactor filter type, such as LCL, and load model.

The application also calculates the gain at the resonant frequency and runs analysis to compare the continuous time and discrete time transfer functions regarding the step response, frequency response, amplitude and phase at the resonant frequency, and pole zero maps. If running this in real-time, uncheck the Perform Analysis? control for faster execution. The NI Control Design & Simulation Module is required.

The code is attached. Please let me know if you find any mistakes or have any suggestions to improve it. The discretization is working well in double precision but for single precision it needs work.

[DaveKlapp]

I'm having a small problem working with the Floating Point IP. I unpacked the zip using WinRar and moved it to a short directory as directed. I built a new project just to play around and put it in the same root. Added the NI9606 GPIC gear and started building an FPGA Vi. When I attempt to add the floating point functions to the vi, there is a broken arrow and Labview is asking me to Configure the IP for the Spartan 6 (Screenshot attached). I checked and the supporting Coregen files for the various FPGAs and they are in the same directory. Confused I tried to configure the IP and regenerate the files. The process also fails mid way thru with a -61496 error. I thought it might be a directory length problem so I made sure everything was very short but still no joy. The error has something to do with an unhandled case, looks like a 32 bit overflow or something.

Im sure I'm missing something.

Thoughts?

Dave

[AL3]

Hi DaveKlapp,

I had a similar issue with the NI SoM.

That user solved the problem. I followed his suggestions.

https://decibel.ni.com/content/message/132495#132495

Hope it will help.

Cheer,

AL3

[DaveKlapp]

AL3

    Thanks for the feedback. Unfortunately it does not appear to be a configuration problem. I have been working on the SQRT with the 5.0 corgen for the Spartan 6, which just does not have that many options as the 7.0 for the linked FPGA. I have tried a number of options, all with a similar result. It looks like the process actually completes to a point as all of the files get created properly in the temp directory. At the very end it appears the software attemps to move the files to the final directory, however nothing is actually moved.

Here is a better screen shot showing the generation process nearly complete.

Update....

   I made a small amount of progress. I was able to unzip the files to a very very short path and then incorporate the Floating Point functions into a project. By keeping the path super short the pregenerated floating point functions were not broken this time. Apparently my path was just slightly to long before. I went a step futher though and tried to regenerate the SQRT function above to see if that problem was also related to path length. Unfortunately I still get the same error -61496 even being very careful to keep the path tiny. I have also noticed another strange bug. If you notice the screenshot above the Configure Xilinx IP button is greyed out. After one failed attempt this button will remain greyed out. In order to attempt again I must close out the entire PROJECT and reopen, closing the vi (saved or not) has no effect on resetting the Configure Xilinx IP button.

Any other ideas?

Dave

[DaveKlapp]

OK so I have the answer and I had to dig deep to get there.

     It turns out if you do not use the default Labview installation directory in the Labview paths setting it causes this error when the Xilinx IP tries to generate. One of the steps to generating the Xilinx IP is a check of what target the IP is being generated for. The 'niFpgaIPINodeMapTarget.vi' pulls a path from the Labview Default Path setting and then heads deeper into the 'Targets' subdirectory, searching for the FpgaDevicesSpecs_resource.xml file. Unfortunately if you happen to be like myself and intentionally set your Labview Default directory to another location, say another, non-OS, data partition to ease opening prior projects, the 'Targets' subdirectory doesn't exist here, the file is not found (no file not found error thrown), the IP generation process bombs, and you get the cryptic error above.

     So I'd like to offer the bug and a possible solution (anyone know where to do that?) IMHO the path should use the vi.lib path constant, strip off the 'vi.lib' subdirectory and then head down the 'Targets' path. I believe this will put you into the installation directory with a greater degree of certianity unless someone keeps their vi.lib in a directory other than the default installation directory (which would probably cause all kinds of other issues).

Hopefully this will help someone else in the future.

[richtian]

Hi, DaveKlapp

That's a really nice catch. I will file a bug on behalf of you. Thanks for the suggestion to fix the issue.

richtian

[DaveKlapp]

I noticed a bug with the Floating Point lib above. Within the FPGA Emulation cases of the condition structures in the SCTL comparison functions, many have the same repeated comparison functions, 'equals' if memory serves. Yikes thats tough to follow, heres a pic.

I was going to fix them all and reupload but I got tired of struggling with the Floating Point Operator nodes. On that note, is there a way to point the floating point nodes to pregenerated files and have them flagged as up to date. It was a nightmare to figure out how to keep the same single version of generated code and use it in multiple places. If you copy and paste or regerate the files from a different Vi it breaks the first Vi.

I am attaching a stripped down version of the Floating Point lib which contains the Polymorphic VIs and the Spartan 6 target alone. It was way to much overhead to bring in 17k files into my project each time I wanted to use it. It also made the project code non-protable due to the 100's MB of overhead, now about 20MB. I also made some additions, a set of unordered functions in both polymorphic and SCTL. I also pulled in the Natural Logarithm 02.vi which was located in a distant directory.

If anyone else wants a stripped down version for the 9606 or other Spartan 6 cores here ya go.

Thanks

Dave

[biscay]

Hi BMac,

Your floating-point toolkit is great; thank you for making it available to us all.

There is one thing I have been wondering from the beginning, though:

How come are therr exactly five (00...04) resource-optimized operators? Namely, why not four or six? Is there anything we could do to better take advantage of the floating-point IP in their resource-optimized version?

I usually work with a GPIC-equipped sbRIO-9606. I am still with LabView 2014, and plan to upgrade to 2016SP1 as soon as it becomes available... (but any advice on this is appreciated as well).

Regards,

Biscay.

[bjc120]

Hello I am looking for a Proportional resonant (PR) control for rt lab-view. I can see you posted the PR control for FPGA but because of utilization problem in FPGA, I have to put a PR control from FPGA to RT lab-view. is there any PR control for RT lab-view. Thanks for your help.