Why Ring Topology?

There are many reasons why one might consider using a ring topology for your network. The most common one is to provide a semi-fault tolerant network that can handle the break or loss of any one leg of your network by utilizing redundant physical connection paths between network nodes. For a controls network, this can provide an additional layer of security and safety where machine availability is important. 

MRP (Media Redundancy Protocol) is a redundancy protocol supported by all Profinet capable devices that will allow a network to be configured in a ring topology. Since Profinet is an open standard, this means that MRP is a manufacturer independent protocol and can be used to form a ring with devices from different manufacturers (so long as all devices are fully IEC 62439 compliant). If you’re interested in the details of how it works, Wikipedia has a good and short overview.

In the example below, we will use MRP and the Network Topology tab to configure a ring topology for an automation network. While the most common scenario would be to add a switch into the mix (such as a SCALENCE switch), I don’t have one available for testing so I’m just going to use an S7-1516F-3PN PLC, S7-1510SP-1PN PLC, an IM155-6 PN remote I/O rack, and a 7″ Comfort Panel. All of these devices have at least 2 switched ports and support MRP which will allow us to configure a small ring. 

Step 1: Configure the Network Interfaces of All the Devices

In my project, I’ve already added all of my devices to my project. The first step will be to open up “Devices and Networks” to the Network tab and configure all of their interfaces. For this example, I’ll use the default IP addressing scheme. 

In your network view, connect the interfaces of all devices to create a common Profinet network. This will allow all of our devices to talk to one another. I’ve also added a DO card to my ET200SP I/O remote rack and created HMI connections for both PLCs to the TP700 Comfort Panel.

Step 2: Configure the Network Topology

While it’s possible to configure MRP without using topology, I find it makes it much simpler and aids in troubleshooting in the event of a network fault. To do this, navigate to the Topology tab of the “Devices and Networks” view.

Configure the topology to create a ring – I’ve used the port connections shown below, daisy chaining Port 2 from each device to Port 1 of the following and closing the loop back to the beginning.

Step 3: Configure MRP 

Within an MRP ring, each device must be assigned a role. One device will be the MRP Manager and will be responsible for sending out test frames to detect for a network failure and for blocking network traffic on one port (except for the test frames) to prevent a network loop. The other devices must be assigned a Client role so they know how to handle the test frames. 

In this example, I will use the S7-1516F-3PN as my Manager, and will set all other devices to be Clients. You can assign roles in several ways – the easiest way for me is to go to the Device View for each device and look at the properties of the network interface. Under “Advanced Options,” look for Media Redundancy. Here you can select a role for the device (Manager or Client) and enable diagnostics interrupts. If you choose to enable diagnostic interrupts for all devices, note that you can now detect the status of your MRP ring within your program from OB82. 

Step 4: Download and Configure All of the Devices

Start by first connecting all but one link of your network (don’t close off the ring just yet until all of the devices are configured to handle it). In my case, I daisy chained the S7-1516F, IM155-6, TP700 and S7-1510SP together without connecting the S7-1510SP back to the S7-1516F. Download to each PLC and the HMI, and set the Profinet name of the IM155-6. Now, you are ready to close the loop to create your MRP ring.

Step 5: Test

As a simple test, I enabled the Clock Bytes on both PLCs and configured the 1510SP to function as an I-Device. In my shared data area, I passed over the 1Hz Clock bit from the 1510SP to the 1516F PLC. Now, on the 1516F I added two simple rungs of logic to OB1 to pulse two outputs on the IM155-6PN – one pulsing from the 1Hz Clock bit of the 1516F and the other pulsing from the clock of the 1510SP. Finally, I added a System Diagnostics View to the HMI so I could monitor my network. 

After going online with the two PLCs (I’m connected through the third port on my 1510SP), I can verify on the Topology tab of “Devices and Networks” that my MRP ring is connected as configured. I can also watch the outputs on the remote I/O rack to verify that both outputs are pulsing as expected. 

Now let’s do some testing. Disconnect any one connection and verify that both outputs continue to function as expected. You can also note, from the integrated fault lights on the devices or from the Diagnostics Viewer on the HMI, that a downed network connection is detected and reported.

That’s about it – you now have a working MRP ring! I hope this is helpful! If you’re looking for help, please take a look at our Siemens PLC Programming Services or Contact Us today!

The post How to Set Up an MRP-based Ring Network in TIA Portal appeared first on DMC, Inc..

For OEM’s who produce and sell standard machines with a number of customer-selectable options, Configuration Control can allow a single project to be developed and maintained that is capable of supporting multiple options and configurations. The really cool part is that the hardware configuration can even be changed in the field without any program changes – even from an HMI.

