However, Openness offers many advantages that can lead to more efficient code creation. One of the best uses of Openness is for creating modular code that can be used across many devices, with application-specific changes being made automatically. By defining some base templates, you can allow users to generate entire projects without any knowledge of PLC and HMI programming.

How does Openness Work? 

There are two main parts of any Openness project:

1. The C# .NET application that provides the interface to TIA Portal
2. The XML files that are used to create code in TIA Portal

I’ll cover the details of the XML files in a later blog post; for now, we’ll focus on the C# .NET application. All you need to get started is to add the two .dll files that Siemens provides as references to your C# .NET project. These files provide the variable types and methods needed to work with TIA Portal.

The API provides a wide range of functions; from simple actions like compiling a project to creating and configuring technology objects on a PLC. While there are some functions that cannot be done through Openness, most common operations are available, and more are added with every new release.

In order to see what functions are available and how to use them, open up the Help Viewer (shown below) within TIA Portal, and find the section titled “Automating projects with scripts”. This section contains documentation on the various methods available. Each entry also includes simple code examples. The “Public API” and “Export/Import” sections are where the majority of these examples are located.

Advantages of Openness

At this point, you might be thinking “That sounds pretty nice, but how is this more useful than just programming in TIA Portal?” The main answer is scalability. Using Openness allows a user to automate time-consuming and tedious processes when working on a project. For example, your company may require a standardized code architecture for PLC projects. If that standard is replicated in Openness, one click could create the project, set up the architecture, add standard blocks from custom libraries, and add all the necessary GSD files.

If a project is being created for multiple, mostly identical machines, Openness can simplify creating each specific project. Openness can create a base project, and then only the individual differences need to be implemented. If the differences between the machines are well defined, Openness can further simplify development. A custom application can provide the user with a list of different modules that are assigned to a specific machine. Openness would then be able to create the base project and add in any extra modules that have been defined. With this custom application, any changes to the code are only made in one place and can be easily redeployed.

Disadvantages of Openness

Openness is a very powerful tool and opens up many possibilities for custom applications. However, there are some cases where it does not make sense to use Openness. Since Openness uses XML files to generate objects and code, it requires becoming familiar with the Openness XML tags and structures.

As we will discuss later, these XML files quickly become very large and complicated and require extensive expertise to be able to create and read them. Creating the XML from scratch is a long and difficult process, so it is generally preferred to create your necessary elements in TIA Portal, export them to XML, and use that as a starting point.

Conclusion

As I explained, Openness is a great tool for creating scalable and module code for TIA Portal. While it has a steeper learning curve than working exclusively in TIA Portal, it offers a large amount of flexibility and customization. If you find yourself creating similar projects on a regular basis, it is worth taking a look at how Openness can help you automate your process. In my next blog post, we’ll look at how to make sense of Openness’s XML files.

Learn more about DMC’s PLC Programming Services and TIA Portal Development Services. Contact us for help with your next project. 

The post Advantages & Disadvantages of Siemens’ TIA Openness appeared first on DMC, Inc..

1. Are the rack switches correct?

If you have no idea what I'm talking about, good news, this might be it! Take the second PLC off Rack 1 and look for an exposed switch on the back. Change it so it says "Rack 1" instead of "Rack 0". The default setting of the switch is "Rack 0". Below is roughly where to look. 

2. Is your addressing correct?

Isolate each PLC from the network and make sure you can ping it, and assign the IP address if you can't ping them. Also check that the Profibus address settings are correct on IO devices. You will need to powercycle your IO if you changed the Profibus address.

3. If you have Profibus connections,

make sure the terminating resistors are ON at the start and end of the communication line. If you're using "daisychain"/"piggyback" style connectors you have the "IN" slot filled with the wire for incoming communication and only use the "OUT" if you're connecting devices further down on the daisy chain. 

4. Check those part numbers again.

Not just the PLC, and IO rack info, but also the bus modules on your IO rack if you have one. It's under the DP Slave properties on your hardware config, "Operating parameters". On your system, you'll have to remove the IO modules to see the bus modules behind them. Below shows the properties tab you're looking for. 

5. Is your load memory ok?

If you have too much on your program, the PLC might need a memory card. Check the load memory of your program by right clicking the blocks folder and looking at the User Program + Data Memory. Compare this to the PLC you have and the default load memory it has. Below shows how to check the block folder properties, and where the memory card would be if you have one. 

6. Check that the fiber connection between the PLCs is correct.

Top on PLC 1 to top on PLC 2, bottom on PLC 1 to bottom on PLC 2.

