The magnetostrictive level gauge experiences issues such as partial shutdowns and address changes in oil storage tank areas
Thread Content
Magnetostrictive level gauges are used in large oil storage tank areas; they output signals in MODBUS-RTU format via a bus system, and the microcomputer system connected through RS485 is used to display the liquid level and temperature. Irregular crashes and address changes occur, and crashes can be resolved by restarting the system, but after some time crashes and abnormal address changes along with altered parameters reoccur. The system still freezes after removing the temperature sensor, but the addresses and parameters do not change randomly, and it functions normally after restarting. The on-site testing of each individual level gauge is normal. Explanation of installation and wiring: The entire tank area consists of buried chemical solvent horizontal tanks. The tank area is located near the dock, in an open flat area, and none of the zones are affected by large motors or other large-scale equipment. There are 120 in total. The power supply within the tank area is provided by one set of wires, while the signals are divided into 12 groups of 10 each; these signals are connected to 3 four-channel communication modules. Isolation modules are installed for the power supply of each group, and all of this is then connected to a microcomputer system for display. Have any of you sea gods encountered similar problems? How were they resolved? Please analyze and discuss this matter, and share your valuable insights. Thank you! Automatic control instruments
Additional note: The liquid level, along with the temperature measurement, is within the same signal packet; the address keeps changing randomly, and the system freezes. After resetting it to the original address, it operates normally for a while before the problems recur. When all temperature sensors in the same group are removed, the address does not change randomly; instead, the device freezes. It resumes normal operation after being restarted, but freezes again after some time, and then works normally once restarted once more.
Pigs crow and chickens crow in the middle of the night. . Freeze crashes occur when the program runs to invalid addresses; ultimately, it’s due to the poor interference resistance of the instrument – its design is simply inadequate. As for the point of failure, whether it’s due to poor software design, inadequate hardware setup, or a combination of both, this issue is even more difficult to resolve than chip-level repairs; I’m afraid you might truly be powerless to diagnose it. What brand is whose watch? I’ll tell you more once I know, otherwise I won’t talk about the closing.
Is it a domestic brand or an imported brand?
If possible, another unit should be used for comparison by means of current output rather than communication; if this unit does not crash, then the problem lies in the communication aspect. For example, the main unit may try to communicate with the level gauge without receiving any response, continuously sending requests, which overloads the level gauge and causes it to crash.
Do all twelve groups have problems at the same time, or just one of them?
Domestic brands – problems arise in every batch; there’s no pattern at all!
Is a dedicated Modbus cable used for this bus? Are the terminal resistors being used properly?
There’s probably a problem with the 485 signal communicator. I’ve encountered similar issues before; one manufacturer provided a communicator that combined various signals together, and things worked fine after switching to that one. It’s also possible that one of the 425 modules is faulty, but this is less likely. If possible, it’s advisable to isolate one of the signal paths and test it separately, using a round-robin testing approach to identify the problematic set. However, the chances of that working are low; it’s most likely a problem with the communicator. I don’t know the details of your on-site hardware setup, so this is just a guess based on my experience