LabVIEW
Count running exe instances
Solved!
@Durnek wrote:
Hi!
I need a little help. I've an exe. This exe is allowed to run on several instances. (ini -> allowmultipleinstances = TRUE). But I would like to know how many instances are in memory.
I've found this link: http://forums.ni.com/t5/LabVIEW/Using-VI-Server-to-check-if-another-LabVIEW-executable-is/td-p/10630...
This is very useful, but this solution checks if a specific exe is running.
I would like to do the following. When I start my exe, it will search for any opened instances (looks for itself is opened and if it is count it). This sounds like singleton object, that looks for any object instance in memory.
1.) My question is, is it possible to write a code that can decide from itself is in memory or not?
I'm not forced to use VI server abilities.
2.)What if, I use the exe ini file, and when I open a new instance, increment a value in it (i.e: Instances=1|2|3...), and when it is closed, decrement this value. Editing ini files, isn't it dangerous for the further instaces of exe?
If I want to use VI server to solve my problem, my opinion is I have to write a background service, that counts any opened VIs. Am I right?
Thanks for the advices!
Hey Durnek,
From what I understand, you're wishing to create a VI which can detect how many instances of an arbitrary .exe are currently running in memory.
Here's my idea:
For a Windows OS, the task manager maintains information on all of the currently running processes in the system, including all of the seperate instances of a currently running individual program. I was thinking that if you could access this information, with knowledge of the general name the relevant processes would possess, you could iterate through the entire list of process names and count the number of tasks which correspond to this known process name, giving you the total number of instances of a particular application.
If this sounds like a valid solution to your problem, then this NI Community Document contains VIs which allow LabVIEW to access the task manager. The virtual instrument returns a list of all of the task data in an array format, which you could easily iterate through!
If I've misunderstood the nature of your problem, I'd appreciate it if you could tell me where I've gone wrong so I we can think of another method which will give us the right solution.
@Durnek wrote:
Thanks for the answers! Both solutions are correct!
What do you think counting myApp.exe in tasklist is a good solution to block my exe to run multiple instances on Terminal Server? my App is installed to termial server, and clients want to run my exe simultanously. I would like to limit the number of instances to run.
I'm affraid this tasklist is perfect only "standard" usage. (on termial server, every client has own tasklist)
Do you think, I have to write into registy? or how could you do that?
If I write to registy all clients are work from one registry.... am I right?
Hey again Durnek.
Okay, I understand the problem now. I suppose the solution you supposed would be a valid way of implementing this function.
The way I see it is:
> LabVIEW application is executed.
> Checks a globally accessable variable between all similar .exe's to see if this value has reached a globally defined maximum.
> If not, then increment this value and run the main processes of the VI, if so then display a message indicating to the user that too many instances are running and the application must close itself.
> After every close of an application instance, decrement this value.
The only issue with this implementation is that race conditions must be avoided; i.e. make sure the VI is processing the most up to date version of the counter variable and prevent data conflicts. This could be implemented through the use of Semaphores/Functional Global Variables.
@Durnek wrote:
Dear Alex.T
Thank you for your reply!
There is a small problem with registy. If the termial server user accouts dont have admin privilegs, my exe does not have the right to increment a registry value, only to read.
"Checks a globally accessable variable between all similar .exe's" - what do really mean? if Registry is not possible, Using my application.ini is not an elegant way.
Could you suggest me a way?
Thanks in advance!
Hi Durnek,
Sorry, I didn't properly explain myself. Rather than changing a registry value, you could instead make a variable within LabVIEW which could maintain this counter that your VIs would have access to; via use of a global variable. A global variable is a variable that multiple VIs can have read and write access to for sharing information.
Firstly, for the executable VI, you'll have to create a project which it resides in. In this project, if you right click on My Computer and select New > Variable and create a Network Published variable, you'll have something that the VI within the project can access. What I'm thinking is any same instance of this VI that is executed will be able to reference to this same individual variable, for the increment and decrement process; this will allow us to keep track of the number of opened VIs! Once you've created the variable, if you right click on it in the project window and select Deploy you will instantiate the variable on your computer which all of your VIs will be able to individually access. When implementing this VI for proper use on the server, you'll have to do the same thing but deploy the variable on the server instead.
So, now our design goes as follows:
Each initialised VI will access a network published global variable to determine whether or not the maximum number of applications currently running has been reached, and whilst avoiding race conditions, will modify this value to maintain the count. I also recommend making the 'Maximum number of applications that can be ran' a globally accessable variable too, to improve your program's flexibility.
You can see the newly instantiated global variable by going to All Programs > National Instruments > Distributed System Manager.
The variable will be in your localhost directory, so when other computers need to access the variable they should reference the IP address of wherever the variable is stored. You'll have to make sure you protect it too!
