Socket Messaging Via Siemens S7 PLC

[S7Guy]

Actually, it doesn't read one byte at a time. Where are you seeing that?

If you look at the header of the message, you can see the length in bytes.

 

[Andrew Cullen]

I haven't purchased the download yet, but the entry 19033929 from Siemens describes FB102 as follows:

'With FC6 "AG_RECV" the data is received byte for byte.... If the data is received without error with FC6, the received byte is saved and the byte offset (#B_OFFSET) is calculated via the "#COUNT" parameter for the ANY Pointer receive area. Then the end character "CR" (carriage return) is checked. The the byte received corresponds to the "carriage return", then the length of the data is forwarded as output parameter "#LENGTH" and the byte counter "#COUNT" is set to zero.'

In general, is there a way to know how many bytes are waiting in CP's buffer?

 

[S7Guy]

I think what you are looking at is specific to FB102 and how it looks for a specific CR. I've used socket messaging a lot, and I know it doesn't send and receive data one character at a time. I have sent 2000 byte messages, and 2000 scans would have been unacceptable.

If you dig into the use of SFC58 and SFC59, you can extract the length of the message and the remaining bytes. But normally that isn't necessary- I would just wait for the "Done" bit to go true and evaluate the completed message (I assume you will be looking for either a predetermined length or escape character).

 

[Andrew Cullen]

Escape character??

In my limited experience, I couldn't get AG_RECV to return any bytes at all from CP until the CP's buffer had the full length the RECV parameter.

So, do people pad the length of the transmitted msg? Or do they receive one byte at a time until they can find the length of the msg, if its coded in the header. (Both options require access to the transmitting side program)

So I thought someone might have figured out how to use Rd_Rec to access the number of bytes waiting in the CP's receive buffer.

 

[Bratt]

Escape character??

In my limited experience, I couldn't get AG_RECV to return any bytes at all from CP until the CP's buffer had the full length the RECV parameter.

S7 Guy did you have fixed maximum lengths when working with AG_recv becuse i encountered the same issue and had to switch to fixed lenghts for ag_recv to work properly

This is true you need to have fixed telegram lengths or extract byte for byte for AG_recv to work (Maybe you can loop the call of AG_recv to reduce number of scans needed). This is a limitation in the TCP protocol that dont have telegram lengths. This is why Siemens added suport for ISO on TCP that dont have this limitations. If you add an end char maybe its possible to rewrite AG_recv to handle variable lengths.

Siemens has described the issue here

 

[Rusty_K]

Hey, I've been trying to decide between ordering the CP343-1 Lean or the CP343-1. Seems as though the CP343-1 has support for ISO whereas the Lean does not. Cant seem to find a document that clearly describes what exactly ISO is and what advantages it possesses. I will need to have a rather fast communication speed so reading one byte per cycle may be a bit slow!

 

[Bratt]

CP343-Leans suports Iso On tco but i dont think that ABB suports ISO on tcp or?? Why cant you use a fixed maximum lenght and add and end char where the real data ends? I might also be possible to loop the ag_rec call but i have never tried it myself. I might also be possible to do as S7 guy describes and rewrite AG_recv but i still think you need and end char for this to work.

Have you considered Profibus on the ABB side?

 

[seppoalanen]

Hey, just wondering why is it that using the integrated PN port on an S7-300 requires more programming than when using a CP343?

I think, PN supports TCP/IP but not TCP/IP-Connection.
You will need Connection for socket?
Try it in NetPro .
Try also with CP-Lean Unit .

 

[seppoalanen]

....what exactly ISO is ....

Some Siemens protocoll from S5-World...

 

[Bratt]

Some Siemens protocoll from S5-World...

RFC 1006 (Iso on tcp) is a standardized protocol and not Siemens unique

LINK

 

[Bratt]

You cant add connections in netpro and you cant use AGSend/AGRecive if you are using the PN port. All configuration has do be done with plc code using special functions blocks FB63-->FB68 from the standard library.

 

[Rusty_K]

Thanks for the feedback guys!

Yeah, I looked at the link for communicating via the integrated PN port. Looks as though I have to use the open communication wizard to configure the connections. It then exports a UDT containing the communication specs to the Step7 project. This does seem a little less strait forward than when using a CP Card. Also, considering that I will be communicating to 5 robots I'd like to have a separate processor for the communication tasks, so looks like I'll go for the CP-343-1 Lean.

Like you mentioned Bratt, I think we should be able to have a fixed maximum length with an indicator in the data stream as to where the actual data ends.

To answer your question regarding using Profibus, we are looking at transfering positional & rotational data (X,Y,Z,Rx,Ry,Rz), initially read from a CSV file on a PC via the PLC, to the robot. We are hoping to send this data in a data steam via Ethernet. Using profibus with group inputs didn't seem like the most ideal solution for this setup. We will have a background tasks that will read and store the positional and rotational data which the robot will move to during program execution.

Cheers!

R.K.

 

[Bratt]

Thanks for the feedback guys!

Yeah, I looked at the link for communicating via the integrated PN port. Looks as though I have to use the open communication wizard to configure the connections. It then exports a UDT containing the communication specs to the Step7 project. This does seem a little less strait forward than when using a CP Card. Also, considering that I will be communicating to 5 robots I'd like to have a separate processor for the communication tasks, so looks like I'll go for the CP-343-1 Lean.

R.K.

Note that the lean card only supports 8 connections! I dont know how you plan to do in this case but usually you have one connection (Port) for sending and one connection (Port) for receiving.

 

[Rusty_K]

Wow, nice call Bratt!

I had read that it supports 8 simultaneous connections. What I was not aware of was that there were separate ports for sending and receiving. I'm guessing this is so that you can send and receive at the same time since different sockets are addressed. In that case, maybe the CP343-1 is better (16 simultaneous connections).

 

[Jose Folha]

Ethernet with ABB controler

Hi I want to comunicate a device in ethernet to the called socket message in ABB robot controller, can somebody help me with this matter?

Thanks
Folha