To provide a backup control method in case of PLC failure, the client chose to add a set of additional manual controls wired directly to the drive control unit. This configuration can be kind of tricky; we effectively had two potential command sources to the drive. But we were in luck! Siemens drives come with the capability to switch between multiple Command Data Sets, control sources, which allowed us to quickly swap drive control from the PLC to control inputs mounted on the drive cabinet.

This tutorial walks through the process of creating a secondary CDS and integrating drive-specific IO to create backup drive controls using Siemens SCOUT programming software. The process is functionally identical using Siemens Starter; you can also use TIA Portal to configure your additional CDS, but the interface looks a little different. Nevertheless, you should be able to follow along with the specific parameters referenced in this blog – just know that the first couple of steps might look a little different in Portal!

Note: this tutorial assumes you’re starting with a functional PLC-controlled drive; if you aren’t there yet, these DMC blogs may be a good place to start! 

• Motion Control Solutions with Technology Objects in Siemens TIA Portal (Note: this is slightly outdated, and S120s can now be configured in Portal).

1. Our first step is to create a secondary CDS in drive configuration. In the “Configuration” section of the drive, click “Add CDS.” You can either add 
   a blank CDS and populate every relevant parameter yourself, or just copy over your primary CDS (which should contain data from your initial configuration and PLC). I’d recommend copying over the primary data; it’ll make our lives just a bit easier. So, all we need to do from here is tie in our manual inputs and clean up a couple of residual PLC-connected parameters.
   1. In the Scout’s drive Expert List, you can filter parameters to look only at those relevant to the Command Data Set(s). Now that we’ve added a secondary CDS, each of these parameters should be shown as an array, with indices for each CDS. For example, p840[0] represents OFF1 for CDS 0 (PLC controls), and p840[1] corresponds to OFF1 for our new CDS. 
   2. 
2. Now that we have a new CDS, let’s connect our inputs!
   1. Under the “Inputs/Outputs” section of the Control Unit project tree, we can see the digital IO for our drive. We have the option to tie parameters to either the incoming digital signal or to the inverse of that digital signal. This gives us a little bit of extra flexibility, which can come in handy if you need to get around some backwards wiring or switch between normally open and closed contacts. Depending on what hardware you’re using, your IO options might look a little different from the screenshots; if you find yourself short on IO channels, Siemens also offers a variety of terminal block modules that can provide additional IO (we use an analog module later in this example).
   2. 
   3. Local/Remote selector switch
      1. Now that we’ve added a secondary CDS, we need a way to tell the drive which CDS to watch for commands. We can tie our selector switch input to p810 (the Command Data Set Selection Bit): a 0 value will tell the drive to use CDS 0, while a high value (1) tells our drive to use CDS 1 (our secondary CDS).
      2. In this example, my local/remote selector switch is tied to DI 17. Notice that I’m actually using the inversion of the digital input. This is solely due to the way the switch hardware is wired: ‘local’ gave us a low value, so the selection bit would be backwards if we used the standard input. It’s a lot easier to play with software than re-label or re-wire the cabinet, so we’re just using the inverted DI!
   4. Fault acknowledge
      1. It’s always good practice to give yourself a way to acknowledge drive faults. If you have an optional screen insert (like this BOP) you already have an interface to acknowledge those faults. But, if not (or if your drive hardware will be secured in a cabinet and you can’t access the screen, like in this case), you can tie a DI to p2102 (Acknowledge All Faults). In our example, this parameter is tied to DI 2.
   5. Open/Close
      1. Since we’re commanding both forward and reverse motion, the open/close commands can get a bit tricky. We want either digital input signal to set the enable signal (p840), but we will also need to accommodate the difference between a forward and reverse command.
3. Open and Close inputs
   1. P840 is going to be our main enable, which we’ll set using the open/close inputs to the control unit. If you’re only trying to run your drive in a single direction (for example, if we only wanted to open our valve to release pressure, or if you wanted to lower an elevator to the ground), you could tie this parameter directly to a digital input wired to a “Run” button or switch; however, we want to be able to run our drive in both forward and reverse directions – meaning we’ll need to do a tiny bit of logic to set this enable if either the forward or reverse inputs go high.
   2. To do this, we’ll want to enable some smarter drive functions:
      1. Right click on the drive unit and go to “Properties.”
      2. Choose the “Function modules” tab and check the box to enable free functions. This will allow us to evaluate simple AND/OR statements within the drive.
      3. If you don’t have the option to enable free function modules, you might need to run through your drive’s DDS configuration again and make sure you checked the box labeled “extended setpoint channel” before following the steps above.
      4. 
      5. In the expert list, we now have additional parameters, starting at p20000.
   3. Now that we have additional parameters with which we can work, we need to tell the drive to actually process the bonus data. We configure this by setting p20000 to [9003] so it knows to evaluate our inputs.
   4. 
   5. From here, we’ll tie our open command to p20046(0) and our close input to p20046(1). The following parameter p20047 represents the “OR” evaluation of all inputs linked in p20046.
   6. From here, we’ll tie that parameter (p20047) to our OFF1 input p840[1], which will be our only conditional enable.
   7. 
   8. This sets our enable signal, but we also need to differentiate between our open and close inputs. Conveniently enough, Siemens has already given us the parameter we need – p1113, for setpoint inversion. We’ll connect our ‘Close’ input to p1113[1], which will tell the drive to invert direction while closing.
   9. 
4. We’ve now set our conditional enable signal from the open/close inputs, but we can’t forget that the drive is expecting to see a few other enables as well (OFF2 and OFF3). If we wanted to connect these to other inputs (for example, having a ‘Drive enable’ switch along with an ‘Open’ command), we could use the other enable parameters. In this case, however, we only have one option and will need to hard-code the other enables.
   1. We’ll set OFF2 and OFF3 both to 1, as pictured below:
   2. 
   3. One thing to note is that the drive should have different responses to a lost enable (coast-down, quick stops, etc.). If you’re looking for a particular response (i.e. you want your drive to STO if the operator releases your enable button), you should investigate each enable signal and make use of the one that fits your system best.
      At this point, we have a drive that should enable with our open and close switch! What we don’t have at this point, however, is a speed setpoint. We can either hard code a value (useful if you only want to run at a single speed, or don’t have a terminal board to supply an analog input signal) or tie an additional input to our setpoint value. In this example, we’re using a Terminal Board module (TB30) to add some analog input options to our drive IO, so we’ll take an extra step to set up an AI for speed setpoint.
5. To use our analog input for speed, we need to set up scaling for the input on the Terminal Board and tie our scaled signal to p1070[1], the main speed setpoint.
6. 

From here, we are all set – just make sure to download to the drive and copy RAM to ROM. After power cycling, we should be ready to utilize our new CDS and extra control options!

If you want to learn more about Siemens motion programming, take a look at these blogs:

• Siemens How To: Starter Executable Scripts and Custom Data Lists
• Simple Motion Control with an S7-1200 PLC and a Pulse Train Output (PTO)
• Go Further with Siemens Motion and Safety Using the S7-1517TF

Learn more about our Siemens PLC Programming expertise and contact us today for your next project.

