Creating a program structure for s7-1200 MODBUS RTU Master with multiple slaves and multiple registers can be challenging. I am facing difficulties in organizing my program for MODBUS RTU communication between my s7-1200 master and 4 slaves, where I need to read the same registers from each slave. To tackle this, I have divided the registers into 2 groups. For example: Group 1 includes registers 4001, 4003, and 4005 Group 2 includes registers 4221, 4223, and 4225 The data from all groups is stored in the same DB, but with different addresses. In the first network, I use the FB "MB_COMM_LOAD_DB" to load data into the DB. In the second and third networks, I utilize FB "MB_MASTER_DB" to read data from Group 1 and Group 2, respectively. Now, expanding this approach to the second slave, which has the same groups as the first slave, poses a few questions. Should I create a new instance data block for "MB_MASTER_DB" for the second slave, or can I simply use a new instance of the FB "MB_MASTER_DB" like when adding a new group of registers to the same slave? Additionally, besides changing the MB_ADDR, what other considerations should be taken into account? It is important to ensure that the FB "MB_MASTER_DB" for Group 2 of Slave No. 1 is not called until the FB for Group 1 of the same slave has completed without errors. Considering storing data from the second slave in a separate DB, with the same structure as the first slave, may also be a good practice. Group 1 and Group 2 registers are consistent across both slaves.
Naturephoenix mentioned that the difference between NW2 and NW3 lies in the use of "DATA_ADDR" and "DATA_PTR." In both cases, the FB "MB_MASTER_DB" is utilizing the same instance data block. Is this the correct approach? Moving on to the second slave (slave number 2), which has the same groups as slave number 1. Should a new instance data block be used for the needs of slave 2, requiring a change in the input parameter "MB_DB" of FB "MB_COMM_LOAD_DB"? Or is it sufficient to use a new FB "MB_MASTER_DB" similar to adding a new group of registers to the same slave? It is acknowledged that MB_ADDR needs to be changed, but is that all that is required? Utilizing multiple MB master blocks (FB) while enabling only one at a time depending on the sequencer. It is essential to only initialize the port once when the PLC starts. By using one instance data block (DB641), the port initialization time can be reduced significantly. Increment the sequencer number only after a short delay if the "busy" signal of MB_MASTER_BLOCKs is "0." Keep in mind that the FB_block is updated by the sequencer, so caution is advised when copying the output signal of MB_master_blocks to multiple variables on the program side. In case of a PLC restart, ensure all "busy" variables are cleared in OB100 block to prevent any issues with communication. Resetting MB_MASTER_BLOCK is recommended as a best practice on PLC startup. When it comes to calling FB "MB_MASTER_DB" for group 2 of slave No.1, it is essential to wait until the previous FB "MB_MASTER_DB" for group 1 of slave No.1 returns done and error-free to avoid any complications. Lastly, it is advisable not to call another MB_master_DB before the busy signal is "0," particularly when dealing with serial data where only one Modbus query can be active on the same port. When it comes to Siemens Modbus TCP, using several queries simultaneously should be possible by assigning different connection IDs to the MB_client block. Keep in mind that there may be limitations on how many sockets can be open simultaneously to/from the PLC.
In PLC programming, it is recommended to use multiple MB master blocks (FB) but enable only one at a time based on the sequencer. By setting the MB master block EN pin high depending on the sequence, you can optimize the use of resources. Different values for mode, data_addr, data_len, and data_point pins may be required depending on the network. For all MB master blocks, it is advisable to utilize only one instance data block (DB641 on the 1200CPU) to streamline port initialization when the PLC starts. The MB master blocks (FB) and (DB) should be linked to the MB_comm_load block. It is essential to clear busy variables on the OB100 block upon PLC restart to prevent any issues with communication. Additionally, resetting the MB_master_FB block and giving a reset signal to the block during PLC startup can help maintain efficiency in programming. It is crucial to be cautious when copying output signals from MB master blocks to different program variables, as they are only updated by the sequencer. By following these guidelines and best practices, PLC programming can be more organized and effective.
This manual pertains to the S71500 CM PTP function and provides guidance on utilizing the Modbus_Master instruction. When calling Modbus_Master with different parameter settings, such as MODE and DATA_ADDR, it is crucial to ensure only one call is active at a time. Otherwise, the system may return error code 16#8200 indicating an ongoing request. Additionally, if parameters are changed before a query is fully completed, the system will terminate the second call with ERROR=1 and STATUS=8200. It is important to note that these details were not previously included in the manual. For further information, please refer to the official Siemens support page.
Lare mentioned the document in the link provided for the Siemens CPU 1500 manual. The information is also applicable for the CPU 1200 and should suit the requirements. The manual outlines procedures for dealing with "New Slave" or "New Communication Job" scenarios. For a different setup with more slaves, adjustments need to be made to the loop and storage DBs. Each slave has three communication jobs, such as reading voltage, currents, and alarms, requiring the program to accommodate for 12 slaves by expanding accordingly. To handle new communication jobs for the same slave but different Modbus registers, the program treats them as separate slaves with varying data address and length, while maintaining the Modbus address. Each new communication job results in an additional entry in the "Master_Comm" array in the "Comm_Data" database. Despite concerns about the internal memory capacity of 50KB, additional memory can be purchased if necessary. Overall, the provided information has been greatly beneficial.
Getting started with Siemens and Modbus may pose some challenges, but the sample works smoothly with 1200 series CPUs. However, for 300/400 series CPUs, there are no sample programs available. In such cases, I had to refer to S1500 samples and manuals, which was a lengthy process a couple of years ago. Eventually, the programming on 300 series CPUs is quite similar to that on S1500, but lacks indirect addressing and loop functionalities.
I think creating a new instance data block of "MB_MASTER_DB" for the second slave is a good idea; it will give you more clarity and segregation in your program. This way, you can ensure that both your slaves are independent of each other, making handling errors and troubleshooting much easier. Regarding your additional considerations, be mindful of the MB_CON parameter - remember that it needs to be set differently for each of your slaves. Also, ensure to stagger requests to your slaves, as simultaneous requests over the same network may lead to data collision issues.
✅ Work Order Management
✅ Asset Tracking
✅ Preventive Maintenance
✅ Inspection Report
We have received your information. We will share Schedule Demo details on your Mail Id.
Answer: Answer: It is recommended to create a new instance data block for "MB_MASTER_DB" for the second slave to ensure clear separation and management of data for each slave.
Answer: Answer: Besides changing the MB_ADDR, you should also ensure that the FB "MB_MASTER_DB" for the second slave is not called until the FB for the first slave has completed without errors. Additionally, consider storing data from the second slave in a separate DB with the same structure as the first slave for better organization.
Answer: Answer: Yes, the Group 1 and Group 2 registers are consistent across both slaves, making it easier to manage and maintain the program structure for MODBUS RTU communication.
Join hundreds of satisfied customers who have transformed their maintenance processes.
Sign up today and start optimizing your workflow.