A Forum run by Enthusiasts of MidNite Solar

Charge Controllers and Clippers => The "Classic" charge controller => Classic and Classic Lite BETA Firmware... => Topic started by: zoneblue on November 04, 2015, 03:40:41 PM

Title: 2074, Network performance
Post by: zoneblue on November 04, 2015, 03:40:41 PM
After installing 2074 this morning, here is some data about the modbus connection time. This is the time in millisconds that it takes to request and receive the full register set over modbus over ethernet. This is done using 5 calls of 50 registers, then a sixth call of 44 regsiters thus getting what is/was the full range from 4101 through 4395. The 50 register call is a legacy of RossW's c code. Increasing that to 123 registers which is the largest packet size will reduce this from 6 calls to 3.

Previous to 1849 this complete connection cycle occured consistently in around 12ms. Post 1849 it assumed the pattern on the left side of the chart, 3 or 4ms about half the time, and 207ms the other half. Since the upgrade to 2074, this is now down to 3 to 4 ms consistently. As with 1849 and its ilk, 2074 continues with sporadic outliers up to 2 full seconds. This means the odd connection is skipped when doing 1s sampling*. Overall looks like an improvement.

* NB: this is likely caused by high cpu load on the monitoring conputer.

Ill let this run for 2 weeks to check the reboot issue, and then change over to 1 minute open, read and close samples. That was pre 2074's real weakness.


Title: Re: 2074, Network performance
Post by: atop8918 on November 05, 2015, 02:17:51 AM
As a point of interest 2 seconds is the modbus timeout. This timeout occurs when there is an unrecognized address on the bus and can potentially be caused by rs232 traffic being forwarded from the other connections.
Title: Re: 2074, Network performance
Post by: dgd on November 06, 2015, 10:44:39 PM
Quote from: atop8918 on November 05, 2015, 02:17:51 AM
As a point of interest 2 seconds is the modbus timeout. This timeout occurs when there is an unrecognized address on the bus and can potentially be caused by rs232 traffic being forwarded from the other connections.

Interesting, why would there need to be a modbus timeout? Where would an unrecognised address come from? Is this a register address? if so then requesting data from an invalid register address over an rs232 connection simply returns an invalid request almost immediately 200ms, with the modbus repeat count set in the modbus master (Classic is slave) to 4 this is completely processed in well under a second.
Or does it get more complicated if modbussing over ethernet AND rs232 at the same time?
I thought ZB was only doing ethernet modbus requests?

dgd
Title: Re: 2074, Network performance
Post by: atop8918 on November 17, 2015, 08:22:50 AM
On the Classic there is only one Modbus engine with essentially 4 routing "ports". One for each of the MNG/LP, Upstream, Downstream, and Ethernet. Modbus protocol was designed as a single master only protocol so the Classic has to decide which of the requesting ports is the master. If it receives a Follow me request before an MNGP request, for example, then it will honor the first request and attempt to process or forward the Follow Me request.
If the request is to be forwarded to another unit (say an MNGP on Classic 1 asking for Classic 2's info) then the first classic (Classic 1) is required by the spec to process the first request until its completion. This means that in this example that any other request will have to wait until the first request has finished processing.
If there is any noise on the line (which there will be as this is a switching power supply switching kW of power at 10s of kHz) that causes the corruption of a MODBUS address byte then there is the potential for a malformed message to be forwarded along the chain of networked Classics.