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
Quote from: fca on July 15, 2013, 01:25:36 PM
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
Quote from: fca on July 15, 2013, 01:25:36 PM
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 :)
Quote from: TomW on July 15, 2013, 01:58:02 PM
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.
Quote from: RossW on July 15, 2013, 04:43:23 PM
Quote from: fca on July 15, 2013, 01:25:36 PM
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
Quote from: dgd on July 15, 2013, 08:33:33 PM
Quote from: RossW on July 15, 2013, 04:43:23 PM
Quote from: fca on July 15, 2013, 01:25:36 PM
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
Quote from: TomW on July 15, 2013, 08:52:27 PM
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)
Quote from: TomW on July 15, 2013, 08:52:27 PM
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
Quote from: dgd on July 15, 2013, 08:33:33 PM
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
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.
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).
Quote from: atop8918 on July 16, 2013, 04:01:52 AM
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
Quote from: dgd on July 16, 2013, 06:09:22 AM
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
Quote from: boB on July 15, 2013, 10:44:43 PM
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
no.
Quote from: dgd on July 20, 2013, 03:11:50 AM
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
I'm sure boB and his team of 500 engineers is hard at work as we speak working on the next generation, 500 amp, 1000 Voc input, 500mA idle current draw, web enabled charge controller (code names $BizBang Sr$). It's based on a $1000 FPGA chip allowing almost infinite configurations and customization for every customer as needed. The retail price will be an amazingly low $5000, which of course the large customer base awaiting this controller will gladly pay... ::)
Seriously though - the current Classic is more than adequate for 99% of users IMHO. Yes , the software and monitoring capabiities still need some fine tuning and some promised features are taking longer to add than many of us eager RE geeks would like but given the size of the market for those kind of things I'm not surprised it is not on the top of their to do list. This ain't exactly "consumer electronics"
??? Are we running out of time? ???
Cause 90% of things get done in 10% of the time allocated, ;)
the last 10% of things to be done take 90% of the time... :'(