Sinamics Safety Integrated

It would be a rare case in which your risk assessment does not indicate some level of safe control required in your drive system. This can be as simple as requiring safe disable of all VSDs in the event of an emergency stop or could get quite complicated, requiring position or speed limiting depending on what doors or guards are open and for setup purposes. Luckily, Siemens offers a range of functions in the Sinamics drive range to help you achieve your requirements (up to SIL2, PLd, Category 3).

Basic Functions

Siemens provides the basic safety integrated functions of Safe Stop 1 (SS1) and Safe Torque Off (STO) as part of the package when you buy a Sinamics drive system. You can select these either through ProfiSAFE (from a failsafe PLC) or via terminals. Neither of these methods require you to buy a safety integrated option.

Terminals: in order to achieve the requirements of SIL2, PLd and Category 3 you need two independent channels to evaluate the command signal. One channel is wired to the EP+ terminal of the drive, the other must be wired to an isolated digital input on the control unit. It can be wired to any isolated digital input, but not to a bidirectional input/output. Additionally, while STARTER will allow you to connect internal drive signals to the “CU input” while offline, this type of configuration is not permitted and will be rejected if you attempt to download to the control unit.

Safe Stop 1: Stops along the OFF3 ramp (fast stop – set in p1135). If using terminals, as soon as the SS1 time has expired (p9652 and p9852 – must be the same), safe torque off will be applied.

Safe Torque Off: Safely disables pulses – i.e. no current and no torque in the drive. Analogous to turning off the contactor on DOL motor – but not quite. There is still a possibility of voltage available at the motor terminals, so for maintenance you would still need to power down the machine.

For motors with brakes you can also activate Safe Brake Control as part of the basic functions. Note that because the efficacy of the brake depends on its mechanical condition, this function has a weak point where a single failure can cause a hazardous situation (brakes are typically only required when there is gravitational potential energy in the axis the motor is driving). This means Safe Brake Control does not meet the requirements of SIL2, PLd or Category 3.

Extended Functions

Extended functions include: Safe Stop 2 (SS2), Safely Limited Speed (SLS), Safely Limited Position (SLP), Safe Acceleration Monitoring (SAM). These can be activated via ProfiSAFE from a failsafe PLC or TM54F. Note these require an option purchased from Siemens.

SS2: This is similar to Safe Stop 1 except that once the motor comes to a standstill it remains in closed-loop control (i.e. Safe Operational Stop). If the motor moves from position during safe standstill, the drive will disable with a safety fault which will prevent re-enabling of the drive unless it is cleared either by powering off and on or performing a safety reset.

SLS: Four selectable levels of speed limiting are available. This is transparent to the system, if the speed limit is violated, a stop will be triggered. It is up to the higher level control to avoid programming speeds in excess of those allowed by the safety system.

SLP: Info to come.

SAM: Info to come.

Tool Management – Useful System Variables

$TC_MPP6[magno, locno]

Magazine Place Parameter 6: I like to think of this as the magazine mapping. It gives the internal tool identifier or tool number (a number between 0 and 32000, inclusive) of the tool occupying this location (locno) in this magazine (magno). Zero (0) means no tool in that location. To find out which tool is in the spindle, you would use $TC_MPP6[9998,1] – incredibly handy!


Tool parameter 2: Tool ID (a string) – this is what you use to call a tool, as in T=”CUTTER”, or T90. Note, in the latter case, $TC_TP2[x]=90, but x is not necessarily equal to 90, and is more likely to be some completely different number. It is important to remember that when reading the Siemens documentation, any parameter that uses the tool number to address it will use the internal identifier, not the tool ID.

$TC_DP3[toolNumber, edgeNumber]

Cutting Edge Parameter 3: Length 3 which is generally applied in the Z direction for milling applications (G17) in both 3 and 5 axis milling. In standard 5 axis milling with the system in G17, Length 3 will be applied along the tool vector in TRAORI.

$TC_DP6[toolNumber, edgeNumber]

Cutting Edge Parameter 3: Tool radius (by default – can be changed to diameter via machine data). Very important when using cutter radius compensation (e.g. G41, G42, CUT3DC).

Drive-CLiQ Topology General Tips

Drive Group and Drive System

In Sinamics, each individual control unit has it’s own drive group. Multiple drive groups can be combined into a drive system which might be controlled by a higher level motion controller to co-ordinate movements but each control unit will only know about the components located in its drive group.

Standard Topology of a Drive Group

In the standard configuration, you would connect X100 of your Control unit to X200 of your first drive. Then you would daisy chain from X201 of that drive to X200 of the next drive. Motor encoders (be they attached via SMC, SME or just drive-CLiQ) would be attached to X202 (or X203 for the second drive on a motor module). The infeed (if it has drive-CLiQ) can be inserted in the daisy chain or connected separately to the CU (i.e. through X101).

You are not required to place all drives in the group on the one daisy chain. However, any daisy chain that exists must follow the X201 -> X200 pattern.

