Hello,

I do not know the bay to start this, so a quick overview: 

We want to build an Open User Communication (TCP/IP, UDP...) application on basis of Basic Examples for Open User Communication (OUC) .

As documentation states: "The FB for controlling the OUC instructions (TCON, TSEND, TRCV and TDISCON) is realized as state machine. The design model of a state machine is particularly suitable for the modeling of complex asynchronous processes, for example, the communication between partners that stretch over several cycles.
A certain state is cyclically run until a transition condition is fulfilled and the machine switches to the next subsequent state. This not only improves the clarity in comparison to a conventional logic controller but also facilitates finding possible errors in the program logic quicker". This is important.

Also: "The application example shows in which places you can integrate your individual expansions in the code". 

There are at least three Application Examples using this approach:

• Basic Examples for Open User Communication (OUC)
• Sending SYSLOG messages with a SIMATIC S7 CPU
• TCP-Fileserver for S7 Controller

This is exactly what the goal is: use OUC to establish connection to communication partner, send and receive some data in reliable way and process errors correctly.

Now to the problem: Most manuals, and forum topics, deal with OUC in following way: establish connection, send data if there are some errors abort connection and check your program online and see what is wrong. These examples do some more processing. As an example of sending some data:

1. Establish communication with TCON. Check errors to see if we disconnect, or reconnect or abort. If connection established continue to sending data.
2. Read data from communication partner, even if he is not sending anything. This is to check communication channel (I think). If error disconnect or ignore and continue processing send requests.
3. Send data to communication partner. If error disconnect or ignore and continue processing send requests.
4. If we are finished with sending disconnect. Check errors and do proper thing.

As always proper reaction on error condition is most difficult

In order to make reliable connection we need to synchronize FIVE state machines: TCON, TDISCON, TSEND, TRCV and user program state machine we program. And this is difficult with information I can find.

To demonstrate: Online help for OUC functions explains inputs, outputs, error codes but does not distinguish between "recoverable" and "fatal" error codes, nor is shows mechanisms for checking connection state (as in our example, with TRCV). There are bits of information on forum from expert users like:

Kaulquappe

TCP uses a keep alive function. This means if there is no data transfer for 30 seconds, a keep alive frame is sent. If the keep alive is not answered by the communication partner, the connection is down. This status is first recognized by the TCP stack of the CPU. When you want to get this information in the user program, a call of TSEND or TRCV is required. The T-block will report the correcsponding error number in STATUS.

 or

Kaulquappe

Hello Gabi,
when the CPU executes active connection establishment and status 7002 is displayed, the CPU waits for SYN ACK of the communication partner.
When the CPU executes passive connection establishment and status 7002 is displayed, the CPU waits for a SYN with the local port number/IP address from the communication partner.

If 7002 is displayed continuously and TCON doesn't set the DONE output, there is an error in IP address or port number (or the communication partner is not switched on or not parameterized for TCP/IP communication).

 etc...

State machines coded in mentioned examples handle error states differently. They are, in my opinion, best structured and handled and can be used only as a base for upgrade. I am rewriting this for my application and would publish the code, but I need some help (please).

Now we come to the question: Is there any document describing state machine of T functions, proper way of handling error states and way to monitor and maintain connection to remote partner? How to handle different cases (TCP/UDP, client/server, read/write) in proper way? If not would some of the experts be willing to share this?

Thank you

drgry

Hello,

I do not know the bay to start this, so a quick overview: 

We want to build an Open User ....

 Hi drgry,

I guess your aproach is to realize a program cappable of handling TCP, UDT, Client and Server at the time?

I don't see any problem in handling the connections and errors. Maybe you need to specify your question a little more so that we can help.

Note: There are also TSEND_C and TRCV_C blocks which handle most of the stuff for you.

First of all, I want to thank you for answering.

As I said, I do not know where to start so this time let's start from end:

For my latest project I need to make mix of PLCs (S7-300 and S7-1200) talk to proprietary PC software using TCP/IP binary protocol. I programmed communication before using knowledge from manuals, online help and forum. But all of these were AD HOC ("just to work") solutions. And they worked.

Before starting I checked support and found these examples. I test "Basic Examples..." and, with some tweaking for my application, it worked. Siemens states that this should be used as base for "standardizing" code for communication. Also this satisfies most of my requirements:

It is SCL so I can use it with both Step7 5.x and TIA (and if you take advise from, well almost everybody, we should code our programs now in SCL and FBD, to which I agree) . It uses T functions so the "almost same" code can be used both for S7-300 and S7-1200.

@Owei: Presence of S7-300 and S7-1200 is the reason to use T functions instead of TSEND_C and TRCV_C.

