LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

UI on an RT target

Hello,

 

Can a User Interface on an RT target be made to run for long?

If I run it for long (about 30 mins), my RT target loses its connection. I get a pop up saying "RT connection has been lost".

0 Kudos
Message 1 of 9
(3,848 Views)

I don't normally have any problems running RT VIs in the development system for extended periods of time. You could think about using remote front panels which will continue to run your RT VI and you can just connect/reconnect to it if you have network troubles.

 

Do you know the reason for the disconnection - is it a network issue (e.g. unreliable wifi) or could it be that your RT controller is running out of CPU/Memory and is becoming unstable?


LabVIEW Champion, CLA, CLED, CTD
(blog)
Message 2 of 9
(3,836 Views)

I have attached a screenshot of what I get. I think I have a memory problem (The "available bytes" continuously decreases). Can you please confirm it?

0 Kudos
Message 3 of 9
(3,831 Views)

Yes, Your CPU load is also showing as 100% which will almost certainly cause your RT controller to become unresponsive (and as such you lose connection to the front panel).

 

Make sure that you have no free-running loops (i.e. without some sort of execution timing) and be careful about memory usage, for example around where you use arrays or open references.


LabVIEW Champion, CLA, CLED, CTD
(blog)
Message 4 of 9
(3,825 Views)

Yep, you have some issues with your code somewhere.  At this point, I recommend posting your code and we can help you reduce that CPU usage and also likely the memory leak.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 5 of 9
(3,805 Views)

Hi,

 

Attached is my folder containing the project. I have modified the code as much as possible to fix the memory issue, but still there is a memory loss.

Hope I get to know what is eating up the memory.

 

I also log data onto the sbRIO. I have removed this log loop in the attached folder. (As I believe that the log loop does not cause memory issues). Let me know if you need that too.

 

[edited 04/13/2015 by moderator to remove confidential information]

0 Kudos
Message 6 of 9
(3,798 Views)

Well, there is a loop inside of your Sensirion_SubVI new_one.vi that doesn't have a wait in it.  You are polling the FPGA for a signal and waiting for it to go low.  But you are slamming the CPU by not having a wait of some sort.

 

You are also loading up the FPGA multiple times.  You should load it ONCE in your top level VI.  You then pass it into the subVIs (like Sensirion_SubVI new_one.vi).

 

And since your top loop has so many waits inside of the code, you should not make that a timed loop.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 7 of 9
(3,791 Views)

Hi crossrulz,

 

 

Even after modifying the code according to your suggestions, the memory space keeps decreasing. I am totally clueless as to how there is a memory leak.

Attached is my modified code.

 

Help!

 

 

-kdm

 

[edited 04/13/2015 by moderator to remove confidential information]

0 Kudos
Message 8 of 9
(3,746 Views)

you are opening multiple references to the FPGA (even inside your subroutines that do not use the open reference and don't close it.

remove them all (except one) and see if it clears up your memory leak.  Even on your main VI. 

Stu
0 Kudos
Message 9 of 9
(3,707 Views)