The post How to Configure a Secondary CDS for a Siemens S120 appeared first on DMC, Inc..

DMC has a lot of experience with Beckhoff motion projects and has developed libraries to reduce development time. Please reach out to DMC if interested!

In this blog we will add an axis, move the axis virtually using a couple of different methods, and get into the configuration and diagnostics in TwinCAT. General TwinCAT knowledge is assumed for this blog.

TwinCAT NC Interface

To explore the TwinCAT NC Interface, an axis will have to be added to a project. Open a new project and RMB (Right Mouse Button) MOTION >”Add New Item…”>”OK.”

Next, add an axis by RMB Axes >”Add New Item…” Name the axis and press “OK.”

At this point, activate the configuration so that axis is on the target.

Click on the axis that was just created. This will open a window with several tabs.

Settings

The Settings tab is where the axis is connected to physical hardware along with the PLC.

When a drive is added to the project, it will show up when clicking “Link To I/O.” When connected to a device, the axis will send commands and receive status from physical hardware. When connected to nothing, the axis is simulated.

To control an axis from PLC code, the axis will need to be connected via “Link To PLC.” This will happen in the next section. For now, the axis can only be controlled via the Online tab.

Online

The Online tab allows for basic control of an axis. Even when connected to the PLC, the Online tab can be used if there are no PLC commands overwriting it.

Since this axis is not connected to the PLC, it needs to be turned on before moving. Press the “Set” button and press “All.” This will turn on the axis at 100% override.

In a situation where the axis should never be moved backward or needs to be run at a reduced velocity, you can choose these options in the above popup.

Once “All” is selected, the 3 boxes in the “Enabling” boxes should be checked. We can now jog the axis by pressing the jog buttons at the bottom of the screen. The position of the axis will change accordingly.

Functions

After you’ve had enough fun jogging the axis, head over to the Functions tab.

This is where more precise motion commands can be issued. For example, setting a “Target Position” and “Target Velocity” and pressing “Start” when “Absolute” is selected will send the axis to the position. There are several other movements in the dropdown that are worth trying out.

Another powerful feature of this tab is the ability to set the position of the axis without actually moving it. Type a number into the “Set Actual Position” filed and press “Set” and the position of the axis will change to that position without moving.

Parameter

Now that we have the basics of axis movement down, let’s make some parameter changes for how the axis behaves. In the Parameter section, a lot of the properties are set based on the drive and motor combination that are brought into the project (this will be discussed later); however, there are other properties that are very application specific.

Here, the “Manual Velocity (Slow)” has been changed to 5.0 mm/s. This will affect the axis when pressing the “+” and “-” in the Online tab. The red text in the “Online Value” indicates the values are different on the target than in the project. We will need to activate configuration for these changes to be made. The second parameter that has been changed is enabling “Soft Position Limit Maximum Monitoring” and setting the “Maximum Position” to a value of 1000 mm. This will prevent the axis from going to a position greater than 1000 mm. Activate the project and see what effect these have!

Axis_REF

Next, let’s connect the axis to a structure in the project so that we can control the axis through code!

The datatype TwinCAT used to do this is AXIS_REF, which acts as an interface between the PLC and NC. At the most basic level, this datatype is passed into MC function blocks as an IN_OUT variable to control the axis. In many instances, these MC blocks are wrapped up in another function block to make it easier to control, but, ultimately, these blocks are used to control the motion on an axis.

To add an axis to the project, we will need the Tc2_MC2 library. Add this by going to References->Add Library->Tc2_MC2. Add an axis (of type AXIS_REF) to the project in a new FB_Axis (Structured Text) function block. Be sure to call this FB from MAIN!

Build the project, and make the linkage in the NC interface to the PLC.

So what is this actually doing? Taking a look at the definition of AXIS_REF, you will see that it exposes a physical input and output to and from the NC interface. This allows for the PLC and NC interface to exchange information. The PLC is sending a Control word (and other commands) and the NC interface is sending back a State word (and other status information). You will also notice that Inputs and Outputs in the side bar have been automatically linked when adding the axis.

Connecting to Code

To gain a solid understanding of what is happening under the hood, let’s add a couple MC functions blocks to control an axis. Add a MC_Power and MC_MoveAbsolute to FB_Axis. Since we will control it from the variable table, only the Axis needs to be connected to the MC blocks.

Download this to the PLC and login. When opening up the Power function block, you should see something very familiar!

These are the exact properties that are seen when going through the Online tab in the NC Interface, so, writing all three of these properties to TRUE will turn on the axis. This can be confirmed by going back to the NC Interface and verifying the 3 boxes in the “Enabling” boxes are checked.

Now that the axis is on, move it to a position of 100 by writing it into the “Position” input of the MC_Absolute block. Make sure to specify a “Velocity” as well. Set “Execute” to true, and the axis will begin to move.

This can be verified by the “Active” bit being true while the axis is moving and the “Done” bit being true once the axis gets to the position. The NC Interface will also show the live position as it is moving. Again, this should look very familiar as it has the same inputs as the Function tab in the NC interface.

Utilizing a General Motion Function Block

This is where DMC’s experience can be of value. DMC has developed a general motion function block, so it is not necessary to add all the MC function blocks. Rather, this acts as a wrapper. For example, instead of adding MC_Jog, all that needs to be done is turning on the `bInCommandJogFwd` bit. The logic inside of the function block handles the scenario when multiple commands are called at the same time, aggregates all the errors, and outputs when a specific command has been completed.

Connecting to Hardware

The final piece is to actually connect the NC interface to hardware.

To do this, some hardware must be added.

Once the drive is added, another axis in the NC Interface will also be added. Since we already have an axis configured, delete the one that was just created. Go ahead and link the NC axis to the drive we just added.

Now, we have a fully functioning NC interface that is ready to be connected to real hardware! Unfortunately, there isn’t much more we can do after this since we don’t actually have this hardware but it’s worth the exercise.

Beckhoff Hardware

Using Beckhoff drives and motors with TwinCAT obviously comes with its advantages. First off, both will be readily available to add as hardware. The drive will be available in the hardware tree, and the motor will be available in the Drive Manager. We will get into Drive Manager and Drive Manager 2 later, but this is where a motor can be specified. This will populate a lot of properties that need to be set in both the NC interface and drive’s Startup parameters (to also be discussed later as well)

3rd Party Devices

For third party devices, configuration files will need to be obtained from the manufacturers website or Beckhoff support. For example, a simple “Yaskawa Drive Beckhoff” yields some great guides with instructions to install files. If that does not yield positive results, Beckhoff support can make these configuration files based on the drive or motor specifications.

To be able to add a 3rd party drive, the configuration file (.xml) will need to be placed in the `C:\TwinCAT\3.1\Config\Io\EtherCAT` folder. For a TwinCAT project to recognize the new file, the devices must be refreshed by going to `TwinCAT -> EtherCAT Devices -> Reload Device Descriptions`

Drive Settings

Just like the NC interface, there are several tabs of settings associated with the physical hardware. Some of these parameters are shared between each other while some are hardware specific.

General, EtherCAT, Online

These tabs speak for themselves and usually do not need to be configured. These tabs exist for any piece of hardware added, regardless of if it is a drive.

