Client - Server application, simultaneous communications results in read_holding_registers not returning #2164
-
|
Der Jan I’m developing an asynchronous Modbus TPIP control program: MetSim. As a client MetSim reads data from 2 Modbus compliant “Energy Meters” and then combines the data. As a server, MetSim simulates the register layout of a single “Energy Meter” and provides the combined energy data to a Modbus compliant solar PV “System Manager”. The “System Manager” then uses this energy data to control the output level of solar PV inverters to disallow export to the grid. As this is a control application, MetSim reads the “Energy Meters” every ~0.18 seconds and the “System Manager” reads the MetSim every ~0.2 seconds. The application is up and running using the pymodbus library simulating both the server and client requirements. I assume I have not considered, how to lock MetSim’s server and client functions to stop simultaneous reading of the TCPIP port, or even if this is possible. Can you please let me know if I’m on the right track in my understanding of my problem and if you have some advice on how I might resolve it? I’ve included a log file snippet showing two successful loops and then the problem, at around line 99, also included is a code snippet for the read_holding_registers section. I have control system and some software experience; however, this is my first use of Python. My IDE is VS code with the Python 3.12.2 interpreter running both on Windows 10 and a raspberry pi-5, the target hardware for MetSim. Thank you |
Beta Was this translation helpful? Give feedback.
Replies: 3 comments
-
|
You do not write which version you use, V3.6.8 have locking builtin for async clients. BUT is works only if the calls are within the same asyncio loop ! If you need multiple loops, then you need to add your own locking. I cannot see any problems in the log file ?? And having multiple clients means having 2 independent sockets each with their own transport object, so that should not cause problems. A number of our test cases, starts a server and a client in the same process to communicate, so it clearly possible. your code looks ok, but there are a number of, lets say not standard usages. The reconnect_delay is far too low for practical purpose, and you prohibit the automatic reconnect, which means you have to call connect() in the app. The read_holding_registers takes optional parameters but you have defined all as positional parameters, that might work today and will most likely change without warning. You normally do not check on client.connected, since the client have the option to automatically reconnect, and if needed retry the request. Please test your app with v3.6.8 |
Beta Was this translation helpful? Give feedback.
-
|
Dear Jan I'm on version 3.6.6 which I installed on the 20th of March, so I will upgrade to the 3.68. I will follow your suggestions, and also try to improve my code implementation. Is there a specific example in the pymodbus documentation of : "starts a server and a client in the same process to communicate" that I can refer to? If I still have problems I will send you a marked up log file showing where the exact issue is. Best regards |
Beta Was this translation helpful? Give feedback.
-
|
Hi Jan |
Beta Was this translation helpful? Give feedback.
You do not write which version you use, V3.6.8 have locking builtin for async clients. BUT is works only if the calls are within the same asyncio loop ! If you need multiple loops, then you need to add your own locking.
I cannot see any problems in the log file ?? And having multiple clients means having 2 independent sockets each with their own transport object, so that should not cause problems.
A number of our test cases, starts a server and a client in the same process to communicate, so it clearly possible.
your code looks ok, but there are a number of, lets say not standard usages.
The reconnect_delay is far too low for practical purpose, and you prohibit the automatic reconnect, wh…