Symbol Explanation

1 – Flags

1. A grey flag indicates a block that is not currently being edited in any local session and is available to be ‘marked for check-in’ which can be done by:
   • Editing the contents of the block
   • Clicking the flag itself
   • Right-clicking the block and selecting ‘Mark objects for check-in’
2. A blue flag indicates a block that is marked for check-in in this local session
   • You can un-mark the block using the same methods above.
   • Keep in mind that only an ‘Undo’ of edited logic can remove the flag – even if you remove the changed logic, the program will still recognize this as a change, and you’ll have to uncheck the flag manually.
3. A grey flag with a refresh symbol represents a block that has changed and has been checked-in, but you are not up to date with because you’re out of date with the server copy (item 2 pictured above)
   • If you mark a block that needs refreshing for check-in, it will not turn red, but it will show up when you filter ‘items marked with conflict’ when checking in (see picture below). 
     

     

4. A yellow flag is a block that has been marked by another user and will turn red to show marked with conflict if you try and mark for check-in in your local session
   • See the Usage Info section below for more details about this flag
5. A red flag indicates a block that is currently in conflict between local sessions.
   • It’s best practice to never check-in changes while marked with conflict. If significant development has taken place before you realize there is a conflict, you need to work it out with whoever else is working on that block. Alternatively, you can copy the block in a _Copy version to save your changes, which you can manually merge once the block is checked in by the other user.

2 – Server Status

1. A few possible states for this icon:
   • Grey – Not connected to the server
   • Solid Green – Connected and up to date with the server copy
   • Solid Green with ‘Refresh’ arrows – Your local session is out of date with the server, and you need to refresh to get up to date
   • Yellow with ‘Lock’ symbol – Server copy is being edited and is locked

3 – Commissioning Mode

1. Two states for this icon:
   • Grey – Commissioning mode is disabled
   • Orange – Commissioning mode is active. Stay tuned for my next blog post about the advantages of using Commissioning mode.

4 – Check-In Functions

1. Check-in
   • Used to check in changes marked for check-in in your local session
   • This will bring up the check-in window (shown above) with various options for compiling before check-in (most certainly a best practice is to keep this enabled) as well as filtering your marked objects by conflict
2. Refresh Local Session
   • Used to pull in updates from the server
3. Edit Server Copy
   • This will allow you to edit the server copy, which Is required to make Hardware updates and check-in items with no flags like Technology Objects (See below)

5 – No Flags

As a rule of thumb – if an object does not have a flag next to it, this indicates that the object must be edited/added within the server copy of the project only. Any changes made on the server copy will require a refresh when complete and saved to be reflected in your local session.

Locked Server

One of the hurdles of working with MUS is what to do when a server gets locked while no one is actively editing it – which can happen any number of reasons including Portal crashing during a check-in or someone leaving their work station while editing the server copy. When this does happen, however, there are several ways to unlock a server.

From Multiuser Server Administration:

From Portal:

• Open the server project using the icon in the project tree, then close the server copy using the same icon
• Note: This can ONLY be done from the Local Session that was in use when the server was locked (See usage Information section).

Revision Control

MUS also has robust version control that can be used in case a rollback is needed. You can find in the MUS Administration. The options here include:

• Roll Back to the Selected Revision – This can only be performed when all local sessions are closed.
  • This will create a new head revision with the comment ‘Rollback to Revision X’
  • All local sessions will need to refresh to get the correct revision 

Usage Info

With all the concurrent work happening, MUS provides a quick and easy way to determine who’s making changes and where.

• Server Locked by another user
  • You can hover over the icon to determine who currently has the icon checked out which can be helpful when the server is inadvertently locked
• Block Flagged for check-in by another user
  • You can right-click the block in question and click ‘Usage Info’ to see who is editing that block
• Best practice when working in MUS (and this is particularly relevant for VM users) is to make sure your machine name is updated to something other than its default. Your computer name in windows is what MUS uses to designate the ‘Device’ under usage info.