The ability to change hardware configuration in the field allows an OEM to use a single program for every machine built while only using the hardware required for the options selected, which can help to lower hardware costs while still allowing for expansion and upgrades. Hardware can be added in the field, and options can be turned on/off from either a configuration screen on the HMI or even a license key that can be provided and entered.

If you haven’t worked with Configuration Control before, it’s worth noting that there are several different Configuration Control features available.

I’m going to highlight two of them: Configuration Control at the Device Level and Configuration Control for IO Systems.

Configuration Control at the Device Level

Within TIA Portal, Siemens provides the ability to configure, at run-time, the hardware modules used within an S7-1200, S7-1500, ET200SP Controller, or ET200SP (PN or DP) Remote I/O Rack. This means a single project can be created with a “Master Rack” configuration which defines a superset of all hardware that could be used and that a user can, at run-time, choose which modules to use and decide where in the rack they are located.

As a simple example, imagine a machine designed to batch and mix ingredients in a system of tanks. As a machine builder, you provide an option to your customers to add a temperature monitoring function. Some customers may feel this feature is worth the extra cost, but it is not a standard feature on every machine built. With Configuration Control, you can add a Thermocouple module to your rack and define the module as ‘Optional.’

Now, you can develop a single program which includes the temperature monitoring functionality and build the machine according to your customers’ selected options. If they choose to add temperature monitoring, you can include the Thermocouple module in your hardware rack and activate that option. If not, you leave it out. Either way, the software (and hardware configuration defined in it) are identical.

So how can you set up Configuration Control at the device level?

Let’s build a quick example. While we could use an S7-1200, S7-1500, or ET200SP I/O remote rack, I’m going to use an ET200SP Controller  (S7-1510 1-PN) as I have one sitting on my desk. Additionally, I have one (1) DI 8x24VDC ST and one (1) DQ 8x24VDC/0.5A ST module. So, let’s assume I want to design a system with four possible configurations:

• Option A: Both DI (Slot 2) and DQ (Slot 3) Modules
• Option B: DI Module Only (Slot 2)
• Option C: DQ Module Only (Slot 2)
• Option D: No Modules

Step 1 – Create a Master Rack
To start with, I’ve created a “Master Rack” in my hardware configuration containing all possible modules. The “Master Rack” should contain the maximum options available. In my case, it will include both the DI and DQ modules as shown below.

After adding the modules, go to the properties of the PLC and, under Configuration Control, check the box for “Allow to reconfigure the device via the user program.”

Step 2 – Create a Configuration Control Record
Create a PLC Data Type (UDT) to define the hardware configuration. This UDT will be structured as follows:

Byte 1: Block Length – the total number of bytes in the record. Header Length (4) + 2 * Number of Slots. In this example, there are four slots: Slot 1 is the CPU, Slot 2 is the DI module, Slot 3 is the DQ module, and Slot 4 is the server module. Note the default values I’ve given the UDT are the default positions assigned in the hardware configuration.

Byte 2: Block ID – The data record number being written. For configuring hardware in a rack, it is 196.

Byte 3: Version – This value is different depending on the type of hardware used. For the ET200SP, Version = 2. For an S7-1500, Version = 4. Additional documentation is available for both with help and online examples.

Byte 4: Subversion – Zero for the ET200SP.

Byte 5: Slot 1 – For the ET200SP Controller, the CPU is always in slot 1 (where it is configured).

Byte 6: Additional Function for Slot 1 – Zero for the ET200SP CPU.

Byte 7: Slot 2 – The value of this specifies where the module configured in the hardware configuration is installed. If the module is used in the station option, this will be the slot in which it is installed. If a module is not used, put a 0 here. If the module is configured to be empty, enter the slot number of the module + 128.

Byte 8: Additional Function for Slot 2 – If you replace a dark colored base unit with a light colored base unit (new potential group), enter 1. Enter 0 if the base unit installed in this slot matches the hardware configuration.

Byte 9: Slot 3

Byte 10: Additional Function for Slot 3

Byte 11: Slot 4 – in this example, the Server Module

Byte 12: Additional Function for Slot 4

Step 3 – Create Configuration Options
For this example, I’ve created a Global DB with an array of four (4) of the control records we just created and set values corresponding to the four possible configurations listed above.

Note in the first that each module matches the configuration. The second removes the DQ module and moves the Server module up. The third option removes the DI module and moves the DQ and Server modules up. The final configuration eliminates both the DI and DQ modules and moves the Server module up to Slot 2.

Step 4 – Add in OB100 (Start-up)
In the startup OB, you will need to write the configuration option record to define the hardware used.

To do this, you can use the code below. Notice that I’ve created an “Index” tag to switch between the different options I’ve configured. 

Step 5 – Configuration from HMI
There are many ways you could do this, but I’ve created a simple HMI screen to allow a user to select which hardware option to use.

It’s very simple – a selection of a configuration sets the “Index,” or a retained tag on the PLC, of the hardware option to be used.

