Thread Content
The author tested the MODBUS communication of multiple brand flow accumulators in an application test. Since the flow meters used for testing come from different manufacturers and represent products from various periods (with the earliest models being manufactured in 2004), although they all indicate support for standard Modbus communication, some of these flow meters have their own distinct characteristics in terms of communication; I would like to discuss those with you here. Since technical support personnel who can be contacted cannot always be found for some flow accumulators, it is possible that certain issues are related to problems with the devices themselves or to older models. Therefore, in the following description, Changhui Instruments omits the brand names of these flow accumulators to avoid unnecessary disputes. All the network testing parameters for the following flow accumulators are a baud rate of 9600, 8 data bits, 1 stop bit, no parity checking, RS485 half-duplex network, and Modbus RTU protocol. 1. MODBUS communication for flow accumulators: Ask slowly, or I’m going to stop working. When testing this flow accumulator, by referring to its manual, we found that the data we need is stored in these 14 consecutive registers, ranging from 40001 to 40014 (or from hold registers 0x00 to 0x0D). http://yunrun.com.cn/upload/201912/18/201912181158534406.png Before using PLCs or configuration software for testing, CHANGHUI Instruments prefers to use the ModScan testing software for simple tests. The ModScan test results are normal, and the 7 pieces of data we need can be read. The ModScan configuration is as follows: http://yunrun.com.cn/upload/201912/18/201912181209450469.png After a successful ModScan test, we used the PLC to read the data mentioned above; the correct values were obtained, but it was observed that the changes in these values were very slow ； Further monitor the PLC’s communication status word, which keeps switching between normal communication, verification error, and no response states. Since we have read the correct data, there should be no issues with the register address information as well as network parameters such as the baud rate and station number. So first, the engineers from Changhui Instruments checked the hardware wiring. Since the testing was carried out in an office and the distance between the communication cables was only 50 centimeters, Changhui Instruments did not install 120-ohm termination resistors at both ends of the network at the start of the testing. Well, now that there are problems, we will add those termination resistors; after all, Changhui Instruments has encountered situations in the past where certain devices could not communicate over short distances even when using specific types of cables. However, the problem persisted even after adding terminal resistors and even replacing it with a standard RS485 twisted-shielded cable. At this point, the instrument’s wires were reconnected to the computer for testing with ModScan, and it still worked properly. Furthermore, we monitored the PLC’s data via the serial port and found that it was exactly the same as the data sent by ModScan, just a bit faster. By default, ModScan sends a data request every 1 second. However, in the PLC master unit tested by CHANGHUI Instruments, as long as there is a response from the slave devices, it will send the next data request after 3½ characters of time have passed. Could it be a problem here? In previous work, engineers at Changhui Instruments have encountered situations where some slave devices had weak capabilities for handling communications, or whose programming was inadequate. When the 485 bus was busy, issues such as slow communication response, sluggish device operation, communication interruptions, and even device restarts occurred due to the limited computing power of their processors or improper programming. Just this year, Changhui Instruments encountered a controller in which the device’s display stopped updating its data after too many queries from the master station at 03 ； The central air conditioning controller of a well-known home appliance brand has fast performance, but communication is interrupted intermittently; the device must be restarted to restore normal operation ； A certain analog module experiences distorted analog readings when the speed increases ； A certain pressure gauge restarts immediately when the speed increases. With this in mind, Changhui Instruments added a 100ms delay to the polling logic of the PLC master station; that is, after the master station receives a correct response from the slave station, it waits for 100ms before sending the next request. Verification: The issue has been resolved. 2. MODBUS communication of the flow meter: Do not ask too many questions at once; I can only answer a little bit each time. When testing this flow meter, we also start with ModScan for the initial tests. The protocol and address table of the instrument are as follows. ◆Read the current data: Computer → FC6000 (4–8 bytes): $, 03H, XXXX, CRC. http://yunrun.com.cn/upload/201912/18/201912181225338002.png Based on the table above, we made the following configurations in ModScan; moreover, we set a mass cumulative flow value of 328 on the flow meter to see whether communication can proceed normally. As expected, ModScan read 14 consecutive words of data starting from address 40003, but the results left Changhui Instruments puzzled. As shown in the image below: http://yunrun.com.cn/upload/201912/18/201912181228542641.png, in address 40003, the value is indeed 328, which is what Changhui Instruments hopes for; however, the same value appears in address 40004 as well. In the address table, we can see that this data should be a 32-bit double-word integer; therefore, for the value 328, the value in 40004 should be 0. Even after taking into account factors such as high/low byte swapping, signless numbers, and a 1-bit address offset, this value is still incorrect. Changhui Instruments conducted additional tests and found that the values of 40003 and 40004 remained identical at all times. Then, Changhui Instruments* instinctively wanted to test one value first to see if it could be read. So, in the configuration shown above, the data length was changed from 14 to 1. Strangely enough, the value 40003 could no longer be read at this point. Could the problem be related to the length of the data? So, the engineers at Changhui Instruments carefully reviewed the manual for that manufacturer’s flow accumulation meter, and made a somewhat uncertain discovery (they are still not entirely sure about it to this day). In the above protocol, there is a line that reads: ◆Read current data: Computer→FC6000 (4-8 bytes): $, 03H, XXXX, CRC. Does the 4-8 bytes refer to the fact that we can only read 4-8 bytes of data at a time? Upon closely examining the data in this table, we see that all the data is 4 bytes in length. Therefore, at Changhui Instruments, in ModScan the data length was changed to 2; after this modification, all 7 pieces of data in the table could be read successfully. Finally, we made the following configuration in the PLC to read these 7 data points in 7 separate readings, and the results were normal. http://yunrun.com.cn/upload/201912/18/201912181233126657.png In this case, it can’t be said that there is a problem with the Changhui instruments; rather, it can only be said that their manuals could be written more clearly. 3. MODBUS communication of the flow meter: It uses the standard Modbus RTU protocol… only the checksum is reversed. The issue with this flow meter is more straightforward; when using ModScan to send commands according to the manual in order to read data, the meter does not respond with any data. However, if a small software provided by the flow meter manufacturer is used to test the instrument’s communication, the data is completely normal. Since it uses the exact same physical link as that used for software testing by the manufacturer, there are likely still some issues with the message protocol. This requires us to read the manufacturer’s manual carefully. After careful study of the manufacturer’s manual, Changhui Instruments finally identified a situation that had been encountered very rarely before. The figure below shows part of the communication protocol: 6. Communication commands: Function code 03 – used to read display data; send 01 ； Address response 01 ； Address 03 ； Function code 03 ； Function code 00 ； High 04 of register address ； ； Number of bytes 01 ； Register address low (display address) 80 ； Data 1 00 ； High register count 04 ； Data 2 04 ； Number of registers is 80 less ； Data 3 CRCH ； High 80 bits of CRC checksum ； Data 4 CRCL ； CRC checksum low CRCH ； High CRC checksum CRCL ； Low CRC checksum indicates: Address = Instrument number ； Register address = Display item number ； The number of bytes in the response = the lower 16 bits (1-63) of the register count. In the standard Modbus protocol, the last two bytes of a message are CRC checksum bytes; under normal circumstances, the lower byte of the CRC is sent first, followed by the upper byte of the CRC. If the CRC check is incorrect, the device may not respond to the message. In the standard Modbus blocks or drivers found in ordinary PLCs or configuration software, Changhui Instruments does not offer the possibility to modify the CRC high and low bytes; therefore, in such cases, it is not possible to communicate with this instrument using ModScan or the standard Modbus blocks built into the PLC. Therefore, for subsequent processing and communication with this table, CHANGHUI Instruments uses a custom protocol: it sends messages directly via the PLC’s TX function block, and then receives the messages sent back by the instrument using the RX function block before parsing them. 4. Others: Some flow accumulators come with Modbus RTU and ASCII options. However, during testing by Changhui Instruments, it was found that some flow accumulators refer to RTU as “register mode” and ASCII as “character mode”; this is something that needs to be taken into account when configuring the flow accumulators. As mentioned earlier, many of the data in flow accumulators are typically 32-bit double-precision integer data or IEEE754 single-precision floating-point data. Since it is 32-bit data, the order in which the high and low words or bytes are stored varies among different PLCs or devices. So, if communication is possible but the data read in appears as garbled characters, in most cases, for 32-bit double-precision data, it is possible to swap its high and low words ； For 32-bit single-precision floating-point numbers, since there are 4 possible values: 1234,2143,3412,4321, it is possible to first swap the high and low bytes; if that does not yield the correct result, then swapping the high and low bytes again can be tried. In PLCs, in addition to using the Move instruction for swapping, cyclic shift instructions can also be used to shift a single word 8 bits to the left/right cyclically in order to swap its high and low bytes, or to shift a double word 16 bits to the left/right cyclically in order to swap its high and low words. Some flow integrators also provide this function to facilitate user use. It should also be noted that the floating-point numbers in some flow accumulators are not necessarily in the standard IEEE754 format; they may use a custom numerical format, as shown in the figure below. At this point, we need to write the corresponding conversion program in the PLC or host computer, based on its manual. Author: Zhang Ningwei. Original article: Modbus communication for flow accumulators. http://yunrun.com.cn/tech/2843.html