The standard topology doesn’t handle direct encoders. These can be attached to any free drive-CLiQ port in the group, but must be configured correctly using Starter.

Use of Hubs

Drive-CLiQ hubs can be used to minimise cabling and also to provide additional Drive-CLiQ ports for the connection of additional encoders and Drive-CLiQ devices. The device numbering convention works a little bit differently on hubs than you might expect so it is important to note the port number your device is connected to and cross-check this with your project.

Be sure to remember that you can only use hubs to connect devices which belong to the same drive group. Example: you have three drive-CLiQ motors: Motor 1, Motor 2 and Motor 3. Motor 1 and Motor 2 are in Drive Group 1 and Motor 3 is controlled by another CU in Drive Group 2. All three motors are located in the same spot on the machine and you would like to reduce the cabling back to the drive cabinet. If you put a Drive-CLiQ hub in, you could only connect Motor 1 and Motor 2 to it and it would belong to Drive Group 1. Motor 3 would still have to be cabled back to the cabinet. If the cabling is long enough that saving one run is worth the cost of the hub this might be worth it. However, it makes more sense to try to re-arrange your drive groupings so that Motor 3 is also in Drive Group 1 and can be connected to the Hub.

Device Numbering

The Drive-CLiQ topology is traversed as a depth first tree, with the control unit as the root. In the standard topology (ignoring infeeds), the CU would be numbered 1; the first drive 2; second drive 3 … (n-1)th drive would be numbered n and its encoder would be device n+1. As encoders are the last node on any branch, the traversal would return to the (n-2)th drive and its encoder would be device n+2 and so on.

Why Doesn’t My G-Code Program Work? Have you tried STOPRE?

Understanding STOPRE and NEWCONF

There are many reasons why a G-code program can fail. In this post I’ll just be looking at a couple of commands you may not have heard of which can save you from a lot of otherwise inexplicable bugs.


Relatively simple one here: you’ve changed machine data in a program and are confused as to why you’re not seeing any effect. It comes down to those two little letters beside the machine data.

First, “im” is immediately active, just set and forget. Second, “cf” is only active after a NEWCONF or by pressing the “Set MD to Active” softkey (or by pressing reset – if all else fails, press reset). Note: the “Set MD to Active” softkey does nothing while a program is running, you will have to reset the program in order for it to work. The “re” and “po” are channel reset and power on reset respectively and therefore are not particularly useful if you want to set data live within a program.

Take home message: if you set machine data within a program – first make sure it’s going to work but checking how it’s activated; second, use NEWCONF.


STOp PREprocessing. Here is where a lot of software writers get tripped up when writing programs to be executed on an NC. G-Code is sequential (whereas PLC code is cyclic) – that part’s easy enough; in a normal computer program on line is executed after the other – sequential, easy.

The difference between the NC and a computer is that some lines in a program take quite a bit more time to execute than to calculate (for example movement commands), so there’s quite a bit of extra time up the NC processor’s sleeve. In a lot of cases it is important to know what the next 20-50 movement commands are so that the NC can plan axis acceleration, deceleration and block smoothing. Combine these two together and you get the pre-processor – the NC will read in several lines of code ahead so that it can optimise what it has to do now. This is great for standard G-code and CAM output, but when you start writing parametric code which performs calculations on the fly, it can get messy.

What’s the problem? Well, the NC can have a movement command sitting in the pre-processed blocks which contains a calculated value (e.g. an R-Parameter). At some point later in the program this value gets re-calculated. Unfortunately, this has the effect of changing already pre-processed block so that by the time it is actually executed, it does something other than what was planned.

Solution – use STOPRE to perform a preprocessing stop before new values are calculated, this forces the buffer to be completely executed before processing any further lines. Be warned, though, excessive use of STOPRE (particularly in long FOR or WHILE loops) will blow out the execution time of your program.

UDP Communication using 840Dsl

I recently came across an application for 840Dsl which required communication over ethernet from the PLC. Upon adding in the Siemens standard blocks (FB63-FB67) I found some gaping holes in the documentation which I hope to rectify.


Whether you are using TCP or UDP you will need to set up a connection. You do this in Net Pro: Select the CPU of the 840Dsl, right-click and choose New Connection. You will have to choose an ID for the connection and possibly a communication partner (unless you choose UDP broadcast/multicast). This part is key, because all the standard communication FBs will need to know this connection ID.


The documentation is largely sufficient to sort out what you should do here, however, it doesn’t tell you anywhere that the local_device_id in UDT65 should be B#16#4 for the Sinumerik 840Dsl – this is pivotal. Also, you will need to setup the connection ID in both the UDT65 data as well as the ID input for the TCON call.


My biggest problem using TUSEND was that I was consistently getting an error 80C4. A couple of things I found: multicast doesn’t appear to work, even if you have setup your UDP connection as multicast you will need to specify a receiver’s address; despite configuring the connection on the company network I found all my packets were going out over the Profinet bus – I needed to set the receiver’s address within the subnet of the Profinet I/O system and I had to connect my receiver on that bus.


