I am wondering if there is a sensible limit to query multiple registers to a Venus GX using Modbus. I did a sniffer trace and see my client queries every 150ms until all my registers are done and then waits for the next cycle.
Let’s say 10 registers in a 5s polling cycle. Can I query all 10 with a 150ms delay in between?
The question is: What is the recommended time between individual queries that is not going to kill the GX?
Have you wired up the RTS/CTS pins? (not shorted them…)
I would try that and see what speed you can achieve… 
Maybe I’m missing something, but how is that relevant to modbus?
Hmm… Perhaps I should have said Modbus/TCP from a client to the GX over a LAN connection.
So many protocols have been converted to run on Ethernet but the name (kind of) remains the same. This confuses an old timer like myself…
Ok, to delve into more details. When I do a Modbus/TCP query to my GX via LAN each register query is sent with a 150ms inter-query delay window. This means if I query 10 individual registers in a polling cycle I start with register #1 and after receiving a response I wait the remainder of 150ms then send the next one. Once all 10 are done I wait the remainder of 5s as my polling interval and then repeat the cycle.
EG. I query register 1 and the GX responds in 1ms meaning I wait 149ms then query register #2 etc.
The question is, how short a time between individual register queries is considered acceptable? If I make the inter-register query interval too small EG. <1ms then perhaps the GX might get overloaded, the CPU spike and all sorts of nasty things can occur. I need to know a sensible delay for the capabilities of the Venus CPU which is not the most powerful of the GX range.
Shooting from the hip: Do you have a block query that returns a block of registers rather than a single one?
Unfortunately not. The vendor has it on his roadmap so for now it’s a read/response for every register.
I’m pretty sure (100% guess) MQTT is newer and faster in this application.
Perhaps but my Client software is an Appliance interface and only does Modbus/TCP. I’ve narowed it down to a bug on the Client side which overlaps two registers and causes the GX to go into a spasm with illegal reads/writes to a particular register. Initially thinking it was too fast polling I now see that you can probably poll as fast as the device can respond - meaning as soon as you receive a reply to the previous query you can launch the next query.
It’s rather pointless to query more than once a second. Almost all the values (some are 500ms) are updated no more often than that.
I agree when you refer to polling cycles. I am referring to the individual register queries inside a single cycle.
Well, I’ve queried modbus-TCP as fast as it would go, on a CCGX, and never had CPU issues. But of course the easiest is to simply test it.
Thanks for confirming. After some testing I saw the same on the Venus so CPU was not the problem, it was something else which I am still working on with the vendor.