Note that to switch hardware configurations, the PLC needs to be stopped and started so that OB100 is executed.

If you’re interested in learning more, Siemens provides a thorough system manual for the ET200SP Controller.

Configuration Control for I/O Systems

In addition to controlling the configuration (location and existence) of modules within a PLC or Remote I/O Rack, TIA Portal also provides the ability to configure an I/O system dynamically. This means you can create a “Master Configuration” with multiple remote I/O racks. You can then programmatically (at run-time) define the use and configuration of those racks.

As another simple example, consider a machine with modular components such as a multi-cell vacuum press. As a machine builder, you can create and offer a system capable of controlling, for example, anywhere from 2-8 cells. Each of those cells may have their own control panel and remote I/O rack.

With Configuration Control, you can develop a single project capable of controlling, for example, eight cells and define at runtime how many (and which) cells are in use. Furthermore, because it’s at runtime, your customer could choose to add an additional cell at a later date.

Because of Configuration Control, you could deliver the new cell, connect the I/O rack to the PLC, and then from the HMI activate the cell – all without making any software changes. By using a single project, the need for maintaining and supporting multiple versions of control code is eliminated allowing you to provide a flexible, modular, and scalable product without the need for troubleshooting and testing of each combination.

So how can you set up Configuration Control for IO Systems?

Let’s look at how simple it can be.

First of all, there are a number of ways in which we can set this up. The TIA Portal Help Files contain some excellent application examples.

Siemens product support also has application examples for the different options. But I’m going to configure an ET200SP Profinet I/O rack (IM155-6 PN HF) to be an optional I/O device. While simple to configure the hardware, it is slightly more complex from a programming perspective.

Step 1: Add an IM155-6 Rack to the Network Configuration
I added an ET200SP I/O rack with a single DI module. Under the properties of the interface module, expand the Profinet interface options and look under Advanced Options. Select “Optional IO-Device. This will define this device as optional and will only be used if programmatically added to the Profinet network.

Note that if booting a PLC without any special code to activate this network device, it will not be automatically added to the I/O network.

Step 2: Configure Topology
While we could do this in other ways, I’ve used Topology to simplify management of the Profinet network configuration for our Configuration Control demonstration. If you haven’t used Topology in the past, it is similar to your network configuration, but it defines specific port-to-port connections between devices.

These connections must match the exact ports used when the hardware is networked together. While adding some complexity, there are a lot of cool things you can do with Topology – including automatic assignment of Profinet name and IP Address. Here, it will allow us to create a simpler configuration record in the next few steps.

In this demo, I’ve defined a connection between P2 on the PLC and P1 on the IM155-6. I’ve left the others undefined – meaning they can use any network connection available.

Step 3: Create Network Configuration Options
In this example, I only have one optional device. So I will define two options: One with the IM155-6 and one without. The Control Records needed to reconfigure the I/O network are structured as follows:

Word 1 – Version: For reconfiguring the I/O system, this is 16#0100.

Word 2 – Number of Optional Devices to be used: The total number of optional devices that will be used in this configuration option.

Word 3 – Optional Device to Activate: the hardware identifier of the device to be activated (HW_DEVICE). You can find this in the system constants of the default tag table. For this example, it is 262.

Word 4 -> Word N-1: Optional Devices to Activate

Word N – Number of port interconnections: Since we already defined the network topology, this is 0.

For the two options (with and without the rack), my configuration records are shown below.

Note that I’ve used a generic struct to define the configurations. Also, note that I’ve added an empty word to the end of the second configuration (WithoutRack) even though it isn’t needed. It will be apparent why a little later.

Step 4: Write Logic to Reconfigure the I/O
The I/O network can be configured at any point without restarting the PLC, unlike the previous example of configuring hardware within a rack. It just requires three steps:

a) Call “ReconfigIOSystem” with Mode 1 to Deactivate all Optional I/O Devices.

b) Call “ReconfigIOSystem” with Mode 2 (and the configuration record) to Reconfigure/Activate the used I/O Devices.

c) Call “ReconfigIOSystem” with Mode 3 to Restart the I/O.

For this demo, I wrote a simple state machine to sequence through the three steps off of a start command (from the HMI). The user can select a configuration and restart as needed.

A Few Tricks Worth Nothing… 

Then I’ll leave you with some demo code.

First, the “ReconfigIOSystem” system function block requires writing the control record as an array of words.

We could have defined our Configuration Records as an array, but I liked the Struct better. However, we do need to take the selected configuration and move it into an array.

To do this, I created a static Array [0-3] of Words and a Struct CTRL_REC using an AT construct for the Array. Now I can move my Struct into CTRL_REC and still use the array of Words as the input to the block.

be foundSecond, the Logical Address used (LADDR) on the “ReconfigureIOSystem” call is the Hardware Identifier of the PROFINET interface of the IO controller. Again, this can be found in the system constants tab of the default tag list .