DC (Distributed Clock)

This is another tab that should not be touched unless there is a complete understanding of what needs to be set and why.

Process Data

In this section, the PDO’s (Process Data Object) of the drive can be edited. PDO’s are parameters that are cyclically passed to and from the PLC. The parameters can then be linked to variables and used in code.

So, let’s say we need to monitor the torque of the drive to know when to move to the next state in a sequence. This can be done by simply adding the PDO and then linking it to a variable in the PLC. RMB in the “PDO Content” window and press “Add New Item…”

Find the “Torque feedback value” and press “OK.” It will then show up in the hardware tree.

Some drives will have multiple sets of mapping available. Depending on what is useful for the application, choose which one(s) are necessary by toggling the check marks in the “PDO Assignment” area.

For Beckhoff drives, the Dictionary will contain all of the available PDO mappable content. For third party devices, these may not be readily available and may require some digging into the documentation. For example, here is an excerpt from a Yaskawa EtherCAT communication guide.

For the first parameters, this would not be able to be added because of the No under PDO Mapping; however, to add the second parameter, adding the index, subindex, and data type in the window above will add this parameter.

SoE – Online

Going slightly out of order, this is where the parameters of the drive can be viewed and also modified.

A parameter can be changed by double-clicking on the value.

Startup

The Startup tab contains the parameters that are written to the drive on startup.

So, if a parameter is changed in the SoE – Online tab and the parameter also exists in the Startup tab, then the change will get overwritten on the next power cycle if it is also not configured here; therefore, it is very important to change the value in the Startup tab as well once the parameter change has been validated.

Another scenario is where the parameter is changed in the SoE – Online tab but the parameter does not yet exist on the Startup tab. In this case, the parameter will be retained at the value through a power cycle; however, it is still very important to then add this parameter to the Startup tab in the event the drive fails and a new one needs to be added. Without adding that parameter to the Startup tab, there is no record of this parameter ever being altered.

For Beckhoff drives, Drive Manager (2) is the most useful tool for what is going wrong. This is a place where all drive information is laid out in a useful way and error messages can easily be read.

Drive Manager

This is the original version, which is available when clicking on the drive in the hardware tree.

After adding a drive, the first thing that should be done is add the motor and feedback type. As mentioned before, this will set a lot of very important parameters on the drive and NC interface.

This is another very important parameter that needs to be set in the distance per motor rotation when taking into account gearbox and ratio. This can be done below.

Drive Manager also gives you the ability to change parameters of the hardware. Additionally, this window gives the user the ability to add/update the parameter to the Startup tab: which is very important, as discussed previously.

Pressing the greyed-out button with the down arrow will make parameters active on the drive from this window. Pressing the button with the blue down arrow will allow you to add any parameters to the Startup tab that differ from the current/default value.

There are several other windows, but the most important remaining one is the “Error history” window: which is located under the Diagnostics section. Here, a list of errors can be seen, and this obviously can be crucial when trying to troubleshoot a machine.

Drive Manager 2

Drive Manager 2 is the new and improved way to commission and diagnose Beckhoff drives. To use Drive Manager 2, it will need to be downloaded from the Beckhoff website.

Once installed in the project solution, add a TwinCAT Drive Manager 2 Project. It will then detect all available drives.

The benefits to Drive Manager 2 is a better look and feel that is easier to navigate. All of the information from the original Drive Manager exists in 2, but it just might be in a different location.

For the drive as a whole, the parameters will be located here:

Then, for axis specific parameters, clicking on the individual channel will show screens similar to the Motor and feedback section in the original Drive Manager.

Although this was mentioned in the previous section, this is worth repeating. When troubleshooting a drive, this is the first spot you should go. A history of all drive errors is very powerful when troubleshooting a system and can often tell a story of what actually happened.

Conclusion

This is just scratching the surface of Beckhoff motion. Gearing, camming, coordinated motion, and CNC are just a few others that Beckhoff excels at. Be on the lookout for some advanced motion control guides in the future!

Learn more about our partnership with Beckhoff and our Motion Control Engineering and Servo Systems expertise, and contact us today for your next project!

The post TwinCAT Motion Control Basics appeared first on DMC, Inc..

MagneMotion Guide Series

• MagneMotion Guide Part 1: Creating Configuration Files
• MagneMotion Guide Part 2: Starting up and Commissioning a Track
• MagneMotion Guide Part 4: Using Path and Station AOI’s
• MagneMotion Guide Part 5: Alternative Routing Controls
• MagneMotion Guide Part 6: Track Recovery Considerations
• MagneMotion Guide Part 7: Traffic Lights
• MagneMotion Guide Part 8: Simulation
• MagneMotion Guide Part 9: Traffic Jam Prevention
• MagneMotion Guide Part 10: Moving Track

Step 1: Setting up the Node Controller

The first step is to make sure that the Node Controller is configured to be controlled by a PLC.

In the MagneMotion Configurator Tool, select PLC EtherNet/IP in the Configurator Tree and check the box for Use a PLC for Host Control. Now, a series of additional PLC options should be available. For most of these, it will be fine to leave them as defaults but you will need to set the IP address for your PLC and enter the PLC slot that the Node Controller will be communicating to.

You will want to ensure that the PLC Max Vehicle ID is large enough to handle all the vehicles that might possibly be in your system. It might also be worth turning PLC Host Disconnect Action from “None” to “Suspend.”

Step 2: Using the Application Code Manager

To create the PLC program for your system, open Application Code Manager and go to File -> New Project. Select the type of project you want to create and click Next.

Enter the name of your project and hit Finish.

If you do not already have the ICT library registered, right-click on Registered Libraries, select register, and then select the .HSL4 file you want to register. You can find the ICT library files here.

On the left-hand panel, right-click controllers and click Add New. In the popup, select the type of PLC controller you are using and enter a name for the PLC. Hit Finish when completed.

In the new controller right-click Tasks and select Add New Task. This brings up a prompt to create a new controller task. Create it as a continuous task and name it appropriately.

Now, right-click the task you just created and select Add New. In the popup that appears find raM_Dvc_DH_MM and click Next.

In the menu, you can now configure parameters for your PLC code; such as the maximum number of movers, max paths, and nodes etc. You can set these values now, but they can also be easily changed in the PLC code. However, one value that is more difficult to change once the PLC gets generated is the MaxNumMethods value. This value is the maximum number of ICT library AOIs in your project. If you have a particularly large system, you might want to increase this to 100 or 150 to afford yourself some flexibility and scalability.

Next, go to the Linked Libraries tab and hit Auto Create. This will generate all the AOIs and udts that are needed to run the default MagneMotion routine.

For the main task of the PLC, select your task again, right-click, and select Add New again. In the pop-up menu, select raM_Tec_MM_Station and add that to the project.

There are various other ICT Library AOIs used for controlling MagneMotion systems, but with these two additions we should be ready to start. If you know of any additional ICT AOIs you would like to use for your project, feel free to add them now.

Finally, in the Controller Preview tab right-click Controllers and select Generate Controller to export your configured PLC as either an ACD file or as an L5X file.

 For additional reference, there is a quick start guide included in the ICT library download.

