Streamlining Auto Login and Logout in Factory Talk View Studio SE for Multiple Areas

For valuable insights and assistance, you might want to check out the discussion in this thread: http://www.plctalk.net/qanda/showthread.php?t=95319. Best regards!

• 16-01-2025
• gclshortt

gclshortt commented: [View the discussion thread here](http://www.plctalk.net/qanda/showthread.php?t=95319). This thread might provide the information you need. Best regards! I've reviewed this suggestion, but it doesn't quite align with my requirements. I am not seeking a "view-only" login; rather, I want to access one of the six startup macros that I have developed. Each operational area requires distinct permissions. For instance, the Filler area should log out and switch to the FillerOperator, while the Capping area must log out and transition to the CappingOperator, both of which operate on separate sides of the facility. Currently, I have a single main menu with a Logout button, which simplifies the interface without cluttering it with numerous screens. Ideally, within the SE environment of the Studio, I would like the Logout button to perform a Login action (specifically, Login startup macro "x"). This means it should log in using FillerMacro or CappingMacro, etc. Although I can set it to log in as a generic operator, that is not my intention. I want the system to log in using the macro that corresponds to the specific client, ensuring that the Logout function logs in the appropriate user profile for that client, rather than just redirecting to the screen.

• 17-01-2025
• travisroberts88

To effectively resolve this issue, it's essential to incorporate Visual Basic for Applications (VBA). Since FactoryTalk View (FTView) lacks the capability to identify the specific client on which it is operating, utilizing VBA is crucial. By retrieving the PC name through VBA, you can determine the appropriate macro to execute based on the identified client. This approach ensures a tailored solution for your automation needs.

• 17-01-2025
• ASF

The ASF team stated that you will likely need to integrate VBA (Visual Basic for Applications) to effectively manage client-specific operations in FTView. Since FTView lacks the capability to determine the client being used, VBA is essential for retrieving the PC name. This PC name can then be used to determine which macro should be executed. If you're looking for a command to obtain the PC name, the only one that comes to mind is `Application.GetHMIServerComputerName`, although this method hasn't proven effective in my case. Here's an example of the code I'm working with: ```vb ' Note: This code utilizes the RSVIEW32/SE IDLE DETECT CONTROL ActiveX Control Private Sub RSView32SEIdleDectectControl1_EnterIdleState() Dim computername As String computername = Select Case computername Case "" Select Case CurrentUserName() Case "Supervisor" Application.Login "username", "password" Application.LoadDisplay "Main Menu" Case Else End Select Case "" Select Case CurrentUserName() Case "Supervisor" Application.Login "username2", "password2" Application.LoadDisplay "Main Menu" Case Else End Select Case Else End Select End Sub ``` This implementation allows me to use a single master supervisor username to automatically log out to the specific login credentials associated with the current client, regardless of which client is being accessed. Although it's possible to create multiple supervisor accounts and make the case logic dependent on the logged-in user, my goal is to tie it to the client itself. For example, if the supervisor is on Client4, the system should automatically log in as `usernamex` and `passwordx` after an ActiveX timeout of 30 seconds. By leveraging the right VBA commands and structuring the logic based on the computer name, you can enhance client-specific user experience in FTView applications.

• 17-01-2025
• travisroberts88

We successfully navigated this issue. It’s surprising, but embedded commands often fail to function properly within the FTV environment. To illustrate how I tackled this challenge using VBA, consider the following example: ```vba Dim compName As String compName = Environ$("COMPUTERNAME") 'Utilizing the Windows environment variable "COMPUTERNAME" allows us to identify the device running our code. This is done using the Environ$(string environmentVariableName) function. Select Case compName Case "Client4" Select Case CurrentUserName() Case "supervisor" Application.Login "operator", "operator" Application.ExecuteCommand "Display ""Main Menu""" Case Else End Select End Select ``` You can adapt this approach for additional clients as needed. This method efficiently resolves the device name issue and ensures proper user authentication within your application.

• 18-01-2025
• travisroberts88