modbus

[boB]

does the classic talk modbus rtu

I moved dlhvac's question to here from the introductions section...

The Classic and MNGP remote (and future products) talk RTU and RTU over  TCP/IP.

No plans as yet for ASCII mode.

One little difference from other modbus users is our default of   19.2 K baud   N,8,1

Usually, I see 9600 baud as the default.

boB

[dlhvac]

thank you very much are the registers avail in the manual

[dlhvac]

I would like to try to integrate one into my niagara ax platform

[boB]

thank you very much are the registers avail in the manual

Not in the manual yet... Soon though.

I Googled niagara ax  but I'm still not quite sure how that works.

boB

[dlhvac]

niagara ax is by tridium it is a building automation protocol

[boB]

niagara ax is by tridium it is a building automation protocol

I took another look at this.  Looks interesting.

What is the advantage of the Niagra AX over say, something like, Mango  for instance ??

Are they similar in function ?  Looks like there is at least some overlap.

boB

[dgd]

One little difference from other modbus users is our default of   19.2 K baud   N,8,1

Usually, I see 9600 baud as the default.

I was reading some modbus specs and communicating via slow async serial lines is normal, 9.6
You say 19.2k on classic/mngp but can this be accelerated up to 38k4?
And what about sync serial rates such as 128k, 512k etc?
Is the 19k2 the limit on Ethernet throughput?

Dgd

[boB]

One little difference from other modbus users is our default of   19.2 K baud   N,8,1

Usually, I see 9600 baud as the default.

I was reading some modbus specs and communicating via slow async serial lines is normal, 9.6
You say 19.2k on classic/mngp but can this be accelerated up to 38k4?
And what about sync serial rates such as 128k, 512k etc?
Is the 19k2 the limit on Ethernet throughput?

Dgd

Right now, you can't change the baud rate from 19.2K.  There should be a future update where
higher baud rate will be necessary and we will need to be able to crank it up at least at that time.

The Ethernet runs pretty darn fast (starts with a 50 MHz clock) but I am not sure what the equivalent baud rate is.  We have done
a lot of testing at high repetition rates to make sure the Classic doesn't choke.

boB

[dgd]

thanks boB

What I was meaning to ask was if the async serial speed was a software limitation and was it a modbus specified limit rather than a serial port hardware limit?

I can understand that in the late 1970s, when the modbus protocol was specified, async serial ports were real slow with many only barely capable of 9600 baud rate but that hardware limitation has long gone. USB serial ports are capable of much higher throughput.

The modbus lib specs I was reading contain a lot a timing delay specifications - eg  send data, delay time, look at reply, delay etc..  a true slowed polling system.  It appears to be designed with these timings so that no matter how fast the hardware link layer is, the effective throughput is as a 9600 async data link. Or in the MN modbus implementation you have stretched the spec to effective 19200 async link throughput.

Why I asked about ethernet was the apparent slow throughput to the local app. Mostly evident in the 380 day onscreen report where it can take up to a minute to retrieve the data from the Classic and fill up the report page.  Or have I got this wrong and the data retrieval is real fast but the local app is just slow filling the display?

dgd

[boB]

I'm not exactly sure why the data logs take so long through the local app.  I do know that
a packet of modbus over TCP/IP for file transfers are limited to something like 125 bytes.

So, being on the safe side, I would rather not burden the Classic with overloading it by
communications so I think that's why the inter-packet space... So that it doesn't
bombard it with requests and mess up its main job of switching and charging.

That processor has a lot to do and communications  runs in the background.

You could run Wireshark   http://www.wireshark.org/   and sniff the packets and see what
is happening there.  Pretty cool program !

The modbus itself is not slow here.   It might be in some systems but I wanted to mak sure this
version ran as fast as it could with whatever baud rate we're using.  Even when the packets
are not destined for a particular classic, it doesn't wait to forward the bytes through
to the next unit with another modbus address.  This is basically modbus but it is,
I think, quite a different implementation in that it has a some additions and features
that most modbus systems do not have.  Like, both, server AND client capability.
Packet forwarding even though it is RS-232 (that is not in the modbus spec)
and a couple of other things that make this implementations kind of unique.

Modbus was the standard that closely resembled our original communications
implementation in the early days so it was decided to instead turn it into a
standard method because then it wasn't some proprietary thing but something
that was documented lots of places (pretty much)...  And others are interfacing
to the Classics in larger installations and it just makes it easier that way too.

BTW, I am making progress on the latest Classic modbus document.

boB

[dgd]

BTW, I am making progress on the latest Classic modbus document.

Yes, I'm looking forward to that, please give me a sneak preview    is there a write to register that terminates ABSORB and starts FLOAT - or is  it in the existing doc and I'm missing it 

dgd

[mtdoc]

Yes, I'm looking forward to that, please give me a sneak preview    is there a write to register that terminates ABSORB and starts FLOAT - or is  it in the existing doc and I'm missing it 

dgd

I believe that's coming as an input function to Aux 2.  Right boB?   
a modbus write function would be nice too!

[boB]

>>> is there a write to register that terminates ABSORB and starts FLOAT - or is  it in the existing doc and I'm missing it  <<<

It's in the existing document and has not changed.

Table 4160-1   ForceFlagsBits   Registers 4160 and 4161

ForceFloatF       0x00000020   Force battery charge stage to Float
ForceBulkF       0x00000040   Force new Bulk/Absorb charge stage


>>>I believe that's coming as an input function to Aux 2.  Right boB?   
a modbus write function would be nice too!<<<

Yes, Aux 2 input to force to Float is coming...
Not sure exactly what you mean by a modbus write function though

boB

[mtdoc]

>>>I believe that's coming as an input function to Aux 2.  Right boB?   
a modbus write function would be nice too!<<<

Yes, Aux 2 input to force to Float is coming...

Yeah! 

Not sure exactly what you mean by a modbus write function though

Oops, maybe I'm not exactly sure what I meant by that either.

Actually  I was referring to djd's question which it looks like you answered i.e. there is already a write to register (4160) that terminates absorb.

Thanks!  Once I get my Arduino do-hickey acurately measuring current I'll be looking for a way to use that info to end absorb -sounds like I'll have 2 options  - assuming I can find the time to learn modbus-speak...

[boB]

Added the Aux 2 function last night to force float when that input is high.

Haven't done the MNGP interface yet to select that function but that is next for this feature.

boB