Finally, I played around with a few options (defining port connections vs. configured topology) and found the topology method easier to demonstrate. The other cool thing about this is that because the topology is defined, the IM155-6 PN does not need to be commissioned (Profinet name, IP Address assignment) in advance.

The PLC will automatically assign a Profinet name and IP Address and autoconfigure the rack wWhen the I/O system configuration is updated with the rack activated! You can test this be resetting the rack to factory default and then reconfiguring the network to activate it. You’ll notice that since the topology matches what was defined, the IP Address and Profinet Name will be automatically assigned and the rack will be auto commissioned and activated.

The Code

Here’s the code I used for my quick test. I am running this FB from OB1 and have buttons on the HMI for Starting/Resetting and selecting which configuration to use. This allows a user to, while the system is running, add or remove the remote I/O rack from the Profinet network.

I hope this is helpful! Thanks for reading!

For those of you who made it this far, I’ve attached a sample project for you if you’d like to try it yourself!

Learn more about DMC’s TIA Portal programming expertise or Contact Us to get started on a project today.

The post Optional Hardware Configuration Control in TIA Portal appeared first on DMC, Inc..

Oftentimes, I will find those settings and tricks in a great blog, application example or help file. Over the years, I’ve built up a personal library of links and documents that I reference whenever I come back to an issue that I know I’ve seen before and have forgotten how we fixed it in the past. Today I’d like to share one of these examples that I’ve relied upon several times when working with the S7-400H and programming HMI’s in WinCC Advanced or WinCC Comfort configuring automatic connection fail-over. 

If you’ve worked with TIA Portal and the 400H CPUs in the past, you probably know that Portal does not have any automatic fail-over mechanisms built in for WinCC Advanced or WinCC Comfort. Hopefully, when the S7-1500H is released, this functionality will be added as well. But for now, programming of the 400H system is completed in Step 7 v5.5; the station must be imported into Portal as a Proxy, and any connection fail-over must be manually added. Luckily, Siemens provides a great Application Example to make the process easier. Nothing I’m sharing below is secret; you can easily learn from this information. Yet for anyone who has already found this blog, I’ll walk you through configuring WinCC Advanced or WinCC Comfort to work with a redundant pair of S7-400H CPUs and automatically handle connection failover.

Step 1: Import your 400H system into TIA Portal

TIA Portal does not support programming of the 400H inside the Portal, but you can easily import a station from a Step7 v5.5 project into the Portal to make things easier. To do so, choose “Add a New Device”, select the type as “Controller,” and pick “Device Proxy.” 

After the new station has been added to the Project, right-click the station in the project tree (or from Device View) and choose “Initialize Device Proxy.” Navigate to and select your Step7 v5.5 project and it will open a new dialog to allow you to choose which source device and what data you would like to add to your Proxy Station. 

Step 2: Add your HMI

For the purpose of this demo, I will add a Comfort Panel to my project. But you can do the same with an Advanced Runtime application.

Step 3: Create a Connection to the PLC Station

Open up the hardware configuration (network view) and add an HMI connection from your Proxy Station to the Comfort Panel. If you open up the Connections Editor from the HMI Project (in the Project Tree), you will see that a connection has automatically been created for you. I’ve renamed this Connection to “CPU_400H” and this will be the connection that we configure to switch been CPU’s (failover). This is the connection that will be used for all tags used for visualization and control on the HMI.

What we will do, in order to provide automatic failover, is create three primary connections. The first will be a dynamic connection, capable of pointing to either processor in the redundant pair. We will use scripting and the control function “ChangeConnection” to switch the connection when a loss of communication is detected. All tags used for display on the HMI will use this connection. The other two connections will be static connections to each CPU for monitoring connection status.

Step 4: Create Additional Connections to Each CPU

Next, we will create dedicated connections to each CPU. These connections will each be looking at a different CPU. Note that the two connections are configured for different CPU’s in the redundant pair (IP Address, Slot, Rack). 

Step 5: Create Connection Monitoring Tags

We will create two heartbeat tags, ‘CPU_0_Trigger‘ and ‘CPU_1_Trigger‘ – one for each CPU – and monitor them through the dedicated connections to the CPUs. Note that both trigger tags are looking at the same tag (in this case, at DB110.DBX429.3), but on different CPUs. That tag on the PLC is a heartbeat tied to the Clock Byte (1 Hz). Also, note that we’ve changed the tag acquisition mode to be Cyclic Continuous so that it will be constantly monitored for changes.

Additionally, create three internal tags: ‘CPU_0_ConnectionState‘ and ‘CPU_1_ConnectionState‘ (both Integer tags used to keep and store an internal connection state) and ‘CPU_ConnectedTo‘ (a WString tag used to track which CPU we’re using for our active connection and can be displayed on the HMI). 

