Skip to Content

Register Login

Industry Online Support

Technical Forum

Navigation

Open Modbus TCP with FB100 problem connect S7 with Foxboro (Invensys) system

Created by: TryOut at: 9/10/2007 4:33 PM (12 Replies)

Rating (4)

Thanks 0

Result pages:: |; 1 | 2; |

13 Entries

Entries per page: 10 | all

9/10/2007 4:33 PM	Rate (0)
TryOut Advanced Member Joined: 6/1/2007 Last visit: 7/11/2024 Posts: 9 Rating: (0)	Hi, I got some problems with open modbus TCP communication to a Invensys Foxboro FBM233 module. I am responsible for the S7-300 system and Invensys integrator blames the strange behaviour on not Modbus compatibility of the Siemens system The S7 is the Server (Slave), the Invensys system the Client(Master) The communication is established for a short periode but drop'sout afterthe first read request from the client. I substituded the Invensys device with a software client (Modbus Poll) and I could establish and read and write data from/to the S7-300 without any problem. Invensys statement is that this proves noting. No I need some information about the transmittion of the packages (SYNCH -> SYNCH / ACKN etc.) especially the connection estblishment and the further data exchange after connection is established.When Ianalyzethepackages with Wireshark I can see the connection establishment and somedata request with the expected telegram contentbut I can not capturethe data exchange. This also not when I use Modbus Poll as client which works. I do not know enough about the protocol but think that Wireshark can not caputure all type of packages. Is there any other analyzer which does the capture of Modbus TCP data packages? Where can I finddetail information (package flowchart etc.) for differnt cases like connection establishment, client timeout behaviour, etc. HW in use: CPU 6ES7 315-2AG10-0AB0 CP6GK7 343-1EX21-0XE0 SW in use: Step7 V5.3 Open Modbus FB100 V1.6 (uses FC5 V4.2 FC6 V4.7) Got other Modbus TCP communication working just fine

Suggestion To thank Quote Answer

9/10/2007 8:34 PM	Rate (1)
Tomcat Posts: 433 Rating: (48)	Hello TryOut, for checking of my telegrams I use Ethereal always. Did you try this? You could test with Ethereal and insert the file here in forum. Did you try to read or write more than 115 registers? With this modbus block it is possible to read/write more than 115 registers, but I know that there are problems with Foxboro and more than 115 registers. It seems that Foxboro can only 115 registers. Tomcat
Tomcat Posts: 433 Rating: (48)
Suggestion To thank Quote Answer

9/11/2007 1:15 AM	Rate (0)
TryOut Advanced Member Joined: 6/1/2007 Last visit: 7/11/2024 Posts: 9 Rating: (0)	Thank you, attached are some zipped trace files. Did it with Wireshark but could them open with Etheral without any problem. The files 10092007_3_50pm_Server Disconnected.pcap and 10092007_3_50pm_Server Disconnected.pcap contain traces from a Foxboro to a Invensys Tricon PLC which was used as test. The files S7_IP_5_........ contain traces using the original system configuration Foxboro / S7 The S7 address is 172.16.203.5 The Foxboro address is 172.16.203.151 What I miss is a sysnch responce from the Siemens system but I do not know enough about the protocol and the package sequence if it is necesary. The Invensys to Invensys system on the other hand shows 3 synch from theClient, some delay after 3 synch / ackn from the Server and after this a "172.16.203.5 where are you tell172.16.203.151" What is strange to me is that the Client port number is differnd. Is it normal that the client port number is dynamic?? As mentioned I do not know enough about the protocolif this is normal. Thanks for your help TryOut Attachment Trace.ZIP (1405 Downloads)

Suggestion To thank Quote Answer