Setup Tips

• For getting the server setup, please see our Quick Start Guide.

• When assigning a hostname, you can use either the generic server alias or the IP address of the server itself. While I’m not sure there is a real difference here, I’ve heard of cases where people have better luck connection when using the IP address, so if you’re having issues connecting to the server, it may be worth a try to change the host designation.

These tips and tricks are only a small snapshot of the features available in MUS but serve as a good starting place for troubleshooting common problems within Siemens Multiuser. If the problems you’re looking for are not covered here and you can’t find a suitable solution in the Siemens Manual, please don’t hesitate to contact DMC to help with your integration needs!

Learn more about our Siemens PLC Programming services as well as our partnership with Siemens.

The post Siemens Multiuser: Tips and Tricks appeared first on DMC, Inc..

This only takes about 10 minutes to set up and will save countless hours of merging programming whether offline or online.

This is a quick start guide on setting up the multiuser server locally. For more detailed information about how to set up the multiuser server, refer to the Siemens documentation: Multiuser Engineering in the TIA Portal.

For standard multiuser operation refer to our other blog, Leveraging Siemens MultiUser Engineering for TIA Portal.

And as always, please feel free to reach out to us for additional help!

Setting Up the Server

1. Open Multiuser Server V15 Configuration.

2. Select a location to store the multiuser server files under the “Storage” section.

   1. Note: It needs to be local, not on a network drive.

   2. If you’re in a Virtual Machine it needs to be local to the virtual machine, not a shared folder with your host.

3. All other items can be left as default.

4. Click “Install Service” (the screenshot shows “apply” there because I already installed it on mine).
    
5. Distribute the client info for other people to use to connect to your server. When you install the service it will also give you a list of other names for your server.
   1. Note: You’ll connect to the server just like everyone else will. So you’ll essentially connect to yourself using the same info.
       
6. Click “Start Service” to start the multiuser server. Every time you reboot your computer you will need to restart the service.

Connecting to the Multiuser Server

1. In TIA portal go to settings-> Multiuser and “Add server connection” in the list of projects.
    
2. Enter your server connection information.

3. Once the server is added you can go to Project -> Multiuser -> Manage multiuser server projects…
    
4. The window will have a drop-down for the different available servers. If yours is not already selected, select it from the drop-down. Then select the project you would like to work on and “create new local sessions” to start working on that project locally and contribute to other projects.

5. Please refer to our operations blog Leveraging Siemens MultiUser Engineering for TIA Portal for information about standard use of the multiuser server functions.

Set Up User Accounts

Some domains limit the HTTP connection and require users to connect using a secure connection, the https connection. To connect on https, you can use the same login credentials as the user who’s running the server, or go through these steps to set up new credentials:

1. Make a windows credentials user account on the same machine as the multiuser server under the windows control panel -> add or remove user accounts. This is the account that other users will use to access the server. Set them up as a Standard User, then set a password for them.
    
2. Under the TIA Portal Multi-User Server Administration, select the server (you may need to add it) and then User Management.
    
3. Add the new user as a contributor or manager, depending on how much control you want them to have.
   1. Manager = full access and control
   2. Contributor = partial access, no deleting
   3. Member = read-only

4. Then, change the server type to “https” on both the server configuration and connection information in TIA Portal. When other programmers try to connect to the server, they will be prompted for the credentials of the selected user account, e.g. MultiuserProgrammer.

Pro Tip:

• If you have to use a login, use the windows credential manager to store your login data! This way you won’t have to enter your login every time you connect to the multiuser server!

  • NOTE: This does not work within all domains!

If you’d like to learn more about DMC’s Siemens expertise and how we can help you improve your project efficiency, development, and effectiveness, check out our Manufacturing Automation & Intelligence Services.

The post Siemens Multiuser Server Local Host Setup Quick Start Guide appeared first on DMC, Inc..