Step 6: Add Connection Monitoring Scripts

Create three new scrips: (1) CPU_O_Trigger, (2) CPU_1_Trigger, and (3) CPU_Connection. You can grab the scripts from the Siemens application example and edit as needed. But these scripts will do the following:

1. CPU_0_Trigger: Will be triggered on a tag change of ‘CPU_0_Trigger.’ On a heartbeat signal from CPU_0, it will reset ‘CPU_0_ConnectionState‘ to 1, and will increment ‘CPU_1_ConnectionState‘. If ‘CPU_1_ConnectionState‘ ever exceeds our connection fault limit and our HMI Connection CPU_400H is currently assigned to connect to CPU_1, it will swap the connection to CPU_0.

Sub CPU_0_Trigger()

    Const IP_Address = "192.168.1.10"

    ' Initialize active connection
    If SmartTags("CPU_ConnectedTo") = "" Then
        SmartTags("CPU_ConnectedTo") = "CPU-0"
    End If

    ' Reset CPU-0 watchdog
    SmartTags("CPU_0_ConnectionState") = 1

    ' Increment CPU-1 watchdog counter
    If SmartTags("CPU_1_ConnectionState") <= 10 Then
        SmartTags("CPU_1_ConnectionState") = _
            SmartTags("CPU_1_ConnectionState") + 1
    End If

    ' Switch to CPU-0 if CPU-1 has failed
    If SmartTags("CPU_1_ConnectionState") >= 11 Then

        If SmartTags("CPU_ConnectedTo") = "CPU-1" Then

            ChangeConnection "CPU_400H", IP_Address, 3, 0

            SmartTags("CPU_1_ConnectionState") = 100
            SmartTags("CPU_ConnectedTo") = "CPU-0"

        ElseIf SmartTags("CPU_ConnectedTo") = "CPU-0" Then

            SmartTags("CPU_1_ConnectionState") = 100

        End If

    End If

    ' Reintegrate after a complete communication loss
    If SmartTags("CPU_ConnectedTo") = "Connection Lost" Then

        ChangeConnection "CPU_400H", IP_Address, 3, 0

        SmartTags("CPU_1_ConnectionState") = 100
        SmartTags("CPU_ConnectedTo") = "CPU-0"

    End If

End Sub

Sub CPU_0_Trigger()

    Const IP_Address = "192.168.1.10"

    ' Initialize active connection
    If SmartTags("CPU_ConnectedTo") = "" Then
        SmartTags("CPU_ConnectedTo") = "CPU-0"
    End If

    ' Reset CPU-0 watchdog
    SmartTags("CPU_0_ConnectionState") = 1

    ' Increment CPU-1 watchdog counter
    If SmartTags("CPU_1_ConnectionState") <= 10 Then
        SmartTags("CPU_1_ConnectionState") = _
            SmartTags("CPU_1_ConnectionState") + 1
    End If

    ' Switch to CPU-0 if CPU-1 has failed
    If SmartTags("CPU_1_ConnectionState") >= 11 Then

        If SmartTags("CPU_ConnectedTo") = "CPU-1" Then

            ChangeConnection "CPU_400H", IP_Address, 3, 0

            SmartTags("CPU_1_ConnectionState") = 100
            SmartTags("CPU_ConnectedTo") = "CPU-0"

        ElseIf SmartTags("CPU_ConnectedTo") = "CPU-0" Then

            SmartTags("CPU_1_ConnectionState") = 100

        End If

    End If

    ' Reintegrate after a complete communication loss
    If SmartTags("CPU_ConnectedTo") = "Connection Lost" Then

        ChangeConnection "CPU_400H", IP_Address, 3, 0

        SmartTags("CPU_1_ConnectionState") = 100
        SmartTags("CPU_ConnectedTo") = "CPU-0"

    End If

End Sub

2. CPU_1_Trigger: Will be triggered on a tag change of ‘CPU_1_Trigger.’ On a heartbeat signal from CPU_1, it will reset ‘CPU_1_ConnectionState‘ to 1, and will increment ‘CPU_0_ConnectionState‘. If ‘CPU_0_ConnectionState‘ ever exceeds our connection fault limit and our HMI Connection CPU_400H is currently assigned to connect to CPU_0, it will swap the connection to CPU_1.