UDP communication with 840Dsl is possible but it doesn’t work the way you’d expect.

Read-In Disable

DOConCD is an incredibly useful resource with myriad pieces of information. What is lacking is some solid guidance on how to use this information. Here are some tips to get around some problems I have faced with DB21 and more specifically, read-in disables.

Always modify DB21 at the end of OB1

Why? Mainly because of the way M-code synchronisation works between the NC and PLC. If you want your user program to have any meaningful effect on your NC program execution, there are certain bits which should be written only at the end of OB1 (once you’ve had a chance to request, say, a read-in disable). Take the following simple program: M50 is used to clamp a fixture and the PLC sets a read-in disable until the fixture is clamped:

N10 G0 X0 Y0 Z100 S10000 M3
N30 Z10
N40 G1 Z-50 F1000
N50 G0 Z100
N60 M30

DB21 modified at the beginning of OB1

  1. NC program executes up to N20 where it calls M50 to clamp  fixture.
  2. NC delays execution until the PLC acknowledges the M50 command.
  3. PLC sets read-in disable based on the status from the previous scan (no clamping request so no read-in disable).
  4. PLC user program detects the M50, requests clamping and requests a read-in disable (this one will only be read in the next scan).
  5. PLC scan completes, M50 acknowledge occurs NC continues with execution of block N30.
  6. After the next PLC scan the read-in disable will be active (assuming clamping feedback hasn’t occurred). This will only affect block N40 onwards.
  7. End result: Read-in disable didn’t work as expected, the program continued when it should have stopped.

DB21 modified at the end of OB1

  1. NC program executes up to N20 where it calls M50 to clamp  fixture.
  2. NC delays execution until the PLC acknowledges the M50 command.
  3. PLC user program detects the M50, requests clamping and requests a read-in disable.
  4. PLC sets read-in disable.
  5. PLC scan completes, M50 acknowledge occurs NC delays execution of block N30 until read-in disable disappears (part clamped).
  6. End result: Read-in disable worked as expected, the program waited for clamping.

What about the rest of DB21?

Sure my main reason for putting all your modifications of DB21 at the end of the cyclic scan is to prevent wayward read-in disables. I also like to compartmentalise my use of interface signals so I will have an FC which just handles channel signals. In this case you would make this the last FC you call in OB1.


So you want to start writing your PLC program and you can’t decide which language to use. Maybe you’ve written a few programs now and you think you’re pretty good so you’ll give another language a try. Which one to use: Ladder (LAD), function block diagram (FBD) or statement list (STL)? (I’ll leave SCL and GRAPH for another day).

Well, good news, whichever choice you make you can reverse. Didn’t like FBD? Just change it to LAD. LAD taking up too much screen space? Why not try STL? However, sometimes swapping and changing doesn’t work quite right and so I’ve put together some things to consider when picking a language.

Pros and Cons

So what is the difference between these languages? Surely they must all have their pros and cons.


Ladder logic is a visual programming language based on the concept of representing each individual network as it would be shown in a circuit diagram for relay logic. This language is best for people who come from an electrical (as opposed to electronic or computer science) background. Diagnostics are made easy as the individual contacts are highlighted to show the RLO (result of the logic operation) so you can quite quickly find out what is preventing your coil from turning on. Disadvantages are that once your networks get more complex it becomes impossible to see the whole thing on the screen at a time. NOTE: converting your existing hardware relay logic to LAD directly may look correct but will most likely not work as expected – PLCs are sequential, relays are not.


Function Block Diagram is better for people coming from an electronic or computer science background as it is a visual representation based on logic gates. Diagnostics are a little less clear than LAD as it is harder to see the individual inputs to a gate but the gate as a whole is highlighted based on the RLO. Depending on your network, FBD representation may take up more or less screen space than LAD.


Statement List is often the quickest way to write your PLC. Copy and paste is quicker, making small modifications is quicker. Performing more complex operations like loops and jumps and indirect addressing becomes easier in STL. You can also bypass the type checking that occurs LAD and STL, want to load a byte into an int? No problem. HOWEVER, it is just about impossible to debug, particularly if you are using it for all the complex operations mentioned above. Also, just because you can load a real number into a double word doesn’t mean that the result will make any sense to anyone. STL is powerful, but you have to know what you’re doing. NOTE: it is entirely possible to write STL code which Step7 will not be able to convert back to LAD or FBD leaving you stuck trying to debug in STL.


Basically, it depends on who is going to have to maintain the software and what you are trying to do with it. Most of the places I go to electricians will be performing maintenance tasks and debugging problems on the PLCs I write. In these cases I use LAD wherever possible. Picking FBD is still valid and comes down to personal preference as the maintenance personnel can freely swap between these two languages.

STL, I’ll admit, I use more than I should. It allows me to rapidly write code and to do things in one network that would take me 100 networks in LAD or FBD. However, I avoid using it whenever dealing with hardware inputs or outputs as these are the things which are most often the subject of maintenance debugging. I also keep it to simple networks (yes, I still write loops and jumps) so that it is easier to detect bugs later on.