If this still doesn't help your PLC switch to all green lights, go through the rest of the basics if you already have not which includes checking the diagnostic buffer for information, checking cables, making sure licensed blocks are licensed, waiting >5 min after startup to be sure both are synchronized, etc. 

Learn more about DMC's PLC programming expertise.

The post 6 Things You Should Know When Commissioning a SIMATIC S7-400 PLC appeared first on DMC, Inc..

As happens in the development process, we slowly improved the DrinkBot over time. We started displaying it at career fairs in Colorado to help grow the team. We also took it to events in New York, Houston, Seattle, and Manufacturing in America in Detroit. For now, the DrinkBot’s home in DMC’s Denver office ready to entertain visitors as we give tours.

The DrinkBot is an excellent tool for highlighting multiple factory automation technologies offered by DMC while serving a variety of drinks – anything from cocktails to Italian sodas. We could have simplified the DrinkBot, but its intention was to show off a bunch of cool capabilities and to demonstrate a lot of DMC and the Siemens S7-1200 platforms’ potential uses and abilities.

DMC’s DrinkBot utilizes a Siemens S7-1200 PLC, 7″ Comfort Panel, Siemens G120, and Siemens 1FK7 Servo Motor with DRIVE-CLiQ encoder to control the operation. The DrinkBot provides eight different alcohols or syrups and six different mixers for a large variety of drink options. Without further ado, let me dig into each part!

The Brain

The brain of our bot is a Siemens S7-1200 PLC (Programmable Logic Controller). Compact and inexpensive, the controller is capable enough to control all the motion axis, valves, and other organs. We used the Siemens S7-1215, which has more than enough onboard IO to manage the entire process. It controls six valves for drink mixers, a solenoid valve for alcohol dispensing, a variety of sensors to ensure everything is in the right place, PTO (Pulse Train Output) output to move the rotary access (which selects the alcohol), and ProfiNET Communication to the G120 to control the linear axis.

The Body

The DrinkBot also has two limbs powered by servo motors. The spinney one with bottles is controlled with a PTO and is utilizing built-in IO on the S7-1200.

It works like this: the PLC generates a precisely-timed sequence of high-speed step/direction pulses for the motor controller to get to an exact position at the right speed. Thanks to the accurate position control, our DrinkBot never spills your drinks or creates a mess.

The other limb is used to move your cup around. A VFD (Variable Frequency Drive) controls this limb. It talks to the bot’s brain over a standard protocol called PROFINET. VFDs are usually used to control simple AC motors, but the DrinkBot’s is better because it is using the Siemens G120 for full closed-loop position control! Rather than a standard AC motor, it controls a full servo motor with DRIVE-CLiQ encoder feedback!

The Faces

The only way you can tell that our DrinkBot isn’t human is by looking at its face – it has two of them! 

The one with lit buttons is a Siemens SIMATIC HMI key panel. It is an inexpensive device that provides ordering options utilizing PROFINET and is very convenient for ordering drinks with the single push of a button! It also has multi-color buttons that are used to create a light show. In an industrial environment, this HMI can look a lot more serious.

The other face with a fancy graphical screen is a 7″ SIMATIC Comfort Panel. It stores the drink recipes and allows you to choose from a large variety of preselected options or to create your own with whatever ingredients you prefer. 

Additionally, it provides the ability to manually move all pieces of the DrinkBot so that we can fix and identify issues caused by shipping. It utilizes advanced scripting to allow for a wide variety of dynamic buttons, letting the most popular recipes be displayed first, enabling us to move the display location different drink recipes quickly.

Here it is in action:

Summary of Technology

• Siemens S7-1200 PLC
• Siemens 1FK7 Servo Motor
• Siemens G120 VFD
• SIMATIC Comfort Panel
• TIA Portal
• WinCC Comfort
• Custom Panel built by Palmer DCS

To see how we can help you get started on a project, check out our Siemens PLC programming services and contact us today!

Learn more about DMC’s partnership with Siemens.

The post DMC Engineers Serve up a Siemens S7 Powered DrinkBot appeared first on DMC, Inc..

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..

Unfortunately, our client didn’t have TIA Portal software available at the time. They were afraid that this made it impossible to download the new version of the code to the PLC in the field.

Fortunately, Siemens offers the SIMATIC Automation Tool as a free download (just sign up for an account first) on their website. The SIMATIC Automation Tool was perfect for our client’s situation. It allowed them to seamlessly download the updated PLC code and commission the machine on schedule. 

This blog will walk you through the entire process of downloading a new PLC program to an S7-1200 or S7-1500 CPU using the SIMATIC Automation Tool.