Step 3: MMI Tags

Assuming the Node Controllers for your system are set up properly (see MagneMotion Guide Part 2: Starting up and Commissioning a Track if not), then the Node Controller should already be trying to reach a PLC at the IP address you entered in the configuration file.

In either NC Host or the log file from the Node Controller webpage, you can verify if the PLC is properly connected to the Node Controller. If the EtherNet/IP indicator in NC Host is labeled Up, then you are all set.

However, if the EtherNet/IP link is Down you will need to troubleshoot the connection between the Node Controller and the PLC. Verify that the IP addresses of the Node Controller and the PLC are correct, there is a valid network path between them, and the subnet mask for each device is properly set.

Once the communication from the Node Controller to the PLC is set in NC Host, you should either see that the EtherNet/IP link is Up or you will see that the link is flashing between Up and Down.

If the link status indicator is flashing, that means the Node Controller can reach the PLC but there is some conflict between the PLC code and the Node Controller configuration file.

In the PLC, there should be a list of controller-scoped tags with the MMI prefix. The Node Controller reads and writes to these tags in order for the PLC to control it.

To fix the Node Controller and PLC communication, you will need to make sure that all these arrays are large enough to handle the information required by the Node Controller. You can find out which tags are the issue by viewing the High-Level Controller Log from its webpage.

Each tag must be the size of all the elements it needs to control plus one. For example, if you have ten paths, the tag MMI_Path_Status needs to be size 11. This is because the Node Controller begins indexing at 1 so path three’s status information is found in MMI_Path_Status[3].

Go through each MMI tag and make sure it is the right size. For the tag MMI_path_ml_faults_status, the size needs to be the number of paths by the largest number of motors in a single path. So, if you have ten paths and the largest path had six motors this tag would have to be size [10 + 1, 6 +1] or [11,7].

The Vehicle Status tags will need to be sized based on the maximum number of vehicles defined in the Node Controller’s configuration file.

With all these tags properly sized, you should now see a consistent green UP message in NC Host for EtherNet/IP communication. If you still do not see a consistent Up displayed, view the High-Level Controller’s Log File for additional information on which tag to check.

Step 4: Configuring the MagneMotion Connection

Now that the Node Controller to PLC communication is set up, there is just one step left to get the PLC properly communicating to the Node Controller. This is done using the ICT library’s configuration AOI.

The job of this AOI is to configure the communication between the PLC and the Node Controller so that the PLC will know where to send commands. Here are the inputs to the AOI and how to properly set them:

1. Ref Handle: This must be the Hndl tag in the raM_Dvc_DH_MM program to connect the AOI to the device handler. This tag should already be public so you should be able to just input \ram_Dvc_DH_MM.Hndl
2. Inp_EthernetPort & Inp_EthernetSlot: These values are based off where the Node Controller is physically connected to the PLC. View the AOI help file for more information.

3. Inp_XXXOctetIP: These four inputs are for setting the IP address of the Node Controller. For example, if IP address is 192.168.0.1, Inp_SecondOctetIP will be 168.

When you enable the configured AOI, you should see the Sts_MtdID tag get set by the device handler and the Sts_IP tag be briefly on. Once the connection has been established, you should also see the Sts_PC output toggle on. If the block produces an error, check the AOI’s help file for more information.

Step 5: Commanding Vehicles from the PLC

Now that your communications are all set up, you are ready to start controlling the Node Controllers from the PLC. While there are a lot of different things you can do from the PLC, we will start with the simple task of moving a single vehicle along your track.

First, verify the track is started up and functional using NC Host. For good measure, command a vehicle to move through NC Host to ensure that everything is properly set.

In the PLC code, navigate to the default raM_Dvc_DH_MM program and expand the Mover tag. Then, expand the entry for whichever vehicle you want to move and look at the MPM tags.

MPM stands for Motion Position Move and is a basic way to command a vehicle to move to a specified position. Inside this tag, set MPM.Path and MPM.Position to the path and position you want to move your vehicle to and set the MPM.Velocity and MPM.AccelDecel tags to whatever values would be appropriate for your system. Note: unlike NC Host which uses units of meters, the ICT library uses millimeters. Therefore, a value of 500 for Velocity means that the vehicle will move 500 mm/s.

Once your parameters are set, toggle the MPM.Execute bit and you should see your vehicle move across the track! 

Note: If you get an error message in MPM.Sts_ERR you can check what the error code means by checking the help file of the AOI raM_Opr_MM_MPM

Topics to look forward to in this series: 

• MagneMotion Guide Part 4: Using Path and Station AOI’s
• MagneMotion Guide Part 5: Alternative Routing Controls
• MagneMotion Guide Part 6: Track Recovery Considerations
• MagneMotion Blog Part 7: Traffic Lights
• MagneMotion Blog Part 8: Simulation

Learn more about DMC's MagneMotion expertise and contact us to get started on your next project. 

The post MagneMotion Guide Part 3: Controlling a System with a PLC appeared first on DMC, Inc..

Here are my top five tools and suggestions to get you started with HandlingPRO: 

• Joint Jog Tool
• Fine Joint Position Control
• Change Views
• Move to Toolbar
• Fanuc Tutorials

Joint Jog Tool

This tool gives you handles that you can use to move the robot joints, but more importantly, it shows the limits of the robotic arm movements. Sometimes, it’s difficult to understand which joint is at its maximum and is causing you to reach a position limit.    

To enable this tool, navigate to Robot > Show Joint Jog Tool.   

Fine Joint Position Control

Moving the robot arm around with the joint jog tool is great for getting a broad understanding of the robot movement. If you want to dial in the movements to the millimeter, you should use the teach pendant.    

To do so you should click the position button on the bottom right half of the screen.  

Next, enable the teach pendant by clicking the ON/OFF switch on the left so that it's in the ON position.  

Note: The teach pendant-enabled switch will turn off when testing your programs and inhibits many of the editing tools, make sure that this is ON whenever developing on the teach pendant.   

Now that the teach pendant is on, you can either jog the robot with reference to the tool tip in the XYZ plane (or XYZ angles) using the blue button on the right of the teach pendant, or you can press the REPRE button on the bottom right to switch to the second mode (Joint Position Control). In this mode, you can jog each one of the individual joints by, again, using the blue buttons on the right of the teach pendant.  

Change Views

You can change your rotational axis by left-clicking anything in the window and can even select different surfaces of an object. Right-click to then rotate around that.  

Move to Toolbar

With this toolbar, you get access to a bunch of helpful tools such as move to surface or move to points that you have set up in your program.  

To enable the move to toolbar, click this button:   

Fanuc Tutorials

Lastly, Fanuc includes some helpful eLearn Training through tutorials. Some of these are built into the Help documentation and you can find them under the help tab.   

Learn more about DMC’s Robotic Integration and Automation and contact us today to get started on your next project.  

The post Top Five Fanuc HandlingPRO Tips  appeared first on DMC, Inc..

• Construct a basic motion model with a spreadsheet.
• Optimize a non-linear motion profile to match a non-linear mechanical system.
• Implement the solution in Siemens SiMotion Scout.
• Generate a complex motion profile using electronic camming.
• Try out some Microsoft Excel tips and tricks.

