LabView DAQ running more stable under Linux?

[Benjamin38]

Harry - 

Here is an advisor configuration that I built for a system like this : CR2496371.  You can plug it in at ni.com/advisor under Retrieve Configuration.  

The minimum requirements for software would be LabVIEW Full w. App Builder (or just LabVIEW Professional) + the LabVIEW Real-Time Module.  You probably noticed after some research, that these chassis are equipped with an FPGA in the backplane as well which can add extensive capability and truly deterministic execution and speed.  However, if this really isn't a concern or priority you can run the cRIO systems in "Scan Mode" where you won't have to program the chip.  If you do decide to program the FPGA that will require the LabVIEW FPGA Module in addition to the software mentioned earlier.  

So...

No FPGA programming:  LV + App Builder + LV Real Time

Yes to FPGA:   LV + App Builder + LV Real Time + LV FPGA

[Ben]

i have had LV apps running under Windows for over a year without rebooting.

If your apps is crashing under Windows I would first ID the nature of the problem. Converting to Unix or a RT target could cost a lot of time and effort only to find out you still have the same issue.

"Upgrading your engine will not fix the flat tire."

Ben

[Harry.W]

Hello Ben,

I am working on my flat tire but also hoping my old man can buy me a new engine! haha

I did find there is a slowly memory leak in my code and right now I am trying to narrow down where they are. I researched a little bit and learned from others that two main causes of memory leak:

1. Building array inside loop

2. File IO without proper closing it.

For item 1, I do have arrays built inside a big while loop, but I havn't figure out how to get around it yet. Forgive my ignorance, but is there any easy way to resolve this?

For item 2, I found I forgot close one data file aftering writing to it. I fixed it and havn't got chance to test it.

Do you have any other suggestions? What else I should look for to resolve the memory leak issue? I know there are many discussions on this but am trying to use the simple method first to see if I get luck...

Thanks for your help!

Rgds,

Harry

[Ben]

Search on "inplace" at the very least.

I have writtein many posts on the subject and it is no easy topic to cover quickly.

If you narrow down the leak and are still stumped post code pluse images and we (the team here) may be abel to focus on what is hitting you.

Ben

[GuenterMueller]

Hi Harry.
Also worth mentioning: The "NI LabVIEW Desktop Execution Trace Toolkit" should be helpful in identifying memory leaks (and other issues).

And I agree with Ben: We also have LabVIEW applications running at our customers for more than one year without facing any issues. I have to set the limit of one year because our customers usually request new features in these applications about once per year. Then they stop the "old" application and replace it by the update. And then, run for about another year ... No need to blame any operating system nor LabVIEW.
Regards Guenter

[Harry.W]

Thanks Guenter.

I checked this Desktop Execution Trace Toolkit and it costs ~$1000 so I probably have to relay on "manual" approach to identify the issue. But I do think you, and also Ben, are right about it's probably my program's fault. I'll try to dig in a bit more...

Thanks again!

Harry

[Harry.W]

Ben,

Thanks. I'll see if i can find it out myself. If I cannot, I'll for sure ask for help from your experts!

Rgds,

Harry

[Ben]

---

@Guenter Mueller wrote:

Hi Harry.
Also worth mentioning: The "NI LabVIEW Desktop Execution Trace Toolkit" should be helpful in identifying memory leaks (and other issues).

And I agree with Ben: We also have LabVIEW applications running at our customers for more than one year without facing any issues. I have to set the limit of one year because our customers usually request new features in these applications about once per year. Then they stop the "old" application and replace it by the update. And then, run for about another year ... No need to blame any operating system nor LabVIEW.
Regards Guenter

---

Quick war story. A phone call from my customer...

Cust: Ben, I got a message indicating we are running low on memory, do you have any ideas?

Ben: What does the event log show?

Cust: Nothing unusual but there are a lot of entries.

Ben: How long has it been running?

Cust: The log shows about 18 months.

Ben: I may be time to try restarting the application to open a new log file.

That application ahs been running 24 X 7 since 2001 with only occational rebots or restarts to let me add new features. If you have ever worn a protective mask with disposable cartidges, on the side of those cartridges is a sticker earned by the app I mentioned above. See here  (wanring, this is link to cdc.gov) for some of the testing that LV has been driving behind the scenes for years.

Sorry for the [OT] but I do want to squash the diea that LV is not stable.

Take care,

Ben

[GuenterMueller]

Nice story, Ben.

It's time to rewrite your application and discard very old entries in the logile 

This would take it to the next level ...

Guenter

[Ben]

---

@Guenter Mueller wrote:

Nice story, Ben.

It's time to rewrite your application and discard very old entries in the logile 

This would take it to the next level ...

Guenter

---

Or just opening a new file every year or so...

Ben