First, you will learn how to connect a computer to the same network as the PLC. I will then show you how to save the PLC program in a format that the SIMATIC Automation Tool can use. Next, I will walk through using the SIMATIC Automation Tool itself. Finally, I’ll review some of the other capabilities of the SIMATIC Automation Tool. 

0. Connect your computer to the same network as the PLC

Connect an Ethernet cable directly from the S7-1200 or S7-1500 PLC to your computer. Next, set your computer’s IP address to be on the same network as the PLC. In order to do this, click the Start button and search for Network and Sharing Center. Open the Network and Sharing Center. On the left, there should be an option that says Change Adapter Settings. Click that.

Now you should see a connection that says Ethernet or Local Area Connection. Double click on it.

In the dialog box that opens, click Properties

In the next dialog box that comes up, there will be an option that says Internet Protocol Version 4 (TCP/IPv4). Double click on this option. 

In the next dialog box, select Use the Following IP Address. You need to enter an IP address that is on the same network as the PLC you are going to connect to.

This means the first three numbers of your computer’s IP Address must be the same as the first three numbers of the PLC’s IP Address. In this case, our PLC IP Address is 192.168.0.1, so we assign our computer to be 192.168.0.100. In the subnet mask field, 255.255.255.0 is typically used. Click ok.

1. Generate the S7S File using TIA Portal

In order to download to a PLC using the SIMATIC Automation Tool, you need the PLC program in an S7S File Format. Whoever wrote the PLC program should follow these steps using TIA Portal to generate the S7S File for you to use.

First, map a file directory on the TIA Portal computer to a Card Reader/USB Memory location. To do this, open the PLC project in TIA Portal and click Project -> Card Reader/USB Memory -> Add user-defined Card Reader:

Select your desired file location in the dialog box that follows. 

Once you have mapped the Card Reader/USB Location, select the PLC in the project tree.

Then click Project -> Card Reader/USB memory -> Write to memory card…

Select the file location you mapped earlier and press the green check mark.

Click Load: 

Send the resulting S7S File to the computer that is running SIMATIC Automation Tool.

2. Using the SIMATIC Automation Tool 

On the SIMATIC Automation Tool computer, save the S7S File in the following directory: 

C:\ProgramData\Siemens\SIMATIC Automation Tool\Programs

In our situation, DMC simply emailed the S7S file to our client and they saved it in the proper location on their computer. 

Now that your computer is connected to the same network as the PLC and the new program is saved in the correct location, launch the SIMATIC Automation Tool.

Scan for the PLC by clicking Network -> Scan: 

If everything is configured correctly, you will find the PLC and the SIMATIC Automation Tool should look like this: 

Now select the Program Update Tab. In the Program Update area, open the dropdown and you should see the name of the folder that you saved the S7S File in. Select that: 

Now check the box next to the PLC, and then select Network -> Download: 

The program will take a minute or two to download to the PLC. Once it is done downloading, the PLC will be in STOP mode. To put the PLC back into RUN mode, select Network -> RUN.

The PLC should now be running the newest version of the program! 

3. Other Functions of the SIMATIC Automation Tool

According to the Siemens website, the SIMATIC Automation Tool can also perform the following functions: 

• Assign addresses (IP, subnet, gateway) and station name (PROFINET device)
• Set the time in a CPU to the current time in your PG/PC
• Backup/Restore CPU data to/from a backup file (no failsafe)
• Flash the lights on a CPU to help physically locate the CPU
• Upload fault information from a CPU
• Read the diagnostic log from a CPU
• Reset a CPU to factory default settings
• Update firmware in a CPU and attached modules

These functions make the SIMATIC Automation Tool a useful asset for any facility running an S7-1200 or S7-1500 PLC. It allows you to perform basic maintenance functions in a simple interface. 

Learn more about DMC’s PLC Programming services and contact us to get started on your next PLC Programming project.

The post How to Update a Siemens PLC without TIA Portal using the SIMATIC Automation Tool 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..

1. Hardware Setup

   In this particular situation, we used an S7-400H PLC to control a CU240E-2 VFD. The S7-400H can be configured with two CPUs in a fully redundant PLC setup, but in this situation we only used one S7-400H CPU. The S7-400H is not available in TIA Portal, so we used Simatic Manager and Scout/Starter* to communicate with the PLC and VFD over ProfiNET.

   *Note: Before you commission a drive in Scout or TIA Portal, make sure you have the latest Service Pack from Siemens. Some Siemens drives have new firmware versions and it is important that your software is up to date in order to interface properly with the new firmware.

   One important aspect of this particular configuration is that the drive was wired with 6 digital inputs. These inputs were to be used as signals from a separate safety PLC.

   Initially we walked through the standard commissioning Wizard process – entering the motor faceplate data and configuring the drive to use open loop speed control. After standard commissioning we were able to jog the motor from the control panel in Starter.