Sub CPU_1_Trigger()

    '***************************
    '**** Initialization ****
    '***************************

    Const IP_Address = "192.168.1.11"

    ' During initialization the default connection
    ' is stored in CPU_ConnectedTo.
    If SmartTags("CPU_ConnectedTo") = "" Then
        SmartTags("CPU_ConnectedTo") = "CPU-0"
    End If


    '*******************
    '**** Reset ****
    '*******************

    ' Reset CPU-1 connection watchdog
    SmartTags("CPU_1_ConnectionState") = 1


    '*****************************
    '**** Fault Detection ****
    '*****************************

    ' Increment CPU-0 watchdog
    If SmartTags("CPU_0_ConnectionState") <= 10 Then
        SmartTags("CPU_0_ConnectionState") = _
            SmartTags("CPU_0_ConnectionState") + 1
    End If


    '**************************
    '**** Switch Over ****
    '**************************

    If SmartTags("CPU_0_ConnectionState") >= 11 Then

        If SmartTags("CPU_ConnectedTo") = "CPU-0" Then

            ChangeConnection "CPU_400H", _
                             IP_Address, _
                             3, _
                             1

            SmartTags("CPU_0_ConnectionState") = 100
            SmartTags("CPU_ConnectedTo") = "CPU-1"

        ElseIf SmartTags("CPU_ConnectedTo") = "CPU-1" Then

            SmartTags("CPU_0_ConnectionState") = 100

        End If

    End If


    '***************************
    '**** Reintegration ****
    '***************************

    If SmartTags("CPU_ConnectedTo") = "Connection Lost" Then

        ChangeConnection "CPU_400H", _
                         IP_Address, _
                         3, _
                         1

        SmartTags("CPU_0_ConnectionState") = 100
        SmartTags("CPU_ConnectedTo") = "CPU-1"

    End If

End Sub

Sub CPU_1_Trigger()

    '***************************
    '**** Initialization ****
    '***************************

    Const IP_Address = "192.168.1.11"

    ' During initialization the default connection
    ' is stored in CPU_ConnectedTo.
    If SmartTags("CPU_ConnectedTo") = "" Then
        SmartTags("CPU_ConnectedTo") = "CPU-0"
    End If


    '*******************
    '**** Reset ****
    '*******************

    ' Reset CPU-1 connection watchdog
    SmartTags("CPU_1_ConnectionState") = 1


    '*****************************
    '**** Fault Detection ****
    '*****************************

    ' Increment CPU-0 watchdog
    If SmartTags("CPU_0_ConnectionState") <= 10 Then
        SmartTags("CPU_0_ConnectionState") = _
            SmartTags("CPU_0_ConnectionState") + 1
    End If


    '**************************
    '**** Switch Over ****
    '**************************

    If SmartTags("CPU_0_ConnectionState") >= 11 Then

        If SmartTags("CPU_ConnectedTo") = "CPU-0" Then

            ChangeConnection "CPU_400H", _
                             IP_Address, _
                             3, _
                             1

            SmartTags("CPU_0_ConnectionState") = 100
            SmartTags("CPU_ConnectedTo") = "CPU-1"

        ElseIf SmartTags("CPU_ConnectedTo") = "CPU-1" Then

            SmartTags("CPU_0_ConnectionState") = 100

        End If

    End If


    '***************************
    '**** Reintegration ****
    '***************************

    If SmartTags("CPU_ConnectedTo") = "Connection Lost" Then

        ChangeConnection "CPU_400H", _
                         IP_Address, _
                         3, _
                         1

        SmartTags("CPU_0_ConnectionState") = 100
        SmartTags("CPU_ConnectedTo") = "CPU-1"

    End If

End Sub

3. CPU_Connection: This script will be configured to run as a scheduled task. Its purpose is a backup of the heartbeat/triggers. If no heartbeat triggers have been received from a CPU, it will disable the connection. If both connections are disabled, it will set the Connected CPU to “Connection Lost.”

Sub ConnectionCheck()

    '***************************
    '**** Deactivation ****
    '***************************

    ' If a connection has not reset its status tag
    ' back to 1, mark it as disabled.
    If SmartTags("CPU_0_ConnectionState") >= 5 Then
        SmartTags("CPU_0_ConnectionState") = 100
    End If

    If SmartTags("CPU_1_ConnectionState") >= 5 Then
        SmartTags("CPU_1_ConnectionState") = 100
    End If

    ' If both connections are disabled,
    ' indicate total communication loss.
    If SmartTags("CPU_0_ConnectionState") = 100 _
       And SmartTags("CPU_1_ConnectionState") = 100 Then

        SmartTags("CPU_ConnectedTo") = "Connection Lost"

    End If


    '********************************
    '**** Setting Fault Flag ****
    '********************************

    ' Every cycle, set the status tags to 5.
    ' The CPU trigger scripts must reset them to 1.
    If SmartTags("CPU_0_ConnectionState") < 5 Then
        SmartTags("CPU_0_ConnectionState") = 5
    End If

    If SmartTags("CPU_1_ConnectionState") < 5 Then
        SmartTags("CPU_1_ConnectionState") = 5
    End If

End Sub