Table of Contents

• Introduction and Background
• Problem Statement
• Mechanical System
• Baseline Implementation
• DMC’s Approach
• DMC’s Mechanical Model
• Implementation in Siemens Technology CPU
• Future Enhancements
• Conclusion
• Excel Tricks

Introduction and Background

Return to the Table of Contents

This technical blog describes the optimization of a simple motion profile based on the construction of a physical system model using a simple spreadsheet. While the approach, model, and tools described in this paper are very general and can be applied to any basic motion optimization, here we focus on a specific motion optimization process recently completed for a specific DMC Client, the ThyssenKrupp Waupaca foundry.

ThyssenKrupp Waupaca (TK-Waupaca) is a gray, ductile, and compacted graphite iron foundry located in Waupaca, WI. A foundry is a manufacturing facility that produces solid metal castings by pouring hot molten metal into a mold. For iron casting, the molds are typically made of sand. The metal is allowed to cool and solidify, after which the mold is removed by shaking, resulting in the final metal part, the ‘casting’.

To create hollow features inside a casting, a ‘core’ is inserted into the mold (Figures 1-3). For Iron castings, this core is also made of sand with its shape held together by a binding agent. In large foundries, such as TKWaupaca, placing the core inside the mold is an automated process performed by a large mechanical tool called a ‘coresetter’. In simplest terms, a coresetter is a large, 2 ton, pick and place machine.

Figure 1. The Coresetter places a core inside the mold produced inside the sand column. [1]

In this blog, you will find out how DMC increased the speed of the TK Waupaca coresetter machine.

Certain elements of TK-Waupaca’s design are being claimed in a patent application pending in the US Patent and Trade Office.

Figure 2. A pattern creates an impression in a slice of a horizontal sand column 

Figure 3. A core is a solid block of molded sand held by a binding agent. It is placed in the Coresetter to form a hollow cavity in the final metal part. 

Problem Statement

Return to the Table of Contents

TK-Waupaca designed and built their own coresetter, and operates similar coresetter machines at three other foundries in Wisconsin, Indiana and Tennessee. The process step performed by the core setter machine, placing the core inside the mold, is a critical, rate-limiting step in each of these foundries. The faster the coresetter operation runs, the more castings the foundry can produce in a given time period, directly increasing the profitability of the entire foundry.

TK-Waupaca had been operating their Coresetters with a minimum stroke time of 1.4 seconds. This limit was based on an operational torque limitation in the motor, which would be exceeded if the existing motion operation were simply run faster. They had observed that their existing motion system would over-torque the motor at one part of the cycle as they increased the speed. However, at other parts of the cycle, they were well below the motor’s torque limit. What they needed to achieve is a system operating at a more uniform torque level, making better use of the motor’s power at all points in the motion cycle.

TK-Waupaca had performed a simple dynamics simulation, which indicated that, under uncontrolled torque-mode conditions, the coresetter should be able to perform the move in 0.62 seconds. While the model was showing them the operation could theoretically run faster, they were unsure how to approach the problem and implement a solution.

Since all of the automation electronics on their coresetter system were produced by Siemens, TK-Waupaca looked to their local Siemens sales representative for assistance. Siemens referred TK-Waupaca to DMC, a Chicago-based Siemens Solution Partner, to complete the analysis, modeling, and engineering efforts required to meet their goal of reducing the coresetter cycle time to 0.75 seconds.

Mechanical System

Return to the Table of Contents

The coresetter fixture that TK-Waupaca designed weighs 2 ton when loaded with a core. The system is shown in the schematic of Figure 4. The entire system travels along linear roller bearings a total distance of 55 inches (1.4m). The coresetter is actuated by a large AC, synchronous motor under position control by a Siemens 315T technology PLC. The motor drives a crank arm through a double-reduction gearbox with a 22:1 ratio. The crank and connecting rod drive a linear carriage, which places the core in the mold.

Figure 4. Mechanical layout of TK-Waupaca’s coresetter machine.

Baseline Implementation

Return to the Table of Contents

The simplest way to perform the coresetter move would be to ignore the connecting rod carriage and just make a constant angular velocity move on the crank with acceleration ramps. TK-Waupaca implemented this strategy first, and experienced motor torque limitations, even at low speeds.

Figure 5. TK-Waupaca’s initial cam table relates Crank Angle to Carriage Position based on crank arm and connecting rod geometry.

TK-Waupaca had correctly realized that the mechanical power transmission path was non-linear, and were attempting to compensate with their motion profile. They had created an electronic cam table that related Crank Angle and Carriage Position by a function derived from the crank and connecting rod geometry. TK-Waupaca implemented a virtual axis to represent the carriage position, and they synchronized their crank axis to this virtual axis with the cam function shown in Figure 5. The control strategy was to command a constant linear velocity move with acceleration and deceleration ramps on the virtual axis representing carriage position. This solution had slightly improved performance against the constant angular velocity method. Captured torque and velocity traces for such a move are shown in Figure 6, where the non-linear velocity profile and generated torque spikes are obvious.

Figure 6. Initial coresetter velocity and torque. The thin line at 300 indicates the torque limit.

DMC’s Approach

Return to the Table of Contents

DMC took a different approach to TK-Waupaca’s motion problem. Since both prior experience with the coresetter machine and TK-Waupaca’s simulation show that the system is limited by motor torque, and not maximum motor velocity or motor thermal limitations, a constant torque profile could immediately be determined as the most efficient method to get from A to B the fastest. Of course, for the system to return to rest at endpoint B, the torque direction must be inverted midway through the move.

The simplest way to implement a constant torque motion would be to abandon closed-loop control. Without generating a position vs. time motion profile, it would be possible to set the motor to full torque in the forward direction, then at some mid-position set the motor to full torque in the reverse direction and turn the torque off, or re-engage position control, when the axis comes to a stop. This is precisely what TK-Waupaca had assumed in their motion simulations to determine that performance at half of their current travel time was indeed possible.

While operating the system open-loop with constant torque would certainly get the system from A to B very quickly, it would create a number of problems:

1. The exact stopping position would not be consistent from one cycle to the next.
2. The exact time of the move would not be consistent.
3. Obstructions which would otherwise cause following error faults would go unnoticed.
4. Open-loop control of a 2 ton object is generally unsafe.

DMC’s sought an approach to achieving the performance benefits of the constant torque cycle, while avoiding the problems associated with open-loop operation. In this case, the approach was to create a custom motion profile which mimics the motion of the open loop cycle, but can be implemented using closed-loop control.

DMC’s Mechanical Model

Return to the Table of Contents

To achieve this goal, DMC built a new dynamic model of the mechanical system using a simple spreadsheet. The system was modeled as a rotary component in the frame of reference of the crank and a linear system in the perspective of the carriage. Frictional effects were disregarded because the system moves on roller elements. The rotary and linear components are tied together by a non-linear transfer function specified by crank and connecting rod geometry. Since the goal is to hold torque constant, the rotary component is defined as the input and the carriage position is defined as a function of rotary angle. A table of carriage linear position vs. crank rotary angle was generated with 1 degree resolution (plotted in Figure 7). The table was twice numerically differentiated to calculate the first and second derivatives of carriage position with respect to crank angle (also plotted in Figure 7).

