01-13-2025 03:24 AM
I have a content for the SBRIO board - RT and FPGA applications. The SBRIO runs as standalone control block.
The RT application is divided into number of VI-s and runs OK.
Now I want to split the FPGA application into number of VI-s - one main and number of SuVI-s.
Unfortunately, here I am encountering problem with Running state.
I am starting the main VI but the SubVI-s enter "waiting for run" state and I cannot force them to run.
Where is my problem?
01-13-2025 05:37 AM
remark - each SubVi runs as endless loop
01-13-2025 05:40 AM
Hi Rubi,
@RubiMesh wrote:
Now I want to split the FPGA application into number of VI-s - one main and number of SuVI-s.
Unfortunately, here I am encountering problem with Running state.
I am starting the main VI but the SubVI-s enter "waiting for run" state and I cannot force them to run.
How do you know your FPGA subVIs are in "waiting for run" state?
When you run the FPGA VI on system startup then the whole FPGA VI including its subVIs should run…
@RubiMesh wrote:
Where is my problem?
We don't know your code so an error analysis based on your description is rather limited…
01-13-2025 05:41 AM
Hi Rubi,
@RubiMesh wrote:
remark - each SubVi runs as endless loop
Now it sounds like a simple "THINK DATAFLOW!" problem!
One subVI blocks other subVIs from executing!?
01-13-2025 05:49 AM
Hi,
The white arrow in SubVI changes to "wait for run" after the main VI is started (pressed the white arrow).
The SubVI-s are called in such way:
If am copying the content of sub-VI-s back to the main - all loops inside them are running OK.
01-13-2025 06:24 AM
Hi Rubi,
@RubiMesh wrote:
The white arrow in SubVI changes to "wait for run" after the main VI is started (pressed the white arrow).
I still don't know how you could observe a VI running on a FPGA: the code is compiled into FPGA fabric, so either the whole code runs or nothing…
@RubiMesh wrote:
The SubVI-s are called in such way:
If am copying the content of sub-VI-s back to the main - all loops inside them are running OK.
This doesn't look like a DATAFLOW problem, but we still don't know what's inside of the subVIs…
01-13-2025 06:33 AM
Inside most of the sub-VI-s are endless loops:
I also supposed that all VI-s are incorporated into the fabric and cannot be stopped.
But in such case it is not clear white arrow wit tooltip "waiting for run"
01-13-2025 08:01 AM
As someone who has FPGA code with lots of individual VIs with endless loops, something about your description does not make sense.
How are you "running" the code on your FPGA.
Have you connected the "Open FPGA Reference" to a bitfile, VI , build-spec?
01-13-2025 11:00 PM
I am working on project that was started by someone else.
The main FPGA VI added to the RT project via adding the FPGA Reference (*.ctl) to the source files list.
The RT VI-s exchange data with the FPGA using the FPGA References pointing to different VI-s on the FPGA side.
The original design includes single VI that runs well.
Now I am trying to re-organize it by splitting the single huge VI into main and number of SubVI-s.
01-14-2025 05:03 AM
"different VIs on the FPGA side" means different bitfiles.
Can it be that each VI is trying to run a different bitfile? That would cause (of course) resource contention issues as only one FPGA bitfile can be deployed at a time.