Midnite solar status panel Application Version 0.3.24 lock modbus

[fca]

Hi there my firsts midinite 150 started today the operations connected to a 3kw array ...
So far liking the unit with (only  some questions that i will post when i have more time with it)..
But this is post is related to the modbus ip interface, when using this app all other modbus clients fail, like these app locked the modbus acess...

so my question is the classic my any mean limiting the #of modbus clients ?  i want to integrade the midnite in my Scada application...
If these midinite app is running the scada modbus cliente fails to read, if i close this app the scada modbus read the fields with no problem

apps are running on different computers....

REgards

PS: classic sw version 1341_03/01/2013

[TomW]

Hi there my firsts midinite 150 started today the operations connected to a 3kw array ...
So far liking the unit with (only  some questions that i will post when i have more time with it)..
But this is post is related to the modbus ip interface, when using this app all other modbus clients fail, like these app locked the modbus acess...

so my question is the classic my any mean limiting the #of modbus clients ?  i want to integrade the midnite in my Scada application...
If these midinite app is running the scada modbus cliente fails to read, if i close this app the scada modbus read the fields with no problem

apps are running on different computers....

REgards

PS: classic sw version 1341_03/01/2013

Sadly, you can only connect to the modbus over ethernet with one application at a time. You can connect from several applications just not simultaneously. RossW  is/may be working on a work around for this using his application for Linux. But for now it is one at a time.

You can access modbus registers through the serial port, also. More of a register dump than anything but can be done.


Tom

[RossW]

so my question is the classic my any mean limiting the #of modbus clients ?  i want to integrade the midnite in my Scada application...
If these midinite app is running the scada modbus cliente fails to read, if i close this app the scada modbus read the fields with no problem

My understanding is that the classic ethernet interface is permitting only one connection at a time. The modbus protocol itself does not impose this limitation but I can see plenty of valid reasons for midnight to do so, even if it IS inconvenient to us

[RossW]

RossW  is/may be working on a work around for this using his application for Linux. But for now it is one at a time.

My utility will open the connection, request the data then close the connection and exit. If run in "continuous" mode you can choose to have it maintain the connection (which is more efficient) *OR* close and re-open the connection each time it wants to access the classic (which may allow it to co-exist with other modbus clients better).

When I get time, I am aiming to add an additional function to my code, to enable it to look like a modbus device itself and permit other programs to connect to your *computer* rather than the *classic*. No ETA on that code yet though as I've got too many other active projects on the go.

[dgd]

so my question is the classic my any mean limiting the #of modbus clients ?  i want to integrade the midnite in my Scada application...
If these midinite app is running the scada modbus cliente fails to read, if i close this app the scada modbus read the fields with no problem

My understanding is that the classic ethernet interface is permitting only one connection at a time. The modbus protocol itself does not impose this limitation but I can see plenty of valid reasons for midnight to do so, even if it IS inconvenient to us

You are kidding aren't you 
What earthly possible reason would there be for Midnite (Midnight?) to restrict the Classic to one ethernet connection? If this is a deliberate action then all it will do is promote sales of the Chinese Classic copy that has proper tcp/ip stack management allowing several simultaneous ethernet sessions.
I suspect the reason is a 'too tight' design and the cpu is net crippled possibly by a lack of additional working memory (ram) to allow a proper net stack implementation. For the sake of a couple of $ worth of ram IC on the Classic's cpu board.. then of course we could have had a proper OS such as embedded linux...

dgd

[TomW]

You are kidding aren't you 
What earthly possible reason would there be for Midnite (Midnight?) to restrict the Classic to one ethernet connection? If this is a deliberate action then all it will do is promote sales of the Chinese Classic copy that has proper tcp/ip stack management allowing several simultaneous ethernet sessions
dgd

dgd;

Well, duh. The App WRITES to the Classic, too and that might be a bad thing to have 2 different applications writing to the same registers simultaneously. You think? Maybe?

I know you seem to enjoy hammering on the Midnite guys on things so I will just point out the obvious and leave it there.

Tom

[RossW]

dgd;

Well, duh. The App WRITES to the Classic, too and that might be a bad thing to have 2 different applications writing to the same registers simultaneously. You think? Maybe?

Just for the record, Tom - the modbus protocol actually seems reasonably tolerant of multiple devices reading and writing concurrently. There would of course be the potential  danger of two things trying to write to the same register and one clobbering the other, but that's not the protocols fault

To dgd's query - the complexity of handling multiple concurrent connections, including such things as the password to enable writes (the permission is automatically rescinded upon connection close - but that makes far more work and overhead keeping track of it all in the code) - as well as presumably somewhat limited RAM, processor and other resources. I can see why someone could intentionally include such a "limitation" - it's not like it's cast in stone, it could conceivably be addressed later when the product is more mature, but while simply trying to get the product to market, with as many features as practical... for the perhaps 0.05% of people who will be affected by it, it would have required considerable additional time/effort/cost to implement.

