Dear All,
I have a situation where I need to read the currently logged in USERNAME (Like we do it in graphics DVSYS.THISUSER/USERNAME.A_CV = OPERATOR”), in an ACT block in control studio.
Is this possible? If yes then kindly suggest how I can achieve this.
Thanks for all your time.
Bhargav
Hi,
everything is possible
You add a Tag in the controller hmmm.. you can choose wich format you want.. maybe the typ external reference...
In the VB code you add the "newTag" := DVSYS.THISUSER/USERNAME.A_CV...
there is a similar thread here about getting the actual user, and using it..
Niklas Flykt
Klinkmann Oy
Key Account Manager safety products
nikfly@gmail.com
In reply to Niklas Flykt:
How would this work with multiple users? If stations have different users logged in, how do you know which user/station to use?
If you really do want to read the name, you would have to pass it to the controller as a string, using a task in a scheduler. Upon change, a script can be run to write the username to a string parameter.
Doesn’t sound like a good concept though, what are you trying to achieve?
In reply to AdrianOffield:
hi,
sound like your not going to use a standard faceplate or button. Then it should be even easier.
You program under your "button" the get user and write code and then what it´s supposed to do .
Assuming the action is triggered by the operator action.
regards
Hi Adrian, Actually all the operator stations in my project will be logged in with the ID "OPERATOR".
The requirement i am trying to achieve actually is as below:
WHen any one logs in with the ID of "OPERATOR" i need to modelock the faceplate to "AUTO" mode and otherwise release the modelock.
THerefore i was thinking i will use an ACT block in my module and the write the code as below:
If USER = "OPERATOR" then
Modelock
else
Release Modelock
Endif;
In reply to Bhargav.Chitti:
hi Niklas,
Actually i am trying to achive a modelock on AUTO mode when user is logged in as OPERATOR. The faceplate i am using is a standard one.
Therefore i didnt want to customize the faceplate but rather add a code in my module's ACT block which says:
The suggestion which u gave before of
"newTag" := DVSYS.THISUSER/USERNAME.A_CV is working fine in graphics but not in my control studio ACT expression :(
Hi Chitti,
That's kind of what I thought, so how will your logic know from which station the operator has logged into?
If you have three OP stations, anyone of them can have different users, so how do you tell your logic which station is triggering the login?
The only way I can think of doing this is to have a script running in Workspace that writes the current user to a string in your controller, one string per station. Your logic would then need to check if any of these strings have changed and use this as a trigger for performing the USER = OPERATOR check.
Seems like a drastic change though on a process, preventing users from mode changing loops. I think it should be possible using security rather than having to implement VBA. Removing the MODE parameter from the control lock might achieve the same results, basically, it prevents the Operator from accessing the MODE parameter, thereby, not being able to change modes.
In reply to gamella:
I would agree that this is not a good idea. The username is based on an individual operator station. A schedule (or other method) would need to be configured for each physical station.
Controls on what a specific user can do are best handled through the HMI or system security. Therefore, you should either look at overall security settings (privileges for an operator) or you will need to modify the faceplate to look at user and disable certain functions.
In reply to Michael Moody:
Here are your stated requirements:
"The requirement i am trying to achieve actually is as below:
WHen any one logs in with the ID of "OPERATOR" i need to modelock the faceplate to "AUTO" mode and otherwise release the modelock."
I read this as meaning you do not want Operator to be allowed to set the mode to anything but AUTO. (If you actually mean change the control mode of the module to AUTO when Operator logs in than I would advise strongly against that).
Per this statement, you should be using the user interface, not the controller logic, to determine whether the faceplate buttons for mode are enabled and/or visible.
Operate knows which user is logged in. The faceplate should have an animation to disable or hide visibility on the mode selection buttons (all except the one for AUTO, I presume).
However, if you don't want Operator to change modes, perhaps you should look into changing the parameter.field security for Mode.Target so that it is not Control, but Restricted Control.
Chitt,
As Adrian and many others have pointed out, you will have issues with this scheme when you have multiple operator stations as well as reliability/maintainability concerns.
Which Operator Station login info do you use if Usernames are different between multiple stations?
How do Area Assignments affect this logic?
What happens if the mode has to change based on process?
The reason I ask is I'm not understanding your requirement to essentially modelock exclusively to the operator based on a computer login and possibly disregard control schemes and/or logic that may be determining what should be occuring based on process conditions.
In my opinion this seems to be backwards and you should want to prevent the operator from making changes/mistakes based on process conditions instead of giving him/her exclusive use.
What I have typically seen is modelock regardless of who is logged in and then allow certain priviledge users bypass this if needed.
So your choices are:
- Write a bunch of custom VB logic somewhere what will be hard to maintain, troubleshoot, etc
- NOT allow Operators to change the mode as some have suggested (which doesn't seem like a very good idea to me)
- Don't allow him to change the mode during "certain" situations (i.e. Supervisor has bypassed, Process is running they cannot change the mode but when in Hold/Shutdown state they can).
The last option could just be a visibility option of the graphic buttons so they can't do it from the graphic (Control Studio would allow) or it could be an enforcment type that would put the mode back if somehow it was changed from Control Studio Online.
Good luck
In reply to Matt Stoner:
Thank you so much for showing interest in my issue. I guess i will speak to my EPC and suggest to them that doing this "modelock" based on User Login is afterall not such a good idea.
I will instead ask them (EPC) (as Matt Stoner has suggested) to instead give me a "set of situations(process related)" during which i will lock the mode to AUTO.
Thanks once agian for sharing all your valuable knowledge over the community.
Have a nice day all,
Bhargav.C
Hi everybody,
I´ve used this "user lock" in one place.
It was to disable the "disable horn" button, it is quite easy to do it and prevents the operators to turn of the horn and not have to listen to alarm signals.
One thing II noticed it was that when I logged into the system with better rights, you could have that situation that you could "forget" to re-able the horn, when you
switch to operator as user the Horn-button is disabled and also the horn. The operator can´t change the mode because of the user lock..
You have to log into the system with better rights and reable the button/horn and then switch back to operator