Next, values were estimated for rotational and linear inertia constants. A standard simplification for a connecting rod used in engine design is that 1/3 of the mass is applied as a point mass on crank at the crank radius, and 2/3 of the rod mass is applied to the linear mass. The rotational inertia is calculated from the reference of the crank, not the motor. So all inertia values on the motor side of the gearbox are multiplied by the gear ratio squared.

Figure 7. Motion relationships between crank angle and carriage position (top), velocity (middle), and acceleration (bottom).

Next, the equation of motion was determined. The equation of motion relates the system acceleration to the force input and physical constants of the system. The equation of motion for a simple mass with force acting upon it is Newton’s second law of motion: 𝑓=𝑚∗ 𝑎 , where 𝑓 is the force, 𝑚 is the mass, and 𝑎 is the acceleration. The equation of motion for our crank must account for the torque applied by the motor, 𝑡𝑚 the rotary inertia, 𝐽, and the torque transferred to the linear component through the connecting rod, 𝑡𝑙. Given ∝, the rotational acceleration of the crank in radians/s², the equation of motion for the crank is:

𝑡𝑚−𝑡𝑙= ∝ ∗𝐽 or ∝ = 𝑡𝑚−𝑡𝑙�

The variable which requires additional definition is the torque transferred to the linear system, 𝑡𝑙. In the case of a linear transfer function like a rack and pinion connection, this would be a function of the linear inertia and the effective radius. For the linear system, 𝑡𝑙= 𝑚∝𝑟 2. In other words, the rack and pinion system only exerts torque on the rotary system when the rotary system is accelerating. In that case, the torque is proportional to the linear mass and to the square of the effective radius. Note that the effective radius in the rack and pinion system is the slope of the linear transfer function, 𝑥=𝑟 𝜃. For purposes of the crank and connecting rod equation, 𝑟 can be replaced with 𝛿/𝛿𝜃.

There is a second component to the torque transferred through the connecting rod. Even if the crank is moving at constant velocity, while the carriage is accelerating with respect to the crank, it takes some force to make the carriage accelerate just to maintain constant crank velocity. Generating that force requires torque applied through the effective radius, 𝛿/𝛿𝜃. This torque can be represented by the formula 𝑡= ω2𝛿2𝑥𝛿𝜃2𝑚𝛿𝑥𝛿𝜃 where ω is the rotational velocity of the crank.

The total torque transferred through the connecting rod is the sum of these two terms, or:

𝑡𝑙= ω2 𝛿 2 x/𝛿𝜃 2 𝑚 𝛿/𝛿𝜃 + 𝑚 ∝ (𝛿/𝛿𝜃) 2

So, the equation of motion for the crank is:

∝ = 𝑡𝑚− (ω 2 𝛿 2 𝑥 / 𝛿𝜃2 𝑚 𝛿𝑥/𝛿𝜃 + 𝑚 ∝ (𝛿𝑥𝛿𝜃 2) ) / 𝐽 which simplifies to ∝ = (𝑡𝑚− ω 2 (𝛿 2 𝑥 / 𝛿𝜃 2 ) 𝑚 𝛿𝑥/𝛿𝜃) / 𝐽+𝑚 (𝛿x/𝛿𝜃) 2

Now we set initial boundary conditions and use Euler method integration to solve for the function of crank position, 𝜃 versus time. The initial conditions are:

𝜃=0, 𝑡𝑖𝑚𝑒=0, ω =0

Given a function of motor torque with respect to time, 𝑡𝑚=𝑘, ∝ can be calculated for the initial condition. Note that 𝛿 2 𝑥 / 𝛿𝜃 2 and 𝛿𝑥 / 𝛿𝜃 were previously calculated as functions of crank angle, 𝜃 as shown in Figure.

For the second iteration and all subsequent iterations, new values of 𝜃and ω are calculated based on the previous iteration’s acceleration and the time between steps. New values for 𝛿 2 𝑥 / 𝛿𝜃 2 and 𝛿𝑥 / 𝛿𝜃 are obtained by a look up function for each iteration, and a new value for ∝ is calculated. The Crank Velocity function that results from this integration and the corresponding carriage velocity is shown in Figure 8.

Figure 8. Crank and carriage velocity versus time for the acceleration portion or the move.

The effects of the non-linear transfer functions are clearly shown. Since effects of the carriage are proportional to 𝛿𝑥 / 𝛿𝜃 and to the square of ω, both of which start at zero, the velocity of the crank starts to accelerate linearly. Over time, as ω and 𝛿𝑥 / 𝛿𝜃 increase, the acceleration decreases and eventually the crank begins to slow down. This happens because energy is transferred from the rotary to the linear frames so rapidly that the motor, which is exerting constant torque, cannot keep up. But the carriage does continue to accelerate.

At some point in the move it becomes necessary to change the torque direction in order to come to a controlled stop at the 180 degree position. An energy balance from the crank perspective estimates that this should occur at about 90 degrees of crank position. However given errors associated with numeric integration, changing the torque direction and continuing the integration is unlikely to bring the system to rest at exactly the correct position.

The way to bring the system to rest at the perfect spot is to start a second integration at the final conditions working backward to the start. So the starting conditions for the second integration are:

𝜃=180°, 𝑡𝑖𝑚𝑒=0𝑠, ω =0

From these conditions the model integrates backward in time and applying negative torque. It results in a positive trajectory that ends at the defined conditions. These curves are shown in Figure 9.

Figure 9. Crank and carriage velocity versus time for the deceleration portion or the move.

The curves near the endpoint share the same characteristics as the curves at the start of the move. However, the system is not completely symmetrical between start and end. At the start, the crank arm and connecting rod oppose each other and at the end they overlap each other. This results in the higher relative acceleration at the start versus the end shown in Figure 10. So the resultant optimized move is expected to asymmetrical.

The remaining step is to connect the two crank velocity curves to create a single profile for the entire move. The rule for making the connection is that the crank velocity and crank position must both be equal at the point of switchover. In Figure 10, the crank velocities are plotted with respect to Crank Position.

The intersection of these two curves is the torque switchover point. Linear interpolation between segments of the functions is used to determine the crank position of the switchover. Interpolation also determines at what time for each cycle the transition position is reached. The time scale for the deceleration is offset by the total time. Now, a complete profile of both velocity vs. time and position vs. time can be created. They are shown in Figure 11.

Figure 10. The transition point between positive and negative torque occurs at the intersection between the acceleration and deceleration curves. 

Figure 11. Optimized motion profile results: velocity (top) and position (bottom) vs time. Acceleration and deceleration curves are shown in blue and red, respectively.

Implementation in Siemens Technology CPU

Return to the Table of Contents

Ultimately, the crank position vs. time graph is the only element of the analysis that gets implemented into the motion control program, as a simple cam table. In electric camming, the “slave” axis follows a commanded position that is a function of another real or imaginary axis, the “master” axis. In the current system, the slave axis is our crank motor and the master axis is imaginary. A scale of 0 to 1000 was arbitrarily selected as the full stroke distance of the master axis. A set of data points corresponding to the crank position vs. time was copied from the model Excel spreadsheet and pasted directly into Siemens’ SiMotion Scout, as shown in Figure 12.

