LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

FPGA SubVI stalling/slowing down the main VI

Hi,

 

I have a subVI (a) which worked perfectly until today, it's job is to control an IC that routes some signals. Some DIOs are used to put IC into different states and input for these DIOs is generated by converting a U8 int to boolean array and then individual indexed boolean is used a input.

 

Due to some changes, I had to update the DIOs in the subVI (a). After making the change, subVI (a) still functioned as expected but what appeared like, it stalled or slowed down the rest of the code. Please know that the rest of the code is not dependent on this subVI (a), it simply sits in parallel while loop by itself and does it's own work.

 

Troubleshooting steps:

  • I pasted the BD content of the subVI (a) in parrallel to Main VI's BD, in a separate while loop,just like subVI would be place, everything started to work again.
  • Retried using the subVI (a), code stalled (It worked but in a strange manner)
  • Created a new VI, copied the content of subVI (a), saved it with a different name, placed it on main vi's BD, everything worked fine.

Everything is back up and running after bullet 3. But I want to find the reason behind this occurrence.

 

---------------------------------------Additional information below this line if more information is needed-------------------------------------------------

 

It is the exact same code, not even a code, just a conversion of U8 to boolean connecting to DIO. I cannot find a reason why this is happening. I have exhausted my limited brain cells in past eight hours. Any suggestions on where should I start looking for finding some answers about this occurrence? I did not find anything similar on forum.

 

I am willing to provide more information if needed. I just cannot attach the main VI since it's an IP but I have attached the troubling and working subVI.

 

 

Other information:

-FPGA resource utilization 41% (sbRIO-9638).

-IC is analog device ADG1406

-No known race condition, inputs for this subVI are directly and separately controlled by a VI on RT using FPGA IO read/write node.

-Previous versions of subVI (a) just had different DIOs.

-LabView version: 2019 SP1 Full Development.

 

Explain "Strange behavior":

-The input/ output signal voltage values were dropped by half when subVI (a) was used. There is not direct relation in between the two entities. (Please see IO designation in the attached ZIP file, it is the SDI line that I am outputting)

-YES, IC and external circuit are perfectly fine since it has always been working fine and is working fine, just this SubVI caused issue after the update, that too just this one time and code and circuit still works fine when this subVI was saved as a new file.

-My code still breaks when older subVI is used.

 

EDIT: Sorry if it hurt your brain while reading or it if made no sense (not trying to act smart,I know im not). I just tried to provide as much information as I could in one go added with a pinch of frustration I had.

 

0 Kudos
Message 1 of 9
(1,729 Views)

My suspicion is even thought I updated the subVI it was not properly updated/ saved for some reason as saving it to a new VI resolved the issue. But do not want to assume so asked on forum.

0 Kudos
Message 2 of 9
(1,718 Views)

I do not know what those terminals do but I do not see how they would stall/slow down the main VIs.


Certified LabVIEW Architect, Certified Professional Instructor
ALE Consultants

Introduction to LabVIEW FPGA for RF, Radar, and Electronic Warfare Applications
0 Kudos
Message 3 of 9
(1,705 Views)

Hi Terry,


@Terry_ALE wrote:

I do not know what those terminals do but I do not see how they would stall/slow down the main VIs.


Those terminal act as an input for the ADG1406 IC which routes some incoming signals on a PCB as per requirement (All custom made). First I questioned that PCB and had it inspected but it has been tested and it works fine as also confirmed after creating a new copy of the same VI. No other changes were made and I have gone through at least 30 complications to reach the conclusion that for sure something is wrong with only that subVI, somehow.

 

But the question is what could possibly cause it.

 

I understand there are a lot of unknowns in the equation, but I certain to a point that it is not the Main VI or the PCB as they all are working now.

 

EDIT: Even though I am driving the focus towards the subVI, I am more than willing to be pointed towards something else but I have exhausted my options. So looking for any possible suggestions. So that something like this does not repeat since this issue was difficult to catch.

0 Kudos
Message 4 of 9
(1,697 Views)

I see and appreciate the detail.  Stepping back, can you put some kind of a counter insight the subVI to see if it really is stalling or slowing down?  The output of counter can be monitored for this.

 

The application specific stuff is a bit over my head to help out so trying to get back to basics.


Certified LabVIEW Architect, Certified Professional Instructor
ALE Consultants

Introduction to LabVIEW FPGA for RF, Radar, and Electronic Warfare Applications
0 Kudos
Message 5 of 9
(1,689 Views)

Sure, thanks for suggestion, I will try it out and share the findings.

0 Kudos
Message 6 of 9
(1,686 Views)

Hi Terry,

 

I added counters to monitor a bunch of things, it turned out the input on one digital input which is supposed to receive an I2C response back was not seeing any input signal, but looking at a scope I can see that the signals are there. Which made code to appear as if it has stalled.

 

To make sure all the DIOs are configured properly for input or output, I have a starting sequence that configures each DIOs using "Set Output Enable" (T/F) method node. (Mentioned just to eliminate possibility of wrongly configured DIOs)

 

But the subVI and digital input are not directly related, even considering the external circuit or previously mentioned IC. And again everything works when using same BD content, copied and saved to a new VI.

0 Kudos
Message 7 of 9
(1,648 Views)

In that case I'd suggest you simplify the code until all is understood and operating as a expected. Then add things back in.

 

Each of things being tried are effectively tests. It may be good to note these checks as tests so they can be rerun if things stop working again.


Certified LabVIEW Architect, Certified Professional Instructor
ALE Consultants

Introduction to LabVIEW FPGA for RF, Radar, and Electronic Warfare Applications
Message 8 of 9
(1,644 Views)

Okay, yes, I will continue running tests. However, I may not be able to come back with any response anytime soon.

 

I appreciate your input. Thank you.

0 Kudos
Message 9 of 9
(1,639 Views)