Sub ConnectionCheck()

    '***************************
    '**** Deactivation ****
    '***************************

    ' If a connection has not reset its status tag
    ' back to 1, mark it as disabled.
    If SmartTags("CPU_0_ConnectionState") >= 5 Then
        SmartTags("CPU_0_ConnectionState") = 100
    End If

    If SmartTags("CPU_1_ConnectionState") >= 5 Then
        SmartTags("CPU_1_ConnectionState") = 100
    End If

    ' If both connections are disabled,
    ' indicate total communication loss.
    If SmartTags("CPU_0_ConnectionState") = 100 _
       And SmartTags("CPU_1_ConnectionState") = 100 Then

        SmartTags("CPU_ConnectedTo") = "Connection Lost"

    End If


    '********************************
    '**** Setting Fault Flag ****
    '********************************

    ' Every cycle, set the status tags to 5.
    ' The CPU trigger scripts must reset them to 1.
    If SmartTags("CPU_0_ConnectionState") < 5 Then
        SmartTags("CPU_0_ConnectionState") = 5
    End If

    If SmartTags("CPU_1_ConnectionState") < 5 Then
        SmartTags("CPU_1_ConnectionState") = 5
    End If

End Sub

Step 7: Configure Scripts to be Executed

The CPU_0_Trigger script will be executed off of a value change event of the tag ‘CPU_0_Trigger‘. In the properties of the tag, configure a Value Change event to call the script CPU_0_Trigger. For the tag ‘CPU_1_Trigger,’ add the same Value Change event to call the script CPU_1_Trigger.

For the ConnectionTest script, add a new Scheduled Task to run once per minute. 

That’s it. Now if a CPU goes down, the lost heartbeat will cause the connection to fail-over to a working connection. These scripts are fairly generic. If you need a faster response rate you can change the heartbeat speed, the tag acquisition cycle, and the limits allowed before fail-over. It’s not a hardware solution and it is not instantaneous, but it will allow a Comfort Panel or WinCC Advanced HMI to work with a redundant 400H PLC system!

Thanks!

The post Automatic HMI Connection Fail-over in TIA Portal with the S7-400H appeared first on DMC, Inc..

We can also offload the motion control to the drive control unit using Siemens’ library motion blocks such as SINA_POS and allow the PLC to control more drives. The Siemens library motion blocks are also available for S7-300 PLCs, which do not support the same Technology Objects as S7-1500 PLCs.

How to Do Motion Control with SINA_POS

1. Add the DO Servo Module to the control unit.

   

2. Add Telegram 111. 

   

3. For a 1200 or 1500 CPU note the HW identifier in the System Constants when Telegram 111 is selected. For a 300 or 400 CPU note the I address and Q address.

   1200/1500

   

   300/400

   

4. In the Global Libraries find the EPOS function blocks.

   

5. Pull the desired motion block into your code. In this case, we created fbPositionAxis and we pulled in SINA_POS. We made SINA_POS a Multiple instance block so that it will be static memory in fbPositionAxis.

   

6. I added a few inputs to the fbPositionAxis function block to simplify the Axis control. I chose to include basic jogging, absolute moves, setting a zero home position, and interrupting a move with the fast stop.

   

7. Based on the inputs to fbPositionAxis I set the ModePos input of SINA_POS. You can see how I use the other inputs and the axis status to control the axis.

   

A few important points:

• The Velocity input of SINA_POS affects the absolute position move, but it does not change the speeds of Jog1 or Jog2. Those parameters must be changed in the STARTER/SCOUT configuration or by using the SINA_PARA or SINA_PARA_S function blocks.
• My example above only uses 3 of the 8 SINA_POS operating modes, so there are functions that this example does not demonstrate.
• SINA_POS uses Telegram 111 whereas SINA_SPEED uses Telegram 1.

Learn more about DMC’s Siemens PLC programming services. 

The post Siemens Decentralized Motion Control with SINA_POS appeared first on DMC, Inc..

If you're attending the Oil and Gas conference, stop by DMC's booth and don't miss the three presentations we'll be leading.

Using TIA Portal and the S7-1200 for Simplified, Distributed Control – Jason Mayes
PATCO Machine and Fab, Inc., a Houston based machine design and fabrication facility specializing in oilfield products, recently patented the world’s first automated electro-pneumatic Hose and Cable Reel Management Control System for use on offshore drilling ships. DMC worked with AWC Inc. and PATCO to design and implement an ATEX/IECEx Zone 1 rated, Siemens based, distributed control system. By leveraging the tools available in TIA Portal, DMC was able to deliver a flexible, expandable, and cost-effective automation solution that will allow PATCO to better serve their clients. In this session we’ll discuss the advantages and differentiators that made Siemens the best choice as an automation platform.

