• Not Answered

Key Security & Groups in relation to PLM's

Hi All,

I am trying to wrap my head around the whole groups and Keys thing and finding it a little difficult, I have managed to set up my groups as follows :-

All of my operators belong to the operate group who have the following keys assigned Control and Alarms.

I then have for example Operator 1 who has operate for Area A assigned and has keys Alarms for Area A assigned.

I also have for example Operator 2 who has operate for Area B assigned and has keys Alarms for Area B assigned.

 When in run time I open the faceplate for the control PLM and Area A operator pushes the start button I am getting the following error 

"Access was denied for operation.  Possible reasons are the modules area is not assigned to the workstations Alarms and event subsystems, or you do not have parameter/field security access."

I have checked that the modules for Area A and B are found in the Alarms and Events for my specific workstation and have been downloaded....

The question is am I missing a key somewhere to allow the operator to start the PLM?

4 Replies

  • You have to check that the parameter (XCOMMAND) that is written when the start button is pressed is assigned the key the operator has access for in Parameter Security list. If it isn't in the list then it assumes the configured default. Just add the parameter name and assign the proper key if it isn't in the list. Changing the default might affect other things that they currently may or may not have access to now.
  • GaryL.  The basic concept is straight forward, but I understand your frustration.  In addition to the User security, there is also the Workstation Scope, and one thing that almost always gets me is with RDP sessions/Remote Clients.  The Plant Areas must be assigned to each Remote Client session.  

    One tool that is very useful for security rights trouble shooting is "Watchit".  You can enter the path to the parameter.Field and select the option to write to it.  On that dialog there is a "May I" button.  Pressing this button will show you the security profile of the parameter.  That is, it shows you the Parameter and field write locks needed and whethe the current user and workstation have the required keys in the designated Plant Area

    Now you can see what the Parameter and Field security is configured to.  In this case the Control lock.  Just below the Field/Parameter, it indicates the path is "within Woskstation areas, and tells you the default Lock, and which Key is required, in this case Control.  Below it tells you the User security information as to the Keys they have, and the Plant Area needed.  At the bottom is "Write Check Results in" RT_SUCCESS, or not.  Now you can clearly see what is preventing you from writing to this parameter.

    If a Parameter or Field is not explicitly assigned a lock, the default lock is applied.  Changing this affects all parameters not explicitly assigned a lock. 

    Your User Group has a defined set to keys, and you've assigned this user to have access to specific Areas.  The Areas must also be assigned to the workstation and/or Remote client session.

    Hope this helps.

    Andre Dicaire

  • In reply to Andre Dicaire:

    Thanks for the advice guys, The XCOMMAND is assigned "Restricted Control" but I don't really want to give the operators this key as we have other parameters in the system that also have "Restricted Control" and I don't want them to be able to use them.


    Would it be safe to change the Restricted Access on the XCOMMAND to different level like "CONTROL"?
  • In reply to GaryL:

    Yes it is safe and what you will need to to something. This will allow all operators to do use the PLM. If you don't want all of them to do this you can assign to a user lock and then give this key to operators you want to be allowed.