LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

LABVIEW FPGA running Sub Vi without Host

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?

0 Kudos
Message 1 of 12
(182 Views)

remark - each SubVi runs as endless loop

0 Kudos
Message 2 of 12
(154 Views)

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…

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
0 Kudos
Message 3 of 12
(153 Views)

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!?

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
0 Kudos
Message 4 of 12
(150 Views)

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:

RubiMesh_0-1736768892979.png

If am copying the content of sub-VI-s back to the main - all loops inside them are running OK.

 

0 Kudos
Message 5 of 12
(143 Views)

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:

RubiMesh_0-1736768892979.png

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…

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
0 Kudos
Message 6 of 12
(132 Views)

Inside most of the sub-VI-s are endless loops:

RubiMesh_0-1736771496491.png

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"

0 Kudos
Message 7 of 12
(128 Views)

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?

0 Kudos
Message 8 of 12
(113 Views)

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.

0 Kudos
Message 9 of 12
(86 Views)

"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.

0 Kudos
Message 10 of 12
(74 Views)