But most importantly: They use Finite State Machines (FSM) to control communication. I personally believe that FSM are most suitable way to control machines. And I know how to handle them. Then I check the code in the examples and find that, in my opinion, FSM code is not written in most efficient way. So I decide to rewrite this to my liking. And to learn something on TCP communication.To do this it is necessary to check and make all state transitions in order for FSM to work.

And then problems begin: These guys are handling TCP in different way that I have seen before. Also the way they program their FSM does not help much. When I rewrote code I realized what they are doing: normal program sequence is trivial: Connect->Read<->Send->Disconnect. But handling errors is different: sometimes they disconnect, sometimes they just ignore, sometimes they wait for partner to reconnect, sometimes they reconnect. And it is not easy to follow in their FSM. I check manuals and I do not find instructions. I check forum, and all I find ''breadcrumbs" that help me understand the program.

At the end I got program that is stable and working. I successfully initiate connection, send data, recover from loss of communication. But... I have no idea if I covered all special cases. And even worse I do not know if I handled all cases in mentioned example. Problem is they are making transitions, signal SET/RESET and T function parameter assignments which are not clear on first reading.

In order to make program "bulletproof" I seek help understanding how to handle TCP (UDP) communication. Than I can write FSM that is clear and easily followed through. Code in example, again in my opinion, is not so easy to follow.

@Kaulquappe: It is not my intention to make one program to handle all protocol varieties at once. Intention is to know how to handle each case separately and correctly.

@Kaulquappe: Thank you for information on non existing book/manual. 

What I need, and I think many other users, is "codebase" of how to handle connection in correct way. Then we can uniform code and use it properly. That way we can focus on application not on establishing and maintaining connection. And making AD HOC code every time. Using OUC with PLCs is getting more important since we need to communicate with more and more different communication partners.

On my part I am willing to share code from my project so it can be reviewed and upgraded. It will be ready in day or two, in an example of proprietary communication.

@Owei: To specify my question at the end:

Can someone add to the list of rules on how to handle TCP connection using T functions so that a connection can be established and maintained properly? The idea is to have, at the end, common and "standard" codebase for everyone to use, as stated in example manual.

To begin, what I have learned new so far from these examples is:

1. Even if we exclusively send, "dummy" read should be used to check the condition of the connection. I never used this before.
2. Example is using byte array for reading and sending, but if one knows structure of the message VARIANT/ANY pointer to structure can be used with no need for byte array <-> STRUCT transformation.
3. S7-300 and S7-1200 data are BIG ENDIAN. PCs are (at least my WIN machine) LITTLE ENDIAN, so transformation is needed for multibyte data
4. Most examples I have seen so far simply ignore error state, or stop communication, or disconnect. This example uses different approach. This is most obvious for errors with codes 80A3, 80C5(I can not find this code for S7-300 but it is used?), 80A1. If these errors appear connection is not terminated, but instead program waits for communication partner to reconnect (or not?).
5. …

Anyhow, I will have some code ready for publishing in next days. Meanwhile, I would appreciate some help.

Best regards

drgry

To begin, what I have learned new so far from these examples is:

1. Even if we exclusively send, "dummy" read should be used to check the condition of the connection. I never used this before.
2. Example is using byte array for reading and sending, but if one knows structure of the message VARIANT/ANY pointer to structure can be used with no need for byte array <-> STRUCT transformation.
3. S7-300 and S7-1200 data are BIG ENDIAN. PCs are (at least my WIN machine) LITTLE ENDIAN, so transformation is needed for multibyte data
4. Most examples I have seen so far simply ignore error state, or stop communication, or disconnect. This example uses different approach. This is most obvious for errors with codes 80A3, 80C5(I can not find this code for S7-300 but it is used?), 80A1. If these errors appear connection is not terminated, but instead program waits for communication partner to reconnect (or not?).
5. …

Anyhow, I will have some code ready for publishing in next days. Meanwhile, I would appreciate some help.

Best regards

Ok, let's see... In general we have different possibilities to handle the connection. In the end the results are the same... AFAIK (for S7-1200/1500):

