The Modbus protocol is identified by the value 0. Protocol Identifier – Used for intra-system multiplexing. Transaction Identifier – Used for transaction pairing, the Modbus server copies in the response the transaction identifier of the request. Identification of a remote slave connected on a serial line or on other buses. Recopied by the server from the received request. The MBAP Header contains the fields listed i n Table 2. The existence of explicit and implicit length rules and use of a CRC-32 error check code (on Ethernet) results in an infinitesimal chance of undetected corruption to a request or response message. If there is a more elegant solution I'd like to learn about it because I think this bit of code is a valuable addition and it will find it's way into future projects as well.When Modbus is carried over TCP, additional length information is carried in the MBAP header to allow the recipient to recognize message boundaries even if the message has been split into multiple packets for transmission. I havn't written the code yet, but that will be the strategy. I will also add code to my SCADA that will "make note" if the DM value is greater than 15 seconds. If the PLC DM field reaches one minute it will "make note" and could also REBOOT if that's what you need. ![]() If there is an outage then the counter will keep increasing. Nice routine communication means the counter should get zeroed more than once a second. When the SCADA connects it will read the counter, then zero the counter. I will increment the value of a DM field every second. We're still a bit doubtfull, so I'm going to add code similar to what the REBOOT would have done. Once we changed the port number communication has been great. My problem ended up originating from another system (other contractor) using the same IP and port as we were using. Sorry for the late reply BC, got tied up in some other details. You can write to and provide the firmware version of your all the PLCs involved, which we can check against our knowledge base to see if there are other workaround. Note: Continuous improvements have been made to PLC with the newer firmware version to handle potential problems that can caused by bad packets received from the TCP/IP network. Re-booting time is quite fast - typically under 2 seconds and shouldn't impact the system performance especially if such error may occur only once in a long while. The PLC can save the important data or registers into the FRAM and execute a REBOOT command and then load the data back from the FRAM after it boots up. If the SCADA program lost communication with the PLC it will retreat long enough for the timer inside the PLC to time out and the PLC can then go through an orderly shutdown and reboot. You can automate the reboot by having the SCADA program periodically clears a timer running inside the PLC. In this case a reboot may be necessary to clear the out-of-sequence error. Since Modbus TCP has a packet ID the sender only accept a response of the same ID, and if the command and response packets are out-of -sync the communication may not recover properly. the sender receive a modbus response packet that belong to the last command. What you experience could be due to Modbus packet out of sync caused by lost connection. Wi-Fi connection also tend to have more errors due to collision. If you connect the PLC direct via Ethernet and ping it you will see a much lower latency. The ping time latency problem probably has to do with your aerial wi-fi connection (weak signal? Noise?). The connections are as default 3 server and 3 Modbus connections. The SCADA has a re-connect function that upon connection failure tries to re-connect, this is set to 10000ms.Īll of the above work fine when the PLC has been power cycled (a online reset does not help get the communication going ) until the comms error returns.Ĭan I use a set system command on port 4 to set the protocol to modbus without affecting the webserver connections? We only read two registers from each PLC. The TCP master is a SCADA program with polling set to 1000ms for each register / device, with a timeout set to 5000ms. We use the web server function also and this works fine so I don't think the issue is with the connection more the PLC.Īll the PLC's are connected via wifi aerials and generally respond to a ping in less than 100-250 ms so I'm wondering if this is a latency issue on the modbus protocol? ![]() We frequently have communication errors that require re-booting the PLC's to get the communication going again only for it to fail at some point in the future, this can be 1 day or 1 month. We have 15 of them controlling pumps around a site and all of them are a little temperamental when responding to Modbus TCP requests.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |