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.