Solution to prevent multiple Vision instances from running on one machine

[Bushmatic]

All,

One issue I need to address is how frequently we run into errors on the floor due to a user inadvertently opening up multiple instances of a Vision project on the same machine. This is a "minimal interaction" screen that primarily feeds information to the user(s) -- sometimes the action is all happening on the screen behind the currently active one, and sometimes the user does not even have a keyboard or mouse as it all runs on PC startup. I'm wondering if any of these hypothetical solutions to this problem seem like good practice to your experienced selves:

• A gateway / project startup script that simply checks whether that same project is already running, and if so, closes the new window right away. Not sure if there is an easy function that can do this.

• Some kind of boolean tag system that indicates whether a Vision project on a specific machine is up and running, including a tag read on project startup to kill new duplicate instances. Maybe this tag gets written with a '1' on startup and back to '0' on shutdown, etc...

• Maybe a client tag system can be set up for this? I haven't delved too deep into client tags but this seems promising once I can learn more.

[andrews]

Could you possibly just hide the project icon they must be clicking on?

[Bushmatic]

I'm really hoping there is an Ignition-based solution out there for this, as that would be easiest for the rest of my team. That idea could definitely work but might also lead to other issues.

[JordanCClark]

If it's just one user and project, something like this in the project stratup script:

sessions = system.util.getSessionInfo('userName', 'projectName')

if len(sessions) > 1:
	system.util.exit()

[Bushmatic]

Edit: This is not actually the final version of the script -- I needed to incorporate the PC name (address) as well. See my post below.

Love it, thanks Jordan. I used your idea to create a client startup script that I can paste into any project where only 1 session should ever be running on a given machine:

project = system.util.getProjectName()
user = system.security.getUsername()
sessions = system.util.getSessionInfo(user, project)
if len(sessions) > 1:
	system.gui.messageBox("This application is already open on this computer. This instance will now close.", "Error: Existing Session")
	system.util.exit()

[Bushmatic]

Just want to update my thread with a question. I have the following startup script running (client scope) on a couple projects. It has been working well for so far, but I have just received a report that a user was repeatedly running into the error message despite there not being any existing instances open. They said they tried about 7 times before they could get into the actual project, and they did not try anything differently those 7 times before it worked. I'm wondering if someone can shed some wisdom as to what might have happened there, because I am having trouble reproducing it. It's like there was a "ghost session" this script was picking up for a short period.

The script is:

pc = system.net.getHostName()
project = system.util.getProjectName()
user = system.security.getUsername()
sessions = system.util.getSessionInfo(user, project)
sessionsCount = 0

for row in sessions:
	if row[2] == pc:
		sessionsCount += 1

if sessionsCount > 1: # If there is an existing session matching this session's username, project name, and PC name, warn the user and close this session.
	system.gui.messageBox("This application is already open on this computer. This instance will now close.", "Error: Existing Session")
	system.util.exit()

[bkarabinchak.psi]

In the gateway you should be able to see what clients are running and under what username under the status page->Vision clients. Perhaps they was logged in on a different computer and they forgot to log out?

[Bushmatic]

Unfortunately I was not around to check the active sessions at the time. The script shouldn't care if a session exists on another computer, as it uses these 3 things to check for existing sessions:

1. Username (common for all shop floor machines -- this is set up with autologin)
2. Project name (common for all shop floor machines)
3. PC name (unique for each shop floor PC)

In this way, it is meant to prevent multiple sessions on any given PC. I did find this post from 2010 which mentions ghost sessions being a real thing in Ignition:

Terminate session

What version of Ignition do you have? The Terminate Session button will terminate the session in the Gateway, however if the client session is still open it will create a new one. The button is only for ghost sessions where there is no client open.

It seems like this is what happened? Maybe there's a function I can incorporate that will attempt to kill a session without me needing to go into the gateway manually?

[bkarabinchak.psi]

If you did not personally verify, I would wait until you did. I cannot tell you the number of times I had a client report an issue, claim they only had one session open, and in fact they had 2 or more. If I had a nickel for every time...

I do see that in your script and that's fair. Presumably they don't log into other user accounts on the same machine and run a client there either? Next time it happens, I would try to remote in and verify for a fact there is not another session running (my moneys on this) and secondly use the the status screen for vision clients, this will illuminate things the most.

The last post in that link does seem to imply that bug was fixed.

[Bushmatic]

Thank you for the help! Yes, I will just have to do some more investigating if and when it happens again. In the meantime I may put in a feature request (or see if there is an existing one) for system.util.endSession( [username], [project], [address], [clientId]) or something to that effect which could do the same thing as me going into the gateway and terminating a session myself.

Edit: Looks like this can be done using existing functions:

Kick out the connected users from the vision client

If you want to have some kind of "management" screen, you can set up client message handlers that call system.util.exit, and then use system.util.sendMessage to broadcast a message to those other clients requesting that they close.

[bkarabinchak.psi]

You may find this thread of interest - https://forum.inductiveautomation.com/t/kick-out-the-connected-users-from-the-vision-client/

[PGriffith]

@Bushmatic

do the same thing as me going into the gateway and terminating a session myself.

Technically this is possible already, but I'm not going to expand on it anymore than I did in this post

Can I create a non-admin user role with ability to review and terminate Vision Client sessions?

No, the gateway doesn’t currently support such granular permissions. The ‘Terminate’ button is visible if the client has access to the config section of the gateway. You could put a feature request on ideas.inductiveautomation.com, though. If you’ve got at least one client open for supervisors, you could use system.util.sendMessage() and system.util.exit() to implement basically the same thing - just have a message handler on each client waiting for a terminate message, and run system.util.exi…

A system.vision.terminate or something function might be interesting... maybe added to the gateway scope only, though that could get confusing.

[Bushmatic]

Or, if you dig through this forum, you could find access to the (unsupported and undocumented) internal classes used for the gateway, and use one of those to send a remote-terminate push message to the client; that’s as much of a hint as I’ll give.

Yeah... I'll stay away from all of this...

If you’ve got at least one client open for supervisors, you could use system.util.sendMessage() and system.util.exit() to implement basically the same thing - just have a message handler on each client waiting for a terminate message, and run system.util.exit() . system.util.getSessionInfo() would give you the session ID(s) to terminate.

If it comes down to it, I think I will just go this route. For now, I will do nothing until this issue starts repeating itself. Thanks for chiming in Paul; always nice to learn from the developers themselves.

[pturmel]

If you use the "kick out everyone else" approach, using the message to duplicate clients to terminate themselves, you don't have to worry about terminating on the gateway side. Any stale connections (not really there) will simply not get a suicide message.