Siemens S7 UDP Connections

Has anyone here ever attempted to use an UDP S7 Connection to receive messages? I have some fairly high-speed, repetitive data that will be sent to the PLC from a process running on a PC, but I've never used UDP to receive data before, although I send data all the time. I have been reading the various manuals (I know, a chore with Siemens), but I have found nothing that specifically lists the limitations and performance. I would like to give it a try, and would appreciate hearing from anyone else who might have tried it before. Just thought I'd ask. Thanks.

Hi S7 Guy,

I've no experience of this myself, but I subscribe to the Siemens Support Newsletter e-mail and it looks as though they've just published a whole bunch of FAQs relating to UDP.

The FAQ document IDs quoted in the e-mail are -

19064839
19064508
19065278
19064178
19064069
19065058
19064070
19064841
19064840
19063963
19065614

You can get to any of these via http://www4.ad.siemens.de/view/cs/en/ and stick the ID number at the end of this partial URL. So, for example, http://www4.ad.siemens.de/view/cs/en/19065278

Good luck!

regards

Ken

Thanks Ken. I will look at those docs. I'm kind of intrigued by using UDP, since it is basically free, very fast, and would mean I don't need other drivers (i.e. an OPC Server). Sounds too good to be true, which means it probably won't work.

Also, has anyone ever used SFC58 and 59 to make their own communications functions instead of using the Siemens communications library?

Nope, I've not tried that.

I've had a look in the past at some unprotected versions of standard comms blocks (DP_SEND, DP_RCV) which call SFC58 & SFC59, and to be honest I was quite happy just to shut the door again and leave them alone. I guess you can imagine the kind of thing - 2KBytes of STL all in one network!! As far as I can remember, the actual SFC calls were relatively simple, it was all the necessary error-checking and error-handling to make the code bullet-prooof that bulked it up.

I've used SFC59 for other much simpler things like just getting fault information from a module, but never been desperate enough to write my own comms routines.

But don't worry, we're all behind you on this one!

Regards

Ken.

I've teased apart many of the Siemens canned functions and changed them to suit my purposes before (I wanted them to work with shared DBs instead of instance DBs). In some cases I was able to eliminate a bunch of instructions, and they ran a lot faster. I have to say though that if I wasn't able to read German, I would have had a real tough time of it. What I've found is that much of the code in these canned functions is used to handle bad parameters, so once you eliminate all of that checking, the rest of the code is fairly straight foward.

I'd like to come up with my own functions from scratch though, and the hangup is finding documentation of what the IO bits in the various cards mean. For instance, if you look at the inputs of a CP340 card, you can see them change, and I have found emperically what most of them mean, but it would be nice to have documentation that said something like "Byte X of the CP340 card is the message telegram size", or "Bit X.X is the ready status bit". I'm faced with the same deal with the ethernet cards.

I'm ready to jump right in this, and if anyone is curious, I'll post whatever I find out.

I have not used the Native TCP UDP function to receive messages but it should work great. I have a project that does SEND UDP 40+ bytes at 20HZ using AG_SEND (not sure of the original #, had to change it). We've also broadcast this at over 40HZ during the testing phase when data collection was more important than bullet proof function. We also use the Passive Write function for that project for them to signal me to enter different states. Search for Native TCP to find it discussed in other threads, there are examples in VB in the Siemens file area as well.

Here, I'll save you some time. I have used UDP for broadcasting messages and the Native TCP, also. I like both. I have attached a native TCP demo and source code given to me by an old friend. It's purpose is for guys like you to "roll your own". Have fun!

Ok, I've hit a road block on this project. I still want to use UDP (I'm interfacing with a 3rd party vendor and they are using UDP broadcasts), but I can't seem to get the CP443 to receive data. Here is how it's set up:

1) I'm using a 443-1EX11-0XE0 V2.3, hardware release 4
2) In the connection table, I am using an unspecified UDP connection.
3) I am currently using port 4100, but I've tried 17000 also.
4) Currently, I am not defining a partner address ("Address assignment in block" is checked). I will be receiving from a Microsoft app, and MS assigns the port when the app launches, so it would be pointless to hardcode a port. Besides, I will be listening only, not broadcasting. If I have to broadcast for some reason, I'll enter the partner IP and Port programatically.
5) I am using FC60 (AG_LRECEIVE).