2. Safety Inputs/Outputs Configuration

    After completing the commissioning Wizard, we moved on to configure the integrated safety functions. Safety inputs to the onboard terminals of the G120 utilize pairs of wires: 6 individual digital input wires allow for 3 distinct safety inputs. We intended to use Safe Torque Off (STO) and Safely Limited Speed (SLS) – this left one unused pair of digital inputs from the safety PLC.

   Using the safety integrated screen in Scout we configured the Safety Inputs/Outputs as shown here. STO was mapped to digital input pair 0, and SLS was mapped to digital input pair 2. Note that you need to set any unused safety functions to “[255] Static deselected”.

   

   At this point we expected the VFD to be ready to go. We still had no problem jogging the motor from the control panel in Scout and everything appeared to be squared away.

   We attempted to control the VFD from the PLC using Standard Telegram 1. However, the VFD would not accept control from the PLC. The drive was receiving the control word and speed word from the PLC, but it was not obeying the commands. The status word and actual speed word the drive sent back to the PLC did not match the command words sent to it from the PLC.

3. Factory Default mapping of Digital Inputs           

   We discovered that this issue stems from the Factory Default mapping of the digital inputs to the VFD (shown below). The VFD saw these digital inputs as HIGH from the safety PLC and behaved as if p1055[1], p1056[1], p2103[1], and p810 were all true.

   

   These particular inputs are meant to place the PLC in local control (i.e. from a local hand switch near the drive). As you can see above, we had successfully configured F-DI 0 and F-DI 2 as safety inputs, but these digital inputs were ALSO mapped to other bits by default (Jog bit 0, Jog bit 1, etc.). When these bits are high the PLC is unable to control the drive.

   The first 4 digital inputs are mapped to these bits by default. If these digital inputs are always low, as they would be if the digital inputs were not connected to anything, then this default presents no issues. However, in this case we were attempting to use the digital inputs for other functionality.

   The resolution to this issue is to remove the default mapping. You do so by clicking the blue shape next to each Digital Input selection, clicking “Further Interconnections” and then deselecting the check box next to all bits.

   

4. Test Stop for Extended Safety Functionality

   Another important parameter to be aware of when configuring Extended Safety functionality is the “Test stop selection of extended functions”. This is available from the configuration button on the Safety Integrated page. This parameter needs to be mapped to any bit. Whichever bit it is mapped to must be toggled under the following circumstances:

   1. The drive power cycles
   2. You perform RAM to ROM on the drive
   3. The timer (configured from this dialog box) runs out.

   This bit is essentially meant to be a test of the extended safety functionality. When the drive is using basic safety, the test stop is simply the STO bit. To perform a test with basic functionality, you simply toggle the STO (usually just an Estop). However, for extended safety you need to configure a custom bit to be toggled.

   

                   On the right side of this dialog box, you can also configure a bit that will get set when this extended safety test stop is required. This could allow you to convey this information to a PLC program or to an operator.

5. Safety Limited Speed (SLS) Setpoint Calculation

   One final issue we encountered when configuring SLS extended safety on the G120 drive is that the SLS speed was not running at the expected speed. As shown below, we configured n_max to be 900 rpm, and the Set Velocity Limitation to be 20%. This should have caused the motor to run at 180 rpm when SLS was active. However, the drive ran at 45 rpm with SLS was active.

                  

   

   It turns out that the error was with how the drive calculated its SLS speed. In the Configuration -> Mechanics configuration dialog box, there is a parameter “Number of motor revolutions x pole pair number”. This needs to be configured to 4. The default setting is 1. This caused the SLS speed calculation to be off by a factor of 4.

   

If you are configuring a G120 Drive using extended safety and/or onboard terminals, we hope this guide will help you avoid some of the issues and trouble spots that we encountered.

The post Commissioning a Siemens G120 VFD with Extended Safety using the Onboard Terminals appeared first on DMC, Inc..

Commissioning the MDrive Stepper Motor with the Schneider TCP Configuration Utility

The software required for commissioning the drive is available for download on the Schneider Motion website. The software that I needed was the Lexium LMDxE TCP Configuration Utility Version 1.2.0.6 that includes the PROFINET configuration part.

When you first open the Utility, you will see the Config screen. This is where you will need to select your computer’s adapter, and then you can read the MAC and IP Addresses from the drive. Once you connect to the drive, use this screen to set the drive’s IP Address as you wish to use it.

The PROFINET screen allows you to set up the input and output Registers for controller and drive communication.
 

