LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

"How can I build a LV-application, that is able run twice at the same time?

I'be built a DataLogging-Application (built with LV7.0) that communicates with a serial device. We own two of these devices and I would like to use both devices on one Win2000-PC. But the application can't start a secound time. Is there a possibility to enable my *.exe to run twice on my system at the same time?
0 Kudos
Message 1 of 6
(4,000 Views)
Hi Robert,

simple solution: copy and rename your exe.

You have to keep in mind that:
1. Globals are global 🙂
2. subvis which arn't reentrant will be shared in that way, that only one application will run it and the other will have to wait until it's finish and uninitlized shiftregisters keep theire value.
(VISA vis are reentrant (I asume))
(If you don't know what reentrant means search the manuals or the knowledgebase)

I have runing applications that independently handle 8 serial ports with VISA and mostly reentrant subvis.
(using VISA 2.6 or 3.0, however recommended is the newest version of VISA)

Henrik
Greetings from Germany
Henrik

LV since v3.1

“ground” is a convenient fantasy

'˙˙˙˙uıɐƃɐ lɐıp puɐ °06 ǝuoɥd ɹnoʎ uɹnʇ ǝsɐǝld 'ʎɹɐuıƃɐɯı sı pǝlɐıp ǝʌɐɥ noʎ ɹǝqɯnu ǝɥʇ'


0 Kudos
Message 2 of 6
(3,999 Views)
You can use a little known, unsupported, use at your own risk ini setting:

allowmultipleinstances=true

I got a couple of senior LabVIEW developers to secretly bless my posting of this .ini setting. They were wearing masks, so can not be identified later if a judge is involved, but as someone on info-LabVIEW stated, if a National Instruments product is using this setting, it must be OK.

Keep in mind, multiple instances of an application may require some special considerations, like deciding if you need them to read/write to different .ini files.

Enjoy,
Roy
Message 3 of 6
(3,999 Views)
I'd be careful using the "allowmultipleinstances=true" technique, as you may come up against some unexpected results - for example, if your application uses named queues, then subsequent instantiations of an executable will cause their queue data to merge with the first instance, resulting in a muddled queue.

Is it an option to do a re-write of the app to handle multiple instruments in instead of only one?

cheers
Christopher

Christopher G. Relf
Certified LabVIEW Architect




Copyright © 2004-2024 Christopher G. Relf. Some Rights Reserved. This posting is licensed under a Creative Commons Attribution 4.0 License.
Message 4 of 6
(4,001 Views)
This may not be a topic for this thread but I am hoping that you guys are aware that there is no enough documentation of the preferences options used in LabVIEW executables. (Is there? let me know...)

(I know one, but not so complete link http://labview.brianrenken.com/INI/)

Thus, I am requesting all of you to go to follow the link below and fill up some product suggestion entry.

http://digital.ni.com/applications/psc.nsf/default?openform

I am very eager to know each and every preference options that we can use, thus, making us more powerful beings c",).
0 Kudos
Message 5 of 6
(3,860 Views)
I disagree (or maybe don't understand) Henrik's answer, at least for Windows environments.
In Win32, memory spaces of different processes are separated, so globals cannot be global to 2 running executables.
You typically need to use special techniques to share memory (e.g. memory mapped files).

Furthermore, Labview's synchronization objects too, either unnamed or named, are not shareable (see http://digital.ni.com/public.nsf/allkb/ECF9AF864FADA3E286256D81005E59DC). On the contrary, native Windows sync objects typically are shareable if named, un-shareable if unnamed.

As for sharing VI's, I'm not sure, but I would be very surprised about any sharing effects not related to external resources (files, registry keys, serial ports, etc.)

Paolo
Paolo
-------------------
LV 7.1, 2011, 2017, 2019, 2021
0 Kudos
Message 6 of 6
(3,843 Views)