I am using a network sniffer to analyze the UDP packets, and they look ok. I set up the sniffer to send packets from my PC to the PLC once per second, and those packets are successfully broadcast. If I look at the data light on the CP, it flickers with each broadcast. If I look at the network statistics on the NCM S7 Diagnostics, the received messages increments as you would expect.

But, if I look at the UDP statistics within the same diagnostics, the received value remains at zero. All I can think of is that there is something wrong with the packets that makes Siemens refuse them (I found a note somewhere that mentioned that Siemens will filter the messages to prevent the stack from overflowing).

So, has anyone here received UDP packets successfully before using a UDP Unspecified connection? Should I be using a different connection type to receive these packets?

On FC60, check your "LADDR" and make sure you are entering the value in HEX that matches the starting address in the hardware config, that is in DEC. You have to convert it yourself. How have you configured the "ANY" pointer for the receive data? Does the DB you are sending the data exist and is it LONG enough? Do you get any errors from the "STATUS" output? When you set up the connection in NET PRO does the LADDR and ID# match what you have on FC60? These are a few things I have corrected in the past.

The input parameters to FC60 are ok, and match the connection configuration. The pointer is valid, and the data block exists. I have monitored the status, and FC60 toggles from 0x8180 to 0x8181 constantly (“no data” and “job active”). I also looked inside FC60 to take a look at the SFC59 return values, and everything looks ok there too. So, it looks like the code is doing what it’s supposed to do. There simply isn’t any data being received on the UDP connection, and I have no idea why.

By the way, as far as the pointer goes, what should a person enter for the length? Right now, the UDP data is consistently 24 bytes (66 bytes including the header), but I would like to use this for variable data in the future as well. I can get the length from the packet, but as far as I can tell I have to enter the length before I can get the packet in the first place. Would the sender have to send me a message first to tell me how long the next variable data length will be? Or can I just set my pointer to some maximum length that will always be sufficient?

In short, NO. The problem is, it will not accept varible length data, correctly. You have to define the packet length ahead of time. The LEN handle will give you the same info as the "byte xx" in the ANY pointer. The only thing I know it's good for is, along with the NDR (new data received) it will set a bit high and tell you the packet length for 1 scan. There is no way to purge the buffer or read the data "Stuck" in the buffer. If the data length is set for 50 bytes in the any pointer and the Ethernet module receives 49 bytes, you have to send a byte to receive the data or toggle the run/stop switch to clear the buffer. I have spent many hours with Siemens to have more control over the buffer data. There is no solution, yet. You could set the byte length to a few bytes and see if the data "Scrolls" when you send something to the module.

Well, I got it working. Apparently, there was something wrong with the UDP packet that was being broadcast. I wish I knew exactly what it was, but I can’t repeat the problem now.

Also, RRobbins, not to disregard what you said about the pointer, but what I am seeing is completely different. It doesn’t seem to matter what I give it for a length as long as it’s long enough. The broadcasts are 32 bytes, and I tried a bunch of values between 32 and 100, and it kept right on working. Perhaps they have fixed something during the various hardware releases.

As for the performance, I am just getting started in the validation, but a quick test showed that I was reliably receiving packets being sent every 40ms. The packets contain an index ID, and I received over 15000 packets without missing any.

The best thing about this is that there are no tag definitions or addresses involved on either end. The server just sends me a packet with the data I need, and I worry about what to do with it. Plus, we are not limited to traditional tag data types (dints, ints, etc). If we want to define a component as having 38 bytes and treat it as contiguous data, we can do that. Now, we can set up “recipes” without breaking the individual variables into tags.

If anyone is interested, I’ll post further performance data.

The LEN handle is the received data length. It makes no differce if you trying to write a value to the variable attached there as it is an output value from the block. I haven't used UDP much. I am in the process of putting up a link from my web page to an IT module and show how to use native TCP, programming over the internet, setting up an email server from the PLC to a cell phone, etc. I wonder how long it would take to send packets from a PLC on the east coast, to one on the west coast......

I wasn't writing to the length. I was talking about the ANY input variable, since you have to define a length. You had said that you had to define the length ahead of time, but I don't see that problem yet. I'll experiment some more.

Hello!

Please keep posting the progress on this issue.
I'm interested (and probably a lot of others too) in how to use this communication method.

Regards
Borte