is there a way for Wonderware scripts to query the Windows username?

Hey guys,

I've got a bit of a conundrum that I'm trying to solve. I'll say what it is basically, and then give the explanation of the greater problem.

Long story short, is there a way for a script in Wonderware to return the name of the Windows user who is currently logged in?

So the client wants a flows summary screen printed every night before the totalizers reset. I found a program called NovaPDF that will do this automatically, with timestamped filenames so I wrote a printscreen script in Wonderware to print every night. Seemed easy enough, but there's a problem. The client has multiple concurrent licenses on a VM server that the application is deployed to. So the main terminal at the WTP is always wateruser1, wateruser2 is always logged in for the standby iPad, wateruser3 is the lead operator's phone. So every time that printscreen script runs, it does it for every user. It's causing issues, so I was hoping there would be a way to grab the current Windows username in a script and then run the printscreen script for only one user.

I've gone through the scripting guides and haven't found anything that will do what I'm looking for. Security is Archestra based, not Windows based.

Any ideas for how I might go about this? Thanks for any help!

You can use the '$Operator' or '$OperatorName' system tag to grab the name of the currently logged on user.

Alternately, you could assign a new 'Receive Notifications' role to more than one user and then use 'IsAssignedRole()' in your script to determine whether or not to proceed with a notification.

tvey said:

You can use the '$Operator' or '$OperatorName' system tag to grab the name of the currently logged on user.

Click to expand...

Doesn't that return the Wonderware operator and not the Windows user though? The security in my application is set up via Archestra and has all users on all VMs, plus they log off automatically for security purposes.

Haven't tested myself recently but here's the entry from the help file:

Can't hurt to try and verify but I'm pretty sure this would return the user of the Wonderware application, not the Windows user but I'll give it a quick test and report back.

Confirmed, $Operator and $OperatorName are not the Windows user.

tvey said:

You can use the '$Operator' or '$OperatorName' system tag to grab the name of the currently logged on user.

Click to expand...

As I understand it, the particular user is not really the question, so much as what platform the user is logged in with. Whether to print is not determined by the user, I think, but by the interfacing hardware. Is that right, defcon.klaxon?

If so, I'm not sure I understand how the Windows username would be any more useful that would be the Archestra username for determining whether to run the printscreen script.

Bit_Bucket_07 said:

If so, I'm not sure I understand how the Windows username would be any more useful that would be the Archestra username for determining whether to run the printscreen script.

Click to expand...

Because the Windows user and the Archestra Operator are two wholly independent things; multiple Windows users are logged into the same virtual machine simultaneously and they're left running 24/7, and the operators only log in to make changes and they are logged out of Archestra/InTouch/WindowViewer after an hour of inactivity. So the users remain logged into Windows and running WindowViewer, and the script runs across all instances of WindowViewer.

For the sake of clarity, when I say "user" I mean a Windows user logged into the operating system. When I say "operator" I mean someone logged into the Wonderware application.

OK so the issue is, the runtime server allows up to four users to log in concurrently through virtual machines. So that means at the water treatment plant, there is a Windows user logged into the server (through Remote Desktop Connection) that is never logged out. On the standby iPad, Remote Desktop Connectivity software is used to log in also, so there are two Windows users and again, never logged out. The manager has a terminal in his office across the corp yard that is always logged in as well, so there's a third user logged into Windows. And there is a fourth license as a spare. So WindowViewer is running in three difference instances, all on the same virtual machine but as different Windows users, but the *operators* are not logged in to InTouch. The operators are automatically logged out of InTouch after an hour of inactivity.

So the issue is, every instance of WindowViewer running wants to run the condition script that prints the flow summary window at 11:55pm and it wants to save it to the same spot, plus that means four licenses for the PDF authorship software that would be totally wasted.

I was thinking that if I could know which Windows user is logged in, I could tell the script only run the print script for the wateruser1 Windows login, which is the terminal at the water treatment plant. If wateruser2 is logged into its own instance, that's the standby iPad so don't run the print script a second time, and if the manager is wateruser3 then again, don't run the print script.

Hopefully that makes sense, let me know if it's still murky.

defcon.klaxon said:

Because the Windows user and the Archestra Operator are two wholly independent things; multiple Windows users are logged into the same virtual machine simultaneously and they're left running 24/7, and the operators only log in to make changes and they are logged out of Archestra/InTouch/WindowViewer after an hour of inactivity. So the users remain logged into Windows and running WindowViewer, and the script runs across all instances of WindowViewer.

OK so the issue is, the runtime server allows up to four users to log in concurrently through virtual machines. So that means at the water treatment plant, there is a Windows user logged into the server (through Remote Desktop Connection) that is never logged out. On the standby iPad, Remote Desktop Connectivity software is used to log in also, so there are two Windows users. The manager has a terminal in his office across the corp yard that is always logged in, so there's a third user logged into Windows. So WindowViewer is running in three difference instances, all on the same virtual machine but as different Windows users, but the *operators* are not logged in to InTouch. The users are automatically logged out of InTouch after an hour of inactivity.

So the issue is, every instance of WindowViewer running wants to run the condition script that prints the flow summary window at 11:55pm and it wants to save it to the same spot, plus that means four licenses for the PDF authorship software that would be totally wasted.

I was thinking that if I could know which Windows user is logged in, I could tell the script only run the print script for the wateruser1 Windows login, which is the terminal at the water treatment plant. If wateruser2 is logged into its own instance, that's the standby iPad so don't run the print script a second time, and if the manager is wateruser3 then again, don't run the print script.

Hopefully that makes sense, let me know if it's still murky.

Click to expand...

Can you use the GetNodeName function and use that to decide whether to run the print script?

Bit_Bucket_07 said:

Can you use the GetNodeName function and use that to decide whether to run the print script?

Click to expand...

Unfortunately that doesn't work; the node name returned is the name of the VM, so it's the same for all Windows instances.

try the function wwgetusername() from the SysInfo Script Function Library add in.

You can always try using OS security type.

defcon.klaxon said:

Unfortunately that doesn't work; the node name returned is the name of the VM, so it's the same for all Windows instances.

Click to expand...

Is it feasible to rely upon the users to operate a switch that toggles a discrete memory tag that would disable the script on their particular machines?

Can you assign a static IP to the client wateruser1 is using to RDP over to the Terminal Server and then call TseGetClientId()
or pull the node name from the client wateruser1 is using and use TseGetClientNodeName()
?

It has been a really long time since I used wonderware, so those might not even be functions anymore..

DaveW said:

try the function wwgetusername() from the SysInfo Script Function Library add in.

You can always try using OS security type.

Click to expand...

This sounds like it's exactly what I'm looking for. Now I just gotta find a download link, I've contacted Tech Support but they're taking forever to get back to me.

Got the software installed, looks like it's gonna work. We'll see come tomorrow morning.