I used all the default parameters for the Inputs and all but two for the Outputs. My application called for an encoder, which enables stall detection. However, the Stall Flag and the Stall Factor parameters were not in the default parameters so I had to add them in place of unused parameters.

The SEM Port screen allows you to send commands to the drive, read parameters from the drive, and set drive parameters. There are some drive parameters that cannot be set from the PLC (direction for example) or are cumbersome (configuring inputs and outputs), so this is the best screen to perform these tasks. Sending commands to the drive is a good way of verifying functionality of the motor before installing it into your application.

IMPORTANT: Write “SAVE” to the drive after setting parameters so that you do not lose them when motor power is cycled.

Setting up the Siemens Project for Motion Control

Integration with Siemens requires installing the GSD file and adding it to your Hardware Configuration. The MDrive object allows for 128 bytes of both input and outputs, and you can see how I used them below.

I found that 128bytes of both inputs and outputs was more than I needed for motion control in my application. Schneider Motion has documented the parameters well, so I will discuss some aspects that are not explicitly explained by the documentation.

Toggle Parameters

The parameters are usually sent to the Stepper motor when they are changed. For example, if you want to run the motor at a certain velocity, you send a speed to the Slew Register, and if you want it to stop, you send the Slew Register the value zero. If you are performing an Absolute Move and you want the motor to stop, you can again send a zero value to the Slew Register. However, if that register is already set to zero then the motor won’t stop, which is why you would need to use the Toggle Registers. In this case you would send a signal to Register 31 to toggle the Slew Register when the Slew Register is set to zero.

I have found that the best way to reliably send commands to the motor is by using the Toggle Registers. In the SCL code below I have an example of using the Toggle Registers. You will see that I compare the acceleration I read from the drive to the acceleration that I sent to the drive. If they are different, I set the toggle bit for the acceleration Register. Once the accelerations match, I reset the toggle bit (without resetting the other toggle bits) so that I can trigger the change the next time the accelerations differ. The motor waits for the rising edge of a toggle bit.

 
In my application it was necessary to change speeds and positions during moves, so I repeatedly toggled the motion commands (Move Absolute, Move Relative, and Slew) while my motor was in motion. In the example below, I check if I am running in position mode and I constantly send the position setpoint to the motor. The toggle bit automatically toggles until I am no longer running in position mode so I only have to worry about updating the position.

Resetting Errors and Faults

When the motor faults, the error is displayed with the Error Code parameter. Most faults can be cleared by sending “0” to the Error Code parameter. However, the Locked Rotor and Stall parameter faults require additional resetting. When the Locked Rotor fault occurs, it is necessary to send “1” to the Clear Locked Rotor parameter. When the Stall fault occurs, it is necessary to send “0” to the Stall parameter.

Quick Tip: I found the Stall Factor parameter was set too low for my application so once I set it higher the erroneous stall faults stopped occurring.

Learn more about DMC’s Motion and Siemens PLC services.

The post Schneider MDrive Motor Integration with Siemens Programming appeared first on DMC, Inc..

1. Add the drive to Devices & Networks. If the drive has separate Control and Power Units, add the Power unit in the Device View of the Control Unit.
2. Assign the IP address and Profinet Name in Devices & Networks. This IP address must be unique and on the same subnet as the PLC.
3. Setup Safety Telegrams in Devices & Networks. Be sure to assign the Partner data area so that no tags are overlapping with tags used for logic.
4. Assign Unique F-Addresses in Devices & Networks. Profinet F-addresses are only assigned through Portal and do not have the physical jumpers Profibus drives have.
5. Set IP address and Profinet Name in the drive to match the one assigned in Devices & Networks. This is done through the Online Access > Device Interface> Online & Diagnostics > Functions. If the device has had a previous IP address assigned, make sure to reset the IP to factory default first. This will reset only the IP address and Name, not any previously assigned parameters or safety functionality. If a factory reset is not done, the IP address may return to the original setting after a few power cycles.
6. Commission drive parameters using the commissioning wizard built into Portal and the specifications found on the motor faceplate.
7. Commission drive safety through the functional view of the Parameter option. If commissioning multiple similar drives and copying the drives in the Device & Networks, you must “Activate the Safety Commissioning Mode” while online with each drive individually, even if no settings need to be changed.
8. Test the drive by manually moving it in Portal’s control panel.
9. Upload from drive to save motor parameters in Portal for later reference.

Here is a more detailed description of the process found on Siemen’s website.

Learn more about DMC’s Siemens PLC programming services. Contact us for more information.

The post Commissioning Siemens G120 Drives with Startdrive in TIA Portal appeared first on DMC, Inc..