DeltaV Operator Login

We are looking at making our operators more accountable for their actions within the deltav system, therefore looking at coming away from the generic operator account and having individual user accounts with operate privileges. Does anyone have any experience with such a setup who can offer any setup advice / lessons learnt.

i'm thinking of keeping windows logged in the generic operator account, then getting the operators to login to deltav user their individual accounts. 

8 Replies

  • There is Autorun DeltaV Operate option ( left click on FlexLock ) and then you have to provide operator user details using Regedit.
  • We do this at my plant. As you said, the Windows login is with a generic operator login. At the beginning of the shift, the operator logs in with his name/password. To ensure that someone doesn't forget to login, we run a script on each operator station at shift change that automatically logs the user out. The script logs in as a generic user "SHIFT_CHANGE" that allows alarms to be visible but doesn't allow changes to be made.
  • Create a View-Only Account (which was described in the second part of this discussion emersonexchange365.com/.../3717 ) or just modify Operator to be a view only account
    - Note, If you are not using a Domain, you will have to create the Windows User Account on all the machines which makes modifying the generic Operator account the better option.

    Then setup each machine to have a screen saver using the DeltaVScreenSaver, click the Settings, Uncheck the Log Off User and enter the information for the View-Only Account. The users will always have to login after whatever you have defined time of inactivity.
    - Note, screen saver settings is user specific so it is usually best to always login with the same account on all the systems

    Instead of using Regedit, you can just put a line of script in UserSettings.grf in the standard directory to login as a default user (View-Only Account) when DeltaV Operate opens.
    If Workgroup:
    frsRunTask "c:\deltav\bin\hlo.exe -user USER -password PASS -computer frsVariables.gs_weName.CurrentValue"

    If Domain system:
    frsRunTask "c:\deltav\bin\hlo.exe -user USER -password PASS -computer DOMAIN"

    If using Remote Sessions:
    frsRunTask "c:\deltav\bin\hlo.exe -user USER -password PASS -computer DOMAIN -session SESSIONNAME"

    Replace the USER, PASS, DOMAIN, SESSIONNAME with the appropriate values for your system.
  • In reply to Matt Stoner:

    Hi ,
    I am Looking for help in below issue.

    While using DeltaV with local monitor, we will be able to Auto Logoff DeltaV user after specified idle time passes (Using DeltaVScreenSaver).
    The same settings are not working when I connect my workstation to HMI using Remote desktop protocol.

    As per the Emerson Exchange forum , we have purchased Splintware third party software and applied below scheduler.


    Set up a new task to activate on System Idle
    Execute the following program: "C:\WIndows\System32\DeltaVScreenSaver.scr"
    Parameters: " /s"

    But this is working only in Windows desktop , not in Deltav Desktop.
    Please support with your ideas.
    Thanks in advance.
  • In reply to RamakV:

    In Deltav Desktop : only Deltav Operate should logon .
  • In reply to Andrew Colvin:

    How do you set up this script to run? Say you would like it log off the user at 7am and 7pm for shift change.
  • How do you guys do it when operators have multi stations. They have to logon/off of each one independently? Also the shift change account is intriguing to me, we would allow that right up until we had a train wreck right at shift change the operators said "we couldn't control and that made the operational upset worse" I hate when we have meetings like that.
  • In reply to Jason.Brumfield:

    first, if not already implemented, move to a domain. managing individual accounts means password issues and a domain keeps all machines aligned.

    Forcing a logoff at shift change can introduce an added stress when a crisis occurs during shift change. Training and trusting Operators is I think better than designing an auto logoff that occurs regardless of operational situation.

    A common windows user is fine, making sure it has the required Windows access for operators. admins can use "run as administrator" when increased windows access is needed, which should not be a typical need.

    At shift change Operator is responsible for logging off, when it is appropriate to do so. logoff is a single button. Shift change is a handoff. why should consoles auto logoff?

    Consider a secure card reader to avoid password forgetfullness.

    a simple solution will always be easier to maintain. Operators should have a say and own the solution.

    Just my opinion...

    Andre Dicaire