We should be asking Bob if it's something they're planning to address "in time", or if multiple, concurrent connections is considered unnecessary. (If it is, it could always be provided by an external box that talks to the classic and provides buffered reads and writes to "emulate" that function adequately)

[dgd]

Well, duh. The App WRITES to the Classic, too and that might be a bad thing to have 2 different applications writing to the same registers simultaneously. You think? Maybe?

I know you seem to enjoy hammering on the Midnite guys on things so I will just point out the obvious and leave it there.

Tom

Ha!  Having spent the best years of my life in the software development industry I do tend to be somewhat cynical when presented with software that just misses the mark or is an engineer's vision of what the users should have.
Multiple processes that can write to the same registers/data structures/files etc usually implement a simple write lock system (perhaps via a lock file for example) to prevent ooopsies occuring.
To use a sledgehammer solution to prevent multiple writes such as crippling multiple ethernet connections would be just laughable.

No, as I said I suspect its a lack of hardware resource issue..

As for hammering on the Midnite guys - I believe if you have the best product that laurel resting is ok to a limited extent BUT active encouragement to review/improve is a positive driver and my hammering is thus intended to encourage improvement.
After all if we all sit back and trumpet on about how great  the Classic is (which it is!) then where do we go from there...

dgd

[boB]

What earthly possible reason would there be for Midnite (Midnight?) to restrict the Classic to one ethernet connection? If this is a deliberate action then all it will do is promote sales of the Chinese Classic copy that has proper tcp/ip stack management allowing several simultaneous ethernet sessions.

dgd

One big reason we limit to one connection at a time is that the Classic's processor is doing MANY different
tasks, the biggest being to charge the batteries properly and not let the smoke out and that it has
a finite clock speed.

I suppose it could just go slower when more than one connection is made but then people might
complain about how slow it goes.  It actually handles two connections at once now.  My Midnite
and the modbus over TCP/IP connection used with the Local App and third party applications.

You could of course add a separate box to convert one or two of the RS-232 lines to Ethernet
and TCP/IP but would also be somewhat slow with all the other comms happening.

boB

[atop8918]

Yup, the Classic is limited to one local connection at a time.

There are plenty of reasons for this, but it just needs to suffice that it was an engineering decision based on performance, time and cost of implementation, and user experience. As 99.9% of users will either use the Local App or not use the Ethernet at all there was no impetus to spend 6 months implementing a full featured stack.

[atop8918]

Incidentally, the technical specs on the networking connections are one ARP channel, the shared DHCP/DNS connection, UDP advertise connection, one Local Listening TCP/IP connection, one active remote MyMidNite connection (if enabled).

[dgd]

Yup, the Classic is limited to one local connection at a time.

There are plenty of reasons for this, but it just needs to suffice that it was an engineering decision based on performance, time and cost of implementation, and user experience. As 99.9% of users will either use the Local App or not use the Ethernet at all there was no impetus to spend 6 months implementing a full featured stack.

ok, not worth arguing about - but I did think those 99.9% users having seen the ethernet interface would have expected to use their web browser to connect to the Classic and perhaps see some simple web pages (like the web pages on most routers like the NetLink wrt54g) for data and settings.
Anyway MN has went down a different networking path.

dgd

[boB]

ok, not worth arguing about - but I did think those 99.9% users having seen the ethernet interface would have expected to use their web browser to connect to the Classic and perhaps see some simple web pages (like the web pages on most routers like the NetLink wrt54g) for data and settings.
Anyway MN has went down a different networking path.

dgd

It seems that other solar PV controllers or Mates and/or WRT routers have a separate Linux processor in them and
can more easily implement the full meal deal as far as the internally served web pages.  That would be nice
and ~could~ be done but with the specialized processor we use, it would be quite a bit more work, unfortunately.

boB

[dgd]

One big reason we limit to one connection at a time is that the Classic's processor is doing MANY different
tasks, the biggest being to charge the batteries properly and not let the smoke out and that it has
a finite clock speed.

I suppose it could just go slower when more than one connection is made but then people might
complain about how slow it goes.  It actually handles two connections at once now.  My Midnite
and the modbus over TCP/IP connection used with the Local App and third party applications.

You could of course add a separate box to convert one or two of the RS-232 lines to Ethernet
and TCP/IP but would also be somewhat slow with all the other comms happening.

boB

I know the MN engineers have been busy with kid and brat development but are we likely to see some further hardware development of the Classic? It must be well into its product lifecycle since its release in 2010(?).  Most consumer electronics get crunched every year or two and even RE devices are 3 to 5 years between major redesigns.
So is autoCAD getting the nextgen Classic pcbs drawn up with the second cpu/4gbram/64gb memory card etc for the embedded Linux
system/web server/web pages and perhaps builtin battery monitor via external shunt and some decent AtoD to get those voltages and currents properly measured?

dgd

[atop8918]

no.