Q 1.:
You don't need to do anything to reconnect in case of a connection loss, because TCON tries to maintain the connection on it's own once it was called successfully. This works for the active connection partner and also for the passive one (it's up to you if your PLC is active or passive). This means, as long as you don't call TDISCON your PLC is able to accept or establish new connections over and over again.

So how do you check the condition of your connection on the PLC side? As you already learned you could just simply call TRCV and set EN_R to TRUE. Now watch it's STATUS parameter. Look for status 80A1 or 80C4 to recognize a loss of connection. If one of these two statuses occur you can react within your PLC program. Note: You don't need to reconnect via TCON because this is done automatically by the block, once the physical connection is repaired.

Q 2.: Yes you don't have to use a byte array. TSEND and TRCV are able to handle structures or other data types, too. But in common the basic data type for TCP/IP is array of byte. Because in the end the network stream only sends byte arrays back and forth. I guess it's just not possible to create an example for every data type.

Q 3.: There'll always be problems related to endian. You'll always need to know the behavior of your systems. Also PLCs are not related to WIN PCs.

Q4.: 80C5 means that the partner blocks the connection -> Port is closed or Port is blocked by a firewall.
80A1 (TRCV), 80C4 -> you don't need to do anything related to the connection, see Q1.
80A3 or 80A1 (TCON) isn't related to the socket -> you just messed up with the internal connection ID. In this case you should change the connection ID programmatically.

So most of these errors need to be handled differently. And the right way to do so is very individual and dependent on your needs.

@Owei: Thank you. This is what I could read from Basic Example. I have written the procedure for sending data to partner based on example and your comments and it works fine. Communication is stable and I detect communication problems correctly. You ask what my requirements are. Exactly this: To understand what is necessary to have stable communication and understand what these guys write in example.

In next days I will post a project, based on this and my current project, to test all we are talking now.

@Kaulquappe:

I have no experience in PC programming. All I do is work with (and program) PLC. If you follow closely "resent" development of coding practices, you will see that FSM are becoming more and more "standard" ("becoming" is not exactly correct: lot of library functions, from different manufacturers dating to more than a decade ago, use FSM). If you follow closely PLCOpen recommendations and other documents:

• Part 3 User Guidelines, version 2.0
• Creating PLCopen Compliant Libraries
• PLCopen TC5 Safety Specification Par 1 (Concepts and Function Blocks), version 2.0
• IEC 61131-3: Das ‘State’ Pattern
  

you will se that FSM are the core concept they use. FSM are here to stay. If you look at IEC61499 you will see that at core of the system are FSM. They use different terminology but it is still FSM.

I do not follow closely, but this Basic Example is first use I see with Siemens on support site. They use FSM to coordinate asynchronous processes, and use all elements to process FSM. If you look at Example documentation (Part 3.2 Details on the mode of operation) you can see what they do:

• Evaluation of input data (with edge detection)
• Initialization of the states
• Watchdog guarding of transition states 
• Synchronization of other FSM (T functions)
• etc...

So, in my opinion, FSM are excellent tool any PLC programmer should know how to use them efficiently. And they are here to stay.

Hello,

On following link you can find Project Archive for example use of Open User Communication realized through FSM. 

Project contains two function blocks: TCP_Service and UDP_Service which can be used in projects. Also there are PLC Data Types for defining parameters of connection and example structure for data exchange. Test cases for UDP and TCP communication using two and one way communication are inside also. Communication is demonstrated between one S7-300 and one S7-1200 PLC, but these procedures can be used on other PLC types. There is example of sending data to ibaPDA PC application using VIP data protocol. This example uses small amount of fixed and structured data but can be used on any amount of data supported by T functions on PLC type used.

There are two state transition diagrams explaining inner workings of FB's. These state diagrams are in fact one diagram, but divided in "normal" and error transitions for easier understanding. Numbers in small blue and red circles on start point of transition represent execution order/priority of transition.

Function blocks are capable of two way communication. Examples should be strait forward to understand, but just a few remarks:

1. If sending/ receiving is not needed just omit inputs for send/receive data locations (do not connect these inputs on S7-300, or declare NULL on S7-1200). If length of data is zero there will be no sending/ receiving. Sending is also disabled if there is no send request. In these examples cyclic sending is shown, but requests can be acyclic also. Sending is implemented on rising edge of request. Receiving is defined on fixed length of data, no ad-hoc mode. Setting length to 0 will disable receiving altogether.
2. Regular behavior is rather straight forward: connect, receive/send disconnect. Error handling is more difficult (and this is where I would like your opinion). Temporary loss of communication is handled so no subsequent TCON is necessary. FB will wait for communication partner to come back and resume communication. On all other errors FB will call TDISCON and terminate communication channel. If there is error there are outputs Error, ErrorSource and ErrorValue which will be set. These remain set until error disappears (temporary error) or ENABLE is set to FALSE to reset/disable communication. These can be used to evaluate which T function produced error. Simple tests of loss of communication are performed: cable unplugged and partner disabled have been performed.
   

Anyway I would your opinion. All comments are welcome.

Best regards

I am not sure, but if CP supports OUC than there should not be any problem using these FB.

I have tested these with differently structured data of arbitrary length (as long it is supported by PLC). This is not just test. These FB are used in production environmentn for exchanging data PLC<->PLC and PLC<->PC. Since large quantities of proces data (~kB)of different structure  Is required T functions are used as only option for PC communication. Idea is to uniform communication FB and make it "user friendly" and implemented on different PLCs with minimal modifications. This is what we came up with. What I would like is remarks and suggestions for possible improvement.

Best regsrds