Decreased Cost, Increased Performance of a LACT Skid Using the S7-1200 – John Sullivan
Why would an OEM that has been installing the same hardware for a long time would want to switch? The answer is always the same: to reduce the cost. The existing LACT skid was utilizing a MicroLogix PLC and PanelView HMI, and when oil prices significantly decreased, management was looking to reduce overall costs of each machine, and the S7-1200 and Comfort Panel appeared to be most cost-effective.

This presentation will cover the features of a LACT Skid. We will discuss some of the strategies of conversion, as well as ways to decrease the cost and increase return on investment.

Powerful SCADA Solutions: Is WinCC Open Architecture Right for Me? – John Sullivan
WinCC OA is a step away from traditional SCADA and has a variety of added benefits. This is especially true when it comes to geographically distributed oil and gas applications, as well as infrastructure applications. WinCC OA uses an open architecture with object oriented concepts, is SIL 3 Certified, and provides nearly unlimited scalability with seamless redundancy. This presentation will cover some advantages and cases of use for WinCC OA in oil and gas applications. It will also help identify areas where WinCC OA can provide a strong benefit over traditional SCADA systems. Specific case study examples will be presented and parallels will be drawn to solutions that could be provided in the oil and gas industry.

Learn more about DMC's Oil and Gas solutions.

The post DMC to Present at Siemens Oil & Gas Conference appeared first on DMC, Inc..

The goal of the day-long event on July 28 was to promote discovery and discussion around the Oil and Gas industry's emerging automation and controls trends. All the presentations were well attended, offering a great opportunity to network in the area and learn about developing Oil and Gas technologies. 

My presentation, Powerful SCADA solutions: Is WinCC OA right for me?, demonstrated use cases for Siemens WinCC OA in Oil and Gas applications. The audience was excited by the idea of putting more configuration tools in the hands of their operators without having an integrator onsite. 

Check out my presentation below and feel free to contact me at james.condon@localhost with any questions.

The post WinCC OA Presentation at the Rocky Mountain Oil and Gas Conference appeared first on DMC, Inc..

Siemens’ mobile showcase will be stopping by Denver on July 28 for the Rocky Mountain Oil and Gas Conference. This free event offers a day of discovery and dialogue on the latest emerging trends around automation, instrumentation, and controls for the Oil and Gas industry. Register here. 

If you’re planning to attend the conference stop by DMC’s booth and don’t miss my presentation: Powerful SCADA solutions: Is WinCC OA right for me?

WinCC OA is a step away from traditional SCADA and has a variety of added benefits. This is especially true when it comes to geographically distributed oil and gas applications, as well as infrastructure applications. WinCC OA uses an open architecture with object-oriented concepts, is SIL 3 Certified, and provides nearly unlimited scalability with seamless redundancy. This presentation will cover some advantages of and present use cases for WinCC OA in oil and gas applications. It will also help identify areas where WinCC OA can provide a strong benefit over traditional SCADA systems. Specific case study examples will be presented, and parallels will be drawn to solutions that could be provided in the oil and gas industry.

I’ll be presenting on July 28, 2015 at 10:30 a.m. in Grand Mesa F. I hope to see you in Denver!

Learn more about DMC’s Wincc OA services.

The post DMC to Present at the Rocky Mountain Oil and Gas Conference appeared first on DMC, Inc..

DMC opened a Houston office this year, making this conference especially valuable. Ryan Taylor and I spent a day at the conference learning more about Oil and Gas technologies, including jackup rigs and underwater ROVs.

We also had the opportunity to volunteer manning National Instruments’ booth at the conference along with other NI Alliance Partners. This was a great way to learn more about NI’s presence in Houston and meet the people who work with NI’s Texas team.

Our partners from Siemens were also represented at the conference. Ryan and I spent some time stopping by the Siemens booth to say hello and enjoyed margaritas with our Siemens friends at their Cinco de Mayo networking event. 

Overall, the OTC was a fun way to network with our existing partners and get a further introduction to the Oil and Gas industry and our Houston neighbors.

The post DMC Attends 2015 Offshore Technology Conference appeared first on DMC, Inc..

Since DMC opened an office in Houston this year, the conference was a perfect opportunity to meet more people in the area. Jason Mayes and I attended and had a great time connecting with partners and distributors. We attended a presentation every session and found the conference to be an insightful introduction to the area.

I had the privilege of delivering a presentation titled Improving and Scaling SCADA Systems: Is WinCC OA Right for Me? The presentation covered a case study from a DMC distributed architecture project that was a good use case for WinCC OA. For our project, we did this with generators. The presentation paralleled these features as they would apply to similar features within Oil & Gas. I shared how our WinCC OA application might apply to distributed well sites, frack site trucks and skids, and pipelines. 

View the slide deck from my presentation below and feel free to contact me with any questions.

Learn more about DMC's Oil and Gas Engineering services.

The post DMC Presents at the 2015 Siemens Oil & Gas Conference appeared first on DMC, Inc..