9/11/2007 8:55 AM	Rate (0)
Ltmon Posts: 86 Rating: (5)	Hello, this is not correct! The portnumbers have to be the same over all of the time, they can't be changed. In Netpro you have to project a TCP connection with definitly addresses.The communicationcan't be okay if the addresses are changed. You have to find out why the port address will changed at first. Bye Ltmon
Ltmon Posts: 86 Rating: (5)
Suggestion To thank Quote Answer

9/11/2007 1:05 PM	Rate (0)
TryOut Advanced Member Joined: 6/1/2007 Last visit: 7/11/2024 Posts: 9 Rating: (0)	Hi, I used ModbusPoll as well as Modscan32 to substitute the Foxboro interface for some investigation. With both programs the communication works but I did see that after each communication off/on that the portnumber of the Client changes. There is also no absolute need todeclare the partner IP address and the partner port address in netpro. This is also mentioned in the Siemens Modbus TCP user manul. Thank Tryout

Suggestion To thank Quote Answer

9/11/2007 2:11 PM	Rate (1)
Dorftrottel? Silver Member Joined: 8/10/2006 Last visit: 8/13/2024 Posts: 298 Rating: (29)	If it's opening and closing connections, the client port changing number is OK. When I get a chance later today, I'll compare your pcap files with ones I saved from a long time ago.

Suggestion To thank Quote Answer

9/11/2007 10:50 PM	Rate (0)
TryOut Advanced Member Joined: 6/1/2007 Last visit: 7/11/2024 Posts: 9 Rating: (0)	Thank you UnimogMan what I would like to know is how the packages for the user data packages send with Modbus TCP are marked. I use Wireshark as sniffer and can not capture (maybe not see or recognize) when user data packages are transmitted. (Wireshark is the former Etheral) In may case, when I use Modbus Poll or Modscan32 as substitute of the Foxboro client I can read/write data without any problem but can not determine the user data package at my sniffer trace. In the attached zip file some traces of communication between S7 and Modbus Poll as a client. I assume the problem not being able to establish data exchange between S7and the real client (Foxboro/Invensys) is that Invensys uses Modbus TCP multitasking or any wrong setup. When I analyze the behavior it looks like the synchronization is lost and never established again. Bad luck for me is that to finish this job I would like to get technical support from Invensys but Invensys is not willing to analyzeor check anything on their site except at user level. Invensys prove that their site works ok is to setup a Modbus TCP connection to an Invensys PLC. To me having problems to do this would be like Siemens systems can not exchange data with Siemens.However, people from Invensys Ihave to work with are barely able to understandhow toparameterize the Foxboro Modbus TCP driver and do not knowmuch about Modbus TCP. They also refused tocheck their used Foxboro functionality against theSiemensopen Modbus descriptionmentioned at the user manual of the Modbus FB (like no multitasking etc.)To me after all the analyzing it looks like Invensys is using more than the Siemens Modbus TCP is capable of or the setup (timeout supervision etc.) of the Foxboro driver has to be corrected.However I have to solve it from the S7 site since I do not get technical support from Invensys and to do this I need all the help I can get. Just to mention it, I did have similar behavior when Iprogrammedconnections to other Modbus devices when my timing of reading / writing data as a client was wrong (did not proper use the status of the Modbus FB and started new read/write orders when a previous order was still active. In this casea 'fall back' reading / writing the last orderat the supervision time cycle cleared the fault after a fewordersrequestedwith a delay of the declaredclient supervision time cycleand the communication was working again. Attachment Trace.ZIP (1588 Downloads)

Suggestion To thank Quote Answer

9/12/2007 5:42 PM	Rate (1)
Dorftrottel? Silver Member Joined: 8/10/2006 Last visit: 8/13/2024 Posts: 298 Rating: (29)	Hi TryOut, Looking at your capture files, you can tell the Modbus/TCP transactions easily by setting the filter "TCP.Port == 502". Then all you will see are the mbtcp transactions. Your Siemens Modbus/TCP query is what I term as "packed". I don't know if this is allowed in the protocol. With the one command, you are requesting a read of the same register 9 times (one word from base address 0 [IIRC, that's 41000?]) where a successful query would be to read 9 words starting at base address 0. What data were you requesting from the program block? One comment -- the computer with the IP address 172.16.203.200 is broadcasting IGMP and RIPV1/V2, all of the packets being sent to the IETF. May I suggest removing RIP (add/remove software -> windows components) and turning off IGMP broadcasts in your registry? If you ever find that some networks will not let you on, that may be one of the reasons. Also, are you on the corporate network with this? Your enterasys router is managing subnets with its spanning tree protocol.