Figure 12. Implementation of cam table in SiMotion Scout.

The program logic is to turn on the camming action at the starting point and then run a timed move through the entire master range, 0 to 1000. Since the cam function already has acceleration ramps built in, the Acceleration and Jerk parameters on the master axis are set to their maximum values. This is done both in the function initiating the move and in the Master axis object Limits page. In addition to this, the Jerk and Acceleration limits for the Crank axis object were also set high.

During on-site testing, the system was still exhibiting sluggish torque ramp-up. The cam function should ramp the axis up to a constant torque very quickly. However, the trace showed high following error at the start and a slow torque ramp up. So the tuning parameters in the Closed-Loop Control tab of the Crank axis object were also modified.

Even after the tuning, there were a couple of low spots and high spots in the torque profile. These were adjusted using a lookup table of torque factors vs. crank position. After adjusting the torque factors at different points, the curve was re-downloaded into the controller. This fine tuning process was repeated until a smooth torque profile was obtained on the system.

Figure 13. Parameter trace of final motion profile implemented on the TK-Waupaca coresetter system.

After implementing the new program the system was performing with approximately uniform torque during the acceleration cycles as shown in Figure 13. This trace shows the system running at 1.0 seconds move time. However, the system was able to run at the goal speed of 0.75 seconds. When the system was operated at different speeds the torque magnitudes changed, but the shape of the torque curve remained similar to that shown.

When comparing the original torque profile against the new torque profile it is easy to see why a significant speed improvement was possible. Originally the torque bumped against the limit at a narrow point during acceleration. Most of the move time was spent using the motor far from its operational limits. The new motion profile achieved near constant torque and can use the motor near its limit for most of the move.

Future Enhancements

Return to the Table of Contents

One deficiency of the current solution is that the torque during deceleration is not uniform. In fact, as shown in Figure 13, it oscillates strongly. On the reverse cycle, when the cam table is run backwards, the acceleration is fairly uniform while the deceleration oscillates. This points to the most likely cause being that the torque direction change in the middle of the cycle induces a vibration in the mechanical system. Modifying the torque model to include a gradual transition in torque from positive to negative in the middle of the cycle should decrease this vibration. Doing this would round out the peak in crank velocity near the transition in Figure 11. It would only slightly affect the average velocity of the crank over the cycle. Therefore it can be expected to add only a couple of milliseconds to the total move time. A plan to make this change and refine the torque adjustments is currently in the works.

Another slight deficiency to this process is the adjustment of the ending position. The starting point, where the core is loaded onto the coresetter, is a fixed position in space. However there are a few millimeters of adjustment at the ending position, where the core is offloaded into the mold. Currently, we handle this by applying a scaling factor to the entire cam table. Because the cam scaling factor is between 0.99 and 1, it is negligible in this implementation. However, if a similar system had to start and stop at arbitrary points in the stroke, is there a way short of performing the same calculation in the PLC that is currently done in Excel to execute a constant torque profile from one arbitrary point to another?

Conclusion

Return to the Table of Contents

For a fairly small investment of time and engineering, TK-Waukpaca was able to work with DMC to reduce their coresetter placement time from 1.4 s down to 0.75 s. This 40% decrease in coresetter motion time has directly increased the utilization efficiency, and therefore profitability, of their foundry operations.

Excel Tricks

Return to the Table of Contents

The key to performing this analysis quickly was developing the mechanical model in a spreadsheet format. The beauty of the spreadsheet over a syntax based language is that all of intermediate calculations are in the foreground, so it is easy to correct mistakes during the process. But there are some tricks which make this type of work much easier. Here are a few:

• Named Ranges: In Excel, that box in the upper left that shows the current row and column (the Name Box) is also the place to enter names for ranges. A range is a single cell or a group of consecutive cells. For most instances where an absolute cell reference is used, it is easier to name that cell and use the name. It makes complicated formulas more intuitive. The Name Manager is on the Formulas ribbon and is used to modify and delete existing named ranges. The easiest way to name a range is to click in the name box and type a name.

• User Defined Spreadsheet Functions: To create a user defined spreadsheet function in Excel, open the visual basic editor (from the development tab) and create a Module. Any Public function written in the module becomes a user defined spreadsheet function. I made a function called LinearInterpolateLookup and used it extensively in the project. It operates similarly to the Excel Lookup function, but uses interpolation and works with either ascending or descending search ranges.

Public Function LinearInterpolateLookup(ByVal SearchVal As Double, SearchRange As Range, ResultRange As Range, bAssending As Boolean)

The IF() Spreadsheet Function: A simple functions called IF() takes a condition and two possible response values. If the condition is true, it returns the first one, otherwise it returns the second one. This function can be used cascading into itself to make complex conditional trees. An easy way to pull a specific value out of somewhere in a column is to make the condition true only for the row where with the desired value. The first possible response value should be the value you are looking for and the second should be zero. If you copy this formula for the entire column and sum the column, you get the one value you are looking for.

The post Optimization of Point-to-Point Positioning with a Non-Linear Mechanical Connection appeared first on DMC, Inc..

We’ll assume you have either a stepper motor or servo with a built-in encoder that can be actuated by controller pulses. First, add the PLC to the project.

Once added, go to Device configuration to do a standard setup, like setting the IP Address, and then enable the first pulse generator, PTO1/PWM1.

Be sure this pulse generator has the PTO signal type.

Note that the Pulse output will be at Q0.0, and the direction output will be located at Q0.1. We can then wire these to our motor.

Next, we need to create a tech object. Click “Add new object” under the Technology objects folder, and then select “TO_AXIS_PTO.”

Next, when you create the text object, select “Pulse_1”. Also, be sure to choose the correct position unit; Here I’ve chosen degrees.

Finally, at a minimum, you should enter the pulses per motor revolution and the load movement per motor revolution into the extended parameters. This step will ensure that your commanded speeds and positions are correct.

If you are interested, now you have the full power of the technology object to go in much greater depth with your motion control configuration. For now, we want to get this done quickly, so we’ll leave it at the mechanics' parameters.

Now our tech object is configured, and we can program some motion. We can now build up a lot of complicated ladder logic, but if all we want is to make the drive spin, we only need two blocks: MC_Power to enable it, and MC_MoveVelocity to get it moving.

Here, for the “Axis” inputs, I entered the Technology object. I put a “true” in the enable input for MC_Power for it to always be on, set the Velocity to 360.0 degrees per second (60 RPM), and then wired up a pushbutton from the first PLC digital input to the execute demand. I can now download the project to the PLC, press the button, and have a spinning motor!

Of course, in a real production setting, you’d want to have the ability to reset the drive if there is a fault, make absolute and relative position moves, and probably want a more thought out and formal structure to your code.

I hope this example showed you how simple it is to get basic motion working on the S7-1200, so you can avoid headaches and spend more of your engineering effort on the specifics of your own use cases. There is quite a lot of cool stuff you can do with simple motion control. If you’d like help with any of your motion problems simple or complex, please feel free to contact DMC.

