pierre

Hello,

To respect the design pattern we decided to use (Model-View-Presenter), I created a few scripting tools.

Their purpose was to generate concrete classes from template, modify vi names and class inheritence, icons, save and insert into the project... It works nice.

(I should maybe post the framework to show what can be done with labview engine)

That given class was just some kind of container and factory for other presenters and views.

It was written at the begining of the project so was not generated by scripting tools.

So what I did, was to generate the class using scripting tools and every thing was done. But I still don't understand what happened will that class...

Found the trouble....

There was a class disturbing the building process.

Traitment for a class in large project takes about 10 to 15s. With this class included processing time raise up to 250s per class. without, processing time goes to 10s.

I regenerated the class, include in the project and restart the compilation.

Processing time per class is between 14 to 18s.

Past 1h, almost 70% of the class and libs where processed.

Let's wait for 30 mn and then run the application

To find where was the bottle neck, I add those lines in labview.ini :

keepinternalllb=TRUE

NI_AppBuilder_Logging=TRUE

DWarnDialog=True

promoteDWarnInternals=True

DPrintfLogging=True

LLVMLargeVIThreshold

I installed 2011f2 and add line : lazyLoadIcons=True.

Thanx for every answers.

Bye

Hi,

I have had these kind of problems. Now I must use LV2011f2 to be able to make a build.

What OS are you running?

Which LV version?

Have you enabled LV to use 3GB of virtual memory? http://zone.ni.com/r...e_lrg_ad_aware/

Have you set GDI objects to maximum? HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows\GDIProcessHandleQuota (max 65536)

/Staffan

Hi,

OS : Seven 64bits,

LV : 2011 32bits

I just modified GDIProcessHandleQuota, let wait for a few hours...

I am getting used with that kind of problems, so every time I added major libs into the project try a new build.

It has work since I last add a big enough lib (almost 1200 Vis and maybe 80 classes).

The design is based on 5 major libs :

- MVPFramework,

- Image display models & interface,

- Connectivity daemon,

- Connectivity database models & interface,

- Main Database models & interface,

Building have been tried with every package separately excepted with the main Database.

What I am going to try is to build without the last one.

The answer in a few hours...

Thanx for your answer,

Regards

Pierre

Hello,

I am currently trying to build a large application :

- ~6000 vis,

- ~300 or 400 classes,

I am quite proud of the code, because there is only 1 vi not packaged in a lib or 1 class, it's the Main_App.vi that launches the application.

Architecture is based on Model View Presenter design pattern.

When I try to build the application Labview just process for hours and don't even moves.

Last night, I let him go for 10 hours and it and just processed 1 class.

I tried using Libp to package part of the code but with no success, a lot of linkage troubles occurs when I try to use them. And management of redefinition seems to broke Vis.

As any body encounters that king of situation and even solved it.

Any Ideas...

The software have to be delivered within a week and it makes me sick not to be able to make usable to work we have done for months....

Thanx for answers.

Pierre

cross-post : http://forums.ni.com/t5/LabVIEW/troubleshootings-while-building-large-application/td-p/1725632

There are a couple of things that come to mind. One is to transfer ownership of the ref from the VI that launches a dynamic VI in a new thread to the dynamic VI. Then it doesn't matter if the caller goes out of scope. This happens with the arguments to the Run method from the invoke node (LV 2010 and earlier) - LV 2011 has the new Async VI call primitive and it can do the same thing by setting the arguments to the VI Ref open method. There's a recent thread here on LAVA that has much info about that (http://lavag.org/top...nchronous-call/). The other method that might work is to create a functional global that is a "reference pool". Call this FGV by something (like the main panel) that never gets unloaded and store create all of your refs in there. The FGV should never go out of scope and the refs should not be destroyed. In this case, do not transfer ownership of the ref to the called VI. This might work for you.

Mark

I first tried Global Functionnal with no success. Actualy, even if creation is made in global fonctionnal, global fonctionnal is called in Dynamic Vi context, so Reference seems to belong to Dynamic Vi context...

The solution I have choosen is post on NI forum : http://forums.ni.com...1698122#M601558

Thanx for answers

Hello,

I am actualy designing a program using a Model-View-Presenter Template.

Views and presenters are contretized by dynamic lauched Vis.

Models are shared between Presenters using LV References.

Main models are instantiated by the main presenter. Others models, that might belong to main models can be instantiated by sub presenter within sub presenter thread.

Using execution-trace I noticed that all references created in sub presenter thread are destroyed when thread stops.

That is very annoying because the aim of sub presenters is to modifiy and eventualy create sub models. And if sub models can not be reused after sub presenter is destroyed, my design pattern will never work.

Does anybody ever met this situation?

Is there any way to ask labview runtime to keep valid references created in dynamic launched VI when this one stops?

thanx for answer.

Pierre