New Battery Monitor For Systems using A Classic & utilising MNGP

[boB]

Where to start? I can't see any necessary reason  to have the Classic communicating via 30+year old protocol that was designed for use PLC devices of 1970s vintage. Limited data structures support (eg no array, stack, record, file types..), good for the few registers/accumulators those PLCs had, master/slave configuation with serial comms performance suited to 110baud serial links. Polling registers continually to test for data changes/updates, no active register notification, ie no interrupt driven data change reporting,...  ad nau.seam.
Ok modbus over ethernet offered some improvements but you can't  do much about its archaic design, awful polling interface, repetitive small data element retrieval to d/l any decent volume of data, cpu cycle waste at both master and slave ends, one-to-one active connection only (perhaps this explains why only one local app on one computer can connect to a Classic - ie  Modbus screws Ethernet), ad naus...

So what should the  comms protocol be?

I would tend to go for a top-down design of user interface rather  the bottom-up approach starting with a register level comms protocol.

Top for me would have been a built-in web server in the Classic. So accessing the Classic with a web browser would display a status page that went
on to various setup and reporting pages, grapichs displays etc.   Same for design of new BM.  Its not exactly rocket science to do this, when I look at the web interface in my Cisco/Netlink WET54G box
This, IMHO, would be a much more satisfying experience for Classic owners/users than dealing with  modbus dependant applications.
I won't mention the MN Local App, oops I did..

dgd

The Classic isn't 110 baud, it's 19.2K on the RS232 ports.  Heck, RS232 is way older than modbus and
it is still used today.

It is also not only a polled system...   You can read and write from/to the Classic over the bus.
The network, as it sits now, can handle 2 simultaneous ethernet connections at once.  One for
My Midnite where it calls into a server and the other which can be something like the local app
or any modbus over TCP/IP connection to the Classic.  The Classic modbus network can be
both a client or a server which is non-standard.  So, in that regard, the Classic actually could
tell the other end when something changed.  The RS-232 modbus software also goes
beyond standard modbus by forwarding packets out the opposite port when the address is
not destined for the Classics' set address.  We can add other communications protocols
for different situations if we need to.  So we are not designed into a corner if we
need to switch direction when say, networking Classics for other reasons like paralleling.
Modbus work great for the 99% of what we are doing.

If the Classic were just a web server, it would be harder to control the Classic.  The modbus
protocol was also picked several years ago now so a lot of work has already gone into it.

The main reason for picking modbus was that we wanted some kind of standard RS-232
protocol to transfer data.  I originally had my own protocol which was similar to modbus
but that would not have conformed to any standard as far as address bytes, commands,
data, CRC checksum at the end and the minimum 3.5 character silence in between packets.
So, modbus made perfect sense.   It works as well I think as anything we could come up
with by ourselves and a lot of customers already understand this format and are communicating
with Classics with their own software.  How can we beat that ?  And, 19.2 K baud is still
19.2 K baud with the simple overhead of bytes that would be there no matter what
protocol or format we chose.   Even if there were some slightly better way of organizing
the way bytes are read and written, why would we want to spend the mass amount of
time to change direction ?  Midnite would be out of business if we tried to do that.
Ain't gonna let that happen anytime soon, I hope.  We can make changes as needed
for special needs.

Having said that, it looks like the Classic may very well have a web interface built
into its network capabilities as well as being able to SMTP an email to the user to
their email address of certain chosen status and/or error information.

Top down user interface changes will not happen for the same reason we won't
change willy-nilly from modbus.  We will however make improvements to the U.I.

Now, if this were just a hobby, this might all be different, but it isn't.  It's a lot of
hard work and many man years of time involved in getting to where we are today
and it's not done yet as you can see.

Newer functionality would be available by updating the firmware of existing Classics
as we get round tuits.



boB

[TomW]

dgd;

Good and valid points!

It sure seems everything has a web interface these days. That makes it cross platform (very good), user friendly, extensible and flexible. All good.

I am not in the loop on why things are the way they are.

History shows that the better method does not always prevail.

Beta Max was technically superior (IMHO) to VHS but you don't see many Beta Max units in use today as a "ferinstance".

I just despise modbus because there seems to be a lack of options for some hardware like Arm. I could not find a port of modpoll for my Raspberry Pi or my Linksys NSLU2. Exactly the kind of low power devices that should be interfaced with an RE system for control and monitoring.

I won't even go on about Adobe Air.

Sadly, you can't please everyone and you have to cater to the widest swath of users which is not the lean and mean bleeding edge hardware with a limited user base.

No answers, just more whining.

Your router web interface analogy is a great example of what is possible in that regard, especially dynamic content and configuration management. Could probably easily access the existing modbus system internally, too, similar to the Local App?  Once you have that ability you can control the system from remote via cgi scripts much like I do with the CAI Webcontrol boards I have scattered around the ranch here. Gather data, send commands, monitor alarms and status, the list goes on and on all from a web browser on any platform anywhere on this interweb thingy. If you desired.

