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.

Connection

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.

TCON

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.

TUSEND

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.

Summary

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
N20 M50 ;CLAMP PART
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.