Suggestion To thank Quote Answer

9/13/2007 7:52 AM	Rate (0)
Dec Gold Member Joined: 5/19/2006 Last visit: 10/23/2024 Posts: 549 Rating: (107)	TryOut No I need some information about the transmittion of the packages (SYNCH -> SYNCH / ACKN etc.) especially the connection estblishment and the further data exchange after connection is established. Ack flag specifies that the portion of the header that has the acknowledgement number is valid; Push flagtells the TCP/IP stack that this should be pushed up to the application layer program that needs it or requires it as soon as time allows; Reset flag used to reset the connection; Syn flag is used to synchronize sequence numbers with acknowledgement numbers for both hosts; Fin flag used to specify that a connection is finished according to the side that sent the packet with the FIN flag set. TryOut The files 10092007_3_50pm_Server Disconnected.pcap and 10092007_3_52pm_Server Connected.pcap contain traces from a Foxboro to an Invensys Tricon PLC which was used as test. These 2 captured packets it looks bizarre to me: #1 The Server (172.16.203.5) acknowledge a connection request [SYN,ACK] on port 1086 instead of 1085. Are you missing packets? I believe the client closed the socket (1085) and opened 1086 and start SYN again but you don't have these packets. #2 Where are theModbus data exchange packets? Are you missingpackets? Use an Ethernet hub or program the switch to forward allthe packets to the port where you sniff the packets. UnimogMant Your Siemens Modbus/TCP query is what I term as "packed". I don't know if this is allowed in the protocol. From S7_IP_5_6_55pm.pcap I see 9 Modbus requests in one TCP frame. A TCP frame must transport only one Modbus Application Data Unit at a time. "Although it’s possible, it is not recommended to send multiple Modbus requests on the same PDU". Sounds like you are screwed up Although I am not familiarly with Siemens "Open Modbus" implementation it should not matter if client sends 9 ADU in one TCP frame or in 9 frames according to Siemens "Native-TCP" implementation in S7-CP. See variable length case below (I still have hard time to understand the logic behind this note). https://support.automation.siemens.com/WW/llisapi.dll?func=cslib.csinfo&lang=en&objid=1235645&caller=view Dec
	Last edited by: Dec at: 13.09.2007 10:38 Last edited by: Dec at: 13.09.2007 10:15 Last edited by: Dec at: 13.09.2007 10:12
Suggestion To thank Quote Answer

9/14/2007 10:07 PM	Rate (0)
Dorftrottel? Silver Member Joined: 8/10/2006 Last visit: 8/13/2024 Posts: 298 Rating: (29)	Hi Dec, My understand of the variable length in the FAQ is because Modbus does not always require a response data length to be encapsulated in the telegram - that certain responses are always a fixed length, therefore no data length byte is embedded in the response. The issue is in the AG_LRCV block, which specifies the number of bytes to expect when the transmission is complete. If you set the command for too little, you will not get all your data - it will be contained in the next receive command execution. If you set the data length too high, you never complete the communication cycle until the remaining bytes come in (and they never will, since the implementation is a blocking type). I may be wrong, but last I remember, the length of the total TCP telegram is always contained in the header, whether it's a complete response (to whatever original message) or a packet of a response that needs to be reassembled at the receiving end.

Suggestion To thank Quote Answer

|

Share this page:

Share this page on...

Related topics by keywords:

ModbusTCP

Follow us on