Learn more about our Motion Control expertise and PLC programming services. 

The post Simple Motion Control With an S7-1200 PLC and a Pulse Train Output (PTO) appeared first on DMC, Inc..

Taking advantage of all the added features of the SINAMIC’s drive system can also make it difficult to keep all the parameters straight and commission your drive system efficiently. This post will walk you through how to create a Custom Data List and Executable scripts within Starter.

These features will save you time, money, and improve commissioning consistency!

Creating a Custom Data List

Within the Starter software (Available for free download), we have all seen the dreaded expert list (shown below). However, most people miss the small box next to the expert list to create a custom list.

Once you have the Custom Data List open, you can enter both comments and parameters in which you are interested.

Comments start with two backslashes (//).

Parameters can be whole arrays or specific points (as in the example). In this case, I have a few that are important to my application. This Custom Data list creates a concise list of parameters to check or monitor!

You can save this offline with the simple click of a button:

Creating an Executable Script

So, now that you have the Custom Data List highlighting all the critical parameters for your application, you do not want to type those in for every drive!

Let’s automate it with a script. Click the below, and you have a script you can run on every drive in the project!

If you want to export the script, press Export and you have a simple text file that you can import into any other project. This is perfect for documentation and distribution within your service force.

Adding and Running and Executable Script

To add an Executable script from that .txt export, add a Scripts folder to the CU drive object (shown below).

Then, import the script with the ASCII Import tool:

To run the executable, right click -> Run executable.

Pro Tip

The script saves the parameters to the online RAM only. I highly recommend adding this RAM-> ROM function to the bottom of your script. Add the text below after the final parameter setting:

Parameters(971, 0) = "1" 'Save parameters

Conclusion

In this blog, I’ve shared a quick overview of the Custom Data List and Executable Script functionality available with Starter. With these quick instructions, you too can have a trustworthy list of the critical parameters for your application as well as a simple executable to get the next job done quickly.

Learn more about DMC's Siemens PLC Programming Services.

The post Siemens How To: Starter Executable Scripts and Custom Data Lists 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..

For someone only seeking basic speed control of the drives, I’ve prepared a step-by-step process on how to quickly setup and control any Yaskawa VFD over PROFIBUS using the Basic Data message package.

Step 1: Setup Your Hardware Configuration

1. Download the Yaskawa drives GSD file from Yaskawa’s web site from this download link. Note: All Yaskawa drive models can communicate over PROFIBUS using only this one GSD file.
2. Install the GSD files in the HW Config tool by going to Options and selecting Install GSD File…

   

3. In the dialog box that was just opened, click Browse…Then navigate to the location of the recently saved GSD file. Select YASK0ACF.gsd and then press Install.
4. Add the newly added Yaskawa VFD to your PROFIBUS network. Expand the right panel menu to find the Yaskawa drive in the following folder location: PROFIBUS DP -> Additional Field Devices -> Drives -> SI-P3 PROFIBUS-DP INTERFACE CARD. Drag this onto your PROFIBUS rail.

   

5. Assign drive a PROFIBUS address by double clicking the newly added drive. Note: This number will have to match the PROFIBUS address entered on the drives front keypad.

   

6. Finally, configure the packet of data exchanged over PROFIBUS. For many simple speed control applications, exchanging the basic data package is sufficient. More complicated applications may require extended data packets. In the right panel menu, drag basic data into the correct location in your project.

   

Step 2:  Handle the incoming information with your code

When using basic data, Yaskawa drives transmit data via 3 input and output words. The inputs words are Status, Speed, and Current. The three output words are Operation, Frequency, and Torque. When using more than one VFD in the project, I recommend creating a VFD function block similar to the one shown below – having the three input and output words as inputs and outputs to the function block. 

Now, let’s look closer at the 3 input words the drive sends over PROFIBUS.

First, the status word contains information related to the current operating Status of the drive. For simple applications, the most important bits are listed below along with an example code usage.

• Bit 0: Forward Running Feedback
• Bit 2: Reverse Running Feedback
• Bit 7: Drive Error Exists

The other two input words (Speed and Current) contain the measured speed and the measured current of the VFD. These variables are received as a percentage converted to engineering units – meaning 0-27648 raw input corresponds to 0-100% (0-60 Hz when considering speed). For example, a raw input of 13824 corresponds to 50%, meaning the drive is currently operating at 30hz. 

The output Operation word contains information related to the commanded status of the drive. For simple applications, the most important bits are listed below along with an example code usage.

• Bit 0: Motor command forward
• Bit 1: Motor command reverse
• Bit 9: Reset drive error

The other two output words sent to the drive are the commanded Frequency and Torque. Similar to input words, these need to be sent as a percentage proportional to the engineering units 0-27648 to 0-100%. For example, a 60 Hz command frequency or 100% and should be sent as 27648. A 30 Hz command frequency or 50% and should send a value of 13824 in the frequency word. 

Step 3: Configuring the drive parameters to accept commands over PROFIBUS

In order for the drive to correctly operate as commanded by the PLC, the following internal drive parameters need to be changed. This can be accomplished from the front of the drive, using the keypad and display.

After changing the drive’s communication parameters, power must be cycled in order for the changes to take effect.  

Once you’ve cycled power, you’re finished! Your drive should now receive commands from your PLC over PROFIBUS!

Learn more about DMC’s PLC Programming Services. 

The post 3 Steps for Configuring Yaskawa VFDs Over PROFIBUS appeared first on DMC, Inc..

While you can't gear directly to an external encoder, you can gear to another drive that uses the external encoder as an input. There is one limitation: the following drive will only gear to the position setpoint of the leading drive, not the actual position. This can cause following issues when the leading drive is turned by hand, for example. However, when the leading drive is disabled using the MC_Power block, the position setpoint of the drive will be the same as the actual position. This way, you can gear to the disabled axis, and it will behave as if you were geared to the external encoder! Let's look at how to implement this.

For our hardware configuration, we have a 1516F PLC, an external encoder, an S120 servo controller that will control our following axis, and a G120 that will be used as our disabled drive. All our devices are connected via Profinet. The leading axis does not have to be a real drive; in this case, we are going to set the G120 as the leading axis with the external encoder as an input, and then disable the Profinet device using the D_ACT_DP block. This will cause the PLC to ignore communication with the drive, but still communicate with the external encoder. Next, we will create a positioning axis technology object, and configure it to use the virtual drive and external encoder.

You can configure the external encoder to use whatever measuring system works for your system, as well as an appropriate telegram. The telegram used for the drive will make no difference. Next, create a synchronous object for the following axis, and configure its drive and encoder. Our servo has an internal encoder, so it will use that for position feedback.

Finally, go to the Leading value interconnections tab, and select the virtual drive as the leading axis. Notice that the only option available under Type of coupling is Setpoint.

And that's it! The leading axis will be disabled by default, but you can always add an explicit call to MC_Power to make it more clear in your logic. Now anytime the following axis is geared to the leading axis with MC_GearIn, it will be following the position of the external encoder.

The post Relative Gearing to an External Encoder with a Siemens 1500 PLC appeared first on DMC, Inc..