Just from here.

3 AM and I am rambling up way too early.

Tom

[dgd]

@boB

Thanks for your reply.

I can actually appreciate where you are coming from and your investment in time and expertise getting modbus to where it now does what you want.
My point is that modbus is not useful for classic users. It's just too primitive and needs a lot of effort from users to understand and write program's to make use of it.  I think it's unlikely more than a few classic owners/users want to or are capable of this primitive interface programming.

The world standard user interface tool is a web browser, every man, woman, child and their dog has access to one. Just about every 'intelligent' device offers a web interface.
So I think this is the user interface the Classic should be providing.

If the hardware has the resources then I would suggest :
Local App development ceases, make the current release the final production version.
Obtain web serving software for the classic and get it installed
Commence developing in HTML code the web pages the classic will offer, eg status, reporting, setup etc..

All IMHO of course..

Dgd

[dgd]

..
Your router web interface analogy is a great example of what is possible in that regard, especially dynamic content and configuration management. Could probably easily access the existing modbus system internally, too, similar to the local app...
..
Tom

If there was a web interface in the Classic (or BM) then the HTML code for the web page would simply map a data structure, such as an array or record, over the physical memory, ram or flash or whatever, and access data values by reading the data structure.  There would be no need to use a serial link protocol to extract data.   

Dgd

[boB]

@boB

Thanks for your reply.

I can actually appreciate where you are coming from and your investment in time and expertise getting modbus to where it now does what you want.
My point is that modbus is not useful for classic users. It's just too primitive and needs a lot of effort from users to understand and write program's to make use of it.  I think it's unlikely more than a few classic owners/users want to or are capable of this primitive interface programming.

The world standard user interface tool is a web browser, every man, woman, child and their dog has access to one. Just about every 'intelligent' device offers a web interface.
So I think this is the user interface the Classic should be providing.

If the hardware has the resources then I would suggest :
Local App development ceases, make the current release the final production version.
Obtain web serving software for the classic and get it installed
Commence developing in HTML code the web pages the classic will offer, eg status, reporting, setup etc..

All IMHO of course..

Dgd

We are already working on a web interface.  But the web interface will not and can not replace the modbus control protocol.
It will supplement modbus though.

I must disagree that customers cannot program modbus interfaces.  They are doing it all the time and it's working great
for them.  If they can program at all, then modbus is a "mature" protocol.  If they can't interface using modbus, then
they should go back to computer school or hire a programmer.... IF they can find one !  It's very hard these days to
find good programmers for embedded systems.

boB

[Halfcrazy]

I do want to point out that I believe Air is on its way out of our supported things to use 

Andrew and crew are working round the clock to make a web interface that resides on the product and I suspect this will be a reality in the Classic in the not so distant future. As far as Code or HTML that is above my head but I will pass this thread on to Andrew and let him respond.

We are very happy to listen to all ideas, Actually that's sorta why we are using ModBus it was asked that it become the standard in the renewable industry and many manufacturers are supporting that. SunSpec alliance is working to bring us all to the same ModBus registers etc.

Anyhow keep the ideas coming and we will take them all into consideration as our goal is to make robust and affordable products that please as many people as possible.

Ryan

[laszlo]

I was going to say that also the web interface was supposed to be there back in 2012 but is not. Same thing with sound. I am kind of cranky tonight, but need to mention there were a lot of cool features and  possibilities that Midnight created for us and  now are teasing us hoping to have with no end in sight.

[Halfcrazy]

Laszlo
I think you are referring to My Midnite the web based monitoring? As far as I know we never had any plans to instal a web interface into the Classic until about 3 months ago?

My MidNite is starting to take shape and should be ready for Beta testers any time now.


Ryan

[dgd]

We are already working on a web interface.  But the web interface will not and can not replace the modbus control protocol.
It will supplement modbus though.

I must disagree that customers cannot program modbus interfaces.  They are doing it all the time and it's working great
for them.  If they can program at all, then modbus is a "mature" protocol.  If they can't interface using modbus, then
they should go back to computer school or hire a programmer.... IF they can find one !  It's very hard these days to
find good programmers for embedded systems.

boB

Ok its good news that a built in web server is on the way for the Classic.  I just hope that sufficient priority is given to it's developnebt as we don't want another software system in the 'almost ready'  category for the forseeable future (ie years!)
With such an interface its only a simple step away to include FTP file uploading (and downloading). I'm thinking here of firmware updates, No more
seriial port uploads for firmware updates. A web page with FTP upload over ethernet - directly from the MN website 
And of course a Telenet login connection with the command line interface already discussed several months ago - for those that desire to write their own display programs.
Then no place left for or need for a local app, my midnite or  data extraction using modbus protocols
Don't really need the MNGP anymore, everything it does the web interface does, the LITE is all we need...

dgd

[dgd]

From what I have seen with LiFePO4 BMS', there is no absorb cycle.   They just want you to turn off when the voltage reaches
a certain set point.  MidNite will not be making a BMS, at least not at the moment.  Could do it I suppose but just look
at  the trouble Boeing is in even with a BMS.

boB

boB,

You mentioned elsewhere the AUX input that will turn off output from the Classic. This being how a BMS controls battery charging.
My LiFePO4 cells need an absorb time that depends on battery Ah discharge time as provided by a BM.
This would need an input, preferably an AUX funtion, that stops ABSORB and commences FLOAT.
Does such a function already exist? (not documented) or if not are you planning to include one? - any time soon, like yesterday   

dgd

[Halfcrazy]

The newest firmware has 2 new Aux functions. One is an Logic high state that tells the classic to go to resting the other is a Logic low state that tells the classic to go to resting. The voltage window is up to 12 volts I believe but boB will chime in here to correct me if I am wrong


Ryan

[boB]

From what I have seen with LiFePO4 BMS', there is no absorb cycle.   They just want you to turn off when the voltage reaches
a certain set point.  MidNite will not be making a BMS, at least not at the moment.  Could do it I suppose but just look
at  the trouble Boeing is in even with a BMS.

boB

boB,

You mentioned elsewhere the AUX input that will turn off output from the Classic. This being how a BMS controls battery charging.
My LiFePO4 cells need an absorb time that depends on battery Ah discharge time as provided by a BM.
This would need an input, preferably an AUX funtion, that stops ABSORB and commences FLOAT.
Does such a function already exist? (not documented) or if not are you planning to include one? - any time soon, like yesterday   

dgd

Yes, am planning another Aux 2 input logic function to force the Classic to Float.

The logic level high voltage is about 6 volts.

boB

[cpm]

From what I have seen with LiFePO4 BMS', there is no absorb cycle.   They just want you to turn off when the voltage reaches
a certain set point.  MidNite will not be making a BMS, at least not at the moment.  Could do it I suppose but just look
at  the trouble Boeing is in even with a BMS.

boB

boB,

You mentioned elsewhere the AUX input that will turn off output from the Classic. This being how a BMS controls battery charging.
My LiFePO4 cells need an absorb time that depends on battery Ah discharge time as provided by a BM.
This would need an input, preferably an AUX funtion, that stops ABSORB and commences FLOAT.
Does such a function already exist? (not documented) or if not are you planning to include one? - any time soon, like yesterday   

dgd

dgd;

I would really like to learn more about your set-up.
I am *very* interested in using LiFePO4 batteries, as I've yet to
actually buy my battery bank. I looked through some of your
posts, but I can't find an inclusive description of your setup.

If you could point me to one, I'd really appreciate it.

--

[dgd]

dgd;

I would really like to learn more about your set-up.
I am *very* interested in using LiFePO4 batteries, as I've yet to
actually buy my battery bank. I looked through some of your
posts, but I can't find an inclusive description of your setup.

If you could point me to one, I'd really appreciate it.

--

hi cpm,

Im in the process of changing my 1100Ah 24v batteries - 6 by 4  volt Century Yaesu flooded lead acid to 4 by 12volt 500Ah LiFeYPO4 batteries as a 24v 1000Ah bank which I can later reconfigure to 48v at 500Ah.
The LiFeYPO4s are arriving March 10 so in meantime I'm trying to get everything I need to install them.
I posted the batt details a few messages back.

The reason I chose these types was they do not need a BMS. Apparently because cell balancing is not needed when the cell AH rating is large and multiple cell strings are not used. Another 480Ah 12v battery I looked at had multiple 80Ah cells and charge balancing was essential. The required BMS inflated the price 

These Lithium cells use an ABSORB then FLOAT charge regimen with ABSORB time calculated by a battery monitor depending on how many Ah has been removed from the battery by loads.  Voltage is no indicator of SOC as its constant to about 80% discharge.

boB has already made an AUX input available that will work with a BMS. I hope he gets time to add one that forces FLOAT.
Better still if MN had a battery monitor arriving soon. In meantime I'm looking at using a Pi to monitor.

Sorry I have not posted pics of my setup. I did get a shock when I saw those from plongson and Ryan, they both show how a 'power wall' should be.
Its encouraged me to tidy up my wall mess and recable into trunking.  Pics soon

dgd

[vtmaps]

I've been thinking about battery monitors...

When Midnite battery monitor estimates SOC, will it derate battery capacity based on battery temperature?  If so, how will it know the temperature... will the Classic tell it?

When the monitor counts amphours will it be able to compensate for Peukert effect?  (display raw amphours vs. compensated amphours, and calculate SOC by either method)

Will the monitor make its own determination of 100% SOC, or will it assume the Classic's transition to float indicates 100% SOC? 

Will the Classic be able to change modes or activate AUX relays based upon the SOC?

--vtMaps