LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Running a second Labview instance paralizes the one already running

Highlighted

Hi,

 

I am writting because I did not find this question along the forum. Perhaps it is already posted but I did not find it.

 

In our lab we are running a labview program to control one of the NI DAQs. The program is used to monitorize some parameters every 10ms (it could be longer, for example 100ms, but it would not matter for the actual problem) and we don't want to close it as It should monitorize this values all the time. When I open another .vi to run some measurements (another .vi program) the first program stops for some time (I did not actually measure but lets say one or two seconds) while it loads all the necesary libraries and so on. We don't want anything to stop the first .vi.

 

Just to add something else, both programs are not accesing any common file, COM port, etc... each of them controls different equipment

 

Thanks.

 

Cheers,

 

Neu

0 Kudos
Message 1 of 7
(1,471 Views)
Highlighted

Are you using LabVIEW projects? If so, each one opens a different instance (process) of LabVIEW and so they should be completely separate. Building an executable for your LabVIEW program would also have the same effect (and I mean...you don't run programs written in other languages in 'debug' mode, do you?)


LabVIEW Champion, CLA, CLED, CTD
MediaMongrels Ltd. - NI Alliance Partner (blog)
0 Kudos
Message 2 of 7
(1,455 Views)
Highlighted

You really should be building executables.  One of the other benefits of executables is you do not need a LabVIEW license to run one.  This could save you money if you are currently running the LabVIEW environment on every single test station when all you are doing is running set tests.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
0 Kudos
Message 3 of 7
(1,447 Views)
Highlighted

I suspect the OS is the issue.

 

When a new application instance is started and a program is started the OS has to map in all of the program to memory. During that period of time, the OS is running in kernal mode and nothing else can happen while that is going on. It about the same as opening a large spread sheet in Excel etc.

 

I code around that by using hardware timed acquisitions that have a large enough buffer to collect data while th main application is interupted.

 

There is an old joke about a guy asking his doctor why he experiences a pain in his eye when he drinks his tea. After going through a etailed sequence of the morning tea the doctor advises him to take the spoon out of the cup before takinga sip.

 

In that case as like the situation you described, it is similar to when my son did something he should not and got hurt.

 

Don't do that!

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 4 of 7
(1,421 Views)
Highlighted

@Sam_Sharp wrote:

Are you using LabVIEW projects? If so, each one opens a different instance (process) of LabVIEW and so they should be completely separate. Building an executable for your LabVIEW program would also have the same effect (and I mean...you don't run programs written in other languages in 'debug' mode, do you?)


Technically, the early versions of LabVIEW did not have the ability to build executables, so running in "debug" mode was the only way, and still is a legitimate way to run LabVIEW, if not the "best" way.

 

Plus, it's a lot easier to integrate a LabVIEW VI than a LabVIEW executable in TestStand.

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 5 of 7
(1,394 Views)
Highlighted

Thanks to all.

 

Unfortunatelly, I cannot run any exectutables at the moment, I suspect because of the antivirus (¿?). In any case right now it is not the moment to try it as we are using it for some experiments. I simply tried to create and executable that works in different computes but not in the one we want to work in. When I double click it just tries to open but then nothing opens (I also tried running as and administrator and compatibility issues). Anyway, I will try to find it out later.

 

On the other hand, I found the problem or at least how to solve it. If I open the second .vi by using the "open" from the first .vi then it freezes for some seconds. The same happens if I double click on the second .vi as it is using the same Labview front. On the other hand, if I simply open another Labview instance (from Labview.exe) and then open my second .vi through there then nothing pauses. This seems to do the trick at least until I am able to run the executables.

 

Thanks once again or the tips 🙂

0 Kudos
Message 6 of 7
(1,349 Views)
Highlighted

@VanderDen wrote:

 

On the other hand, I found the problem or at least how to solve it. If I open the second .vi by using the "open" from the first .vi then it freezes for some seconds. The same happens if I double click on the second .vi as it is using the same Labview front. On the other hand, if I simply open another Labview instance (from Labview.exe) and then open my second .vi through there then nothing pauses. This seems to do the trick at least until I am able to run the executables.


Yes - and if you create a LabVIEW project for each VI, each one will always open up in it's own instance of LabVIEW.


LabVIEW Champion, CLA, CLED, CTD
MediaMongrels Ltd. - NI Alliance Partner (blog)
0 Kudos
Message 7 of 7
(1,341 Views)