Skip to Content

Register Login

Industry Online Support

Technical Forum

Navigation

Modbus/TCP on S7-317 PN/DP, multiple-client setup

Created by: Mike_O at: 9/14/2018 6:08 PM (2 Replies)

Rating (1)

Thanks 1

3 Entries

9/14/2018 6:08 PM	Rate (0)
Mike_O Posts: 3 Rating: (0)	Software: TiA Portal V14 SP1 Hardware: S7-317 PN/DP 6ES7 317-2EK14-0AB0, V3.2 I have eight Modbus/TCP servers (four Basler BE1-11g, four ABB M2M Ethernet) that I am interrogating for registers. I can successfully read each one if I call only one in the software. Data is read and lands in the correct data reception DB. When I setup all eight devices, each call to MODBUSPN with its' own instanceDB and own ControlDB information (as laid out in the Siemens examples) then strange things start happening. Data read from one device ends in the wrong reception DB, the devices lose connection, they stay "busy" for several seconds, and everything slows down drastically. Each call to the MODBUSPN on its' own works fine when all the others are removed. I have eight separate Parameter DBs, one for each connection. Eight separate Control DBs, one for each connection. I have eight separate DBs for receiving the data into. I have tried polling ENQ_ENR and that has not helped. I've tried using different port numbers for the PLC connections, and that hasn't helped. I'm obviously doing something wrong, but I'm not sure what. The modbus license is valid, and the block does report the package is licensed, even though this should be irrelevant for whether it works or not. The modbus-related blocks are in the "Modbus" folder under "Program Blocks" in the project. This is a stripped-down version of my actual software Attachment ModbusProblem_1.zap14.zip (282 Downloads)
Mike_O Posts: 3 Rating: (0)
Suggestion To thank Quote Answer

9/15/2018 2:05 PM	Rate (0)
Mike_O Posts: 3 Rating: (0)	Success at last. The reason for my problem is that the ID parameter in the parameter block MUST BE UNIQUE across the entire CPU irrespective of whether there are separate Parameter DBs or MODBUSPN instance data blocks. I changed the ID from all 1 to 1, 2, 3, ... ,8 , different for each connection, and now it is much better. Now my next challenge is getting the various connections to reliably initialise and recover from a power failure or cable disconnect.
Mike_O Posts: 3 Rating: (0)
Suggestion To thank Quote Answer
This contribution was helpful to 1 thankful Users dchartier

9/17/2018 9:26 AM	Rate (1)
Kaulquappe Posts: 3093 Rating: (323)	Mike_O Now my next challenge is getting the various connections to reliably initialise and recover from a power failure or cable disconnect. Hello Mike_O, the recovery of a connection in case of e.g. cable disconnect is executed by the TCP stack of the CPU or MODBUSPN automatically. MODBUSPN calls TCON. With TCON the connection data is transferred to the CPU. When the TCP stack of the CPU recognizes a connection termination, it tries to re-establish the connection immediatelly without any additional trigger of the user program. The CPU will try to re-establish the connection until TDISCON is called for this connection ID. Some errors force MODBUSPN to terminate the connection. In this case MODBUSPN calls TDISCON and afterwards TCON. So even in this case the connection will be re-established automatically. Regards, Kaulquappe
Kaulquappe Posts: 3093 Rating: (323)
Suggestion To thank Quote Answer

|

Share this page:

Share this page on...

Related topics by keywords:

ModbusTCP

Follow us on