Does your idea apply to LabVIEW in general? Get the best feedback by posting it on the original LabVIEW Idea Exchange.
Browse by label or search in the LabVIEW FPGA Idea Exchange to see if your idea has previously been submitted. If your idea exists be sure to vote for the idea by giving it kudos to indicate your approval!
If your idea has not been submitted click New Idea to submit a product idea to the LabVIEW FPGA Idea Exchange. Be sure to submit a separate post for each idea.
Watch as the community gives your idea kudos and adds their input.
As NI R&D considers the idea, they will change the idea status.
Give kudos to other ideas that you would like to see in a future version of LabVIEW FPGA!
I have a large array of coefficients that I want to load from a file, then populate an array constant with it. I have a script to do it, now I would like to automatically run it before compiling the bitfile. For context, I want it to be a constant because controls take more resources and do not allow constant folding optimization.
I already had another situation where I made a tool to auto-generate code in case structures based on some specifications given by the developer. If however the developer forgets to run it before compiling, the FPGA VI won't work properly as necessary code has not been generated.
More generally, I think scripting for FPGA is way underrated. As FPGA code is quite often tedious and redundant to create (because optimization is priorized over readability, and because of the lack of type genericity), scripting has a great potential here. Allowing to run pre/post build actions for FPGA bitfiles would surely take FPGA scripting to the next level !
One of the benefits of the Instruction Framework is that one could develop several modules each using Instruction Framework. The modules can then be integrated and the Instruction Framework modules can be assembled using Collections.
This information is not clear and the provided tutorial does not provide information on this use case.
LabVIEW NXG had the ability to create a resource file. Though I cannot find the help reference for this I will describe the functionality below:
Right now the Target Scoped FIFO, P2P, DMA-FIFO, Memory, Handshake Items, Registers, Clocks, etc are all stored as part of LabVIEW Project (lvproj) file.
If want to port to a new project file or target I have to copy/paste. This is not a big deal and works well. However if I update one project's configuration I have to re-copy/paste. From a configuration management perspective I cannot ensure the configurations are always the same. With larger, multi-FPGA projects this becomes critical.
It would be great to have a file that holds all of these resources to allow for easier portability and configuration management.
This would vastly simplify making re-usable modular sub-vis to handle complex interactions involving reading and writing front-panel controls to communicate over the FPGA interface. Presently, this requires a lot of complex code to be copied onto an large complex top-level vi. Being able to pass registers linked to front panel controls would allow controls to be bundled into clusters of registers and sent to sub-vis that could then be generically usable for repeat functionality or across multiple "channels".
If your failed compilation misses the required throughput time by only a few nanoseconds, try rebuilding your bitfile. Each build of a bitfile does not always produce identical results on the FPGA, so rebuilding sometimes resolves minor timing violations.
In most case, compilation might require much time and it's difficult to take quick action after they found the aborted compilation result.
It would be great there is an option which allow automated recompile like below.
Of course the compilation completed, it wouldn't try recompile. Only failed, try to compile again.
when you try to use serial NI 9870/71 with crio controllers it will lead you directly to access them from FPGA mode, however you will find it difficult or not allowed to use its connection with MODBUS device so it will need be accessed by scan mode by installing the specified software on your crio to enable scan mode for these devices , may be we need clear declaration in serial NI 9870/71 datasheet to show that its possible to connect them in scan mode as it guide us only to FPGA and what are the best practices to it
I have Labview 2020 installed, along with Vivado 2019.1.1_AR73110 (which is the version the vi package manager installed). My suspicion is there may be few bits missing from the Vivado installation that labview does, since said bits (like using a board definition as a starting point for a project) wouldn’t ever be necessary for the FPGA module’s normal operation.
The Short version is, Labview’s Vivado versions (2017.2 & 2019.1) behave the same way. I’d question why the C:\NIFPGA\programs\<VivadoVersion>\data\boards directory isn’t present (even if it provides no actual board definitions) in the labview installs if end users are allowed/expected to use the software for custom project uses (IE, FPGA IP export utility, expecting you to use the same vivado version), but ultimately the labview vivado versions do not appear to be missing anything major.
Maybe in future labview Vivado versions, include the data\boards directory, with a readme note about what to copy from a Xilinx Vivado version to get board presets to work, or leave the framework without any actual board definitions.
As the title already mentions. Please add support for the 903x series of cRIO in labVIEW NXG. The systems we have (9039) are just a few years old and we would like to show the benefits of NXG to our students.
sr. lecturer in Engineering. HAN University of Applied Sciences