Encryption OFF

[boB]

Pinouts are at the very end of the Classic modbus document.  (needs an update for the WB Jr. stuff)

These connectors can access the same stuff as the modbus over TCP/IP.

The main difference is that the RS-232 connections need a modbus ID address for
the Classic, which is contained in the very first modbus byte.  Default is 10 (decimal).

For modbus over TCP/IP, each Classic must have its own IP address and/or port.

boB

[zoneblue]

Ok, ta. And you guys are ok with the RJ11s being used for monitoring?

But anyway if followme requires two, and the MNGP/LP requires one. Im just seeing that we are all round best off using the ethernet port.  Im ok about that, its working totally stable, so long as you maintain an open connection, and keep it open, just like the local app does.

[zoneblue]

BTW ive roughed up a wiki page about the com ports here:

http://code.google.com/p/theblackboxproject/wiki/ClassicComPorts

Any changes let me know.

[dgd]

But anyway if followme requires two, and the MNGP/LP requires one. Im just seeing that we are all round best off using the ethernet port.  Im ok about that, its working totally stable, so long as you maintain an open connection, and keep it open, just like the local app does.

Or have the follow me loop back done in one rs232 port.
Probably 90% of classics are alone, no follow me necessary
Maybe 9% is two classics so just one bidirectional rs232 port needed on each for follow me
Three classics or moe connected to same battery bank would need to use two rs232 ports on classics in middle, or use a rj11double socket adaptor for middle classics.

That should make a free rj11 rs232 port on each classic for com box connection 

...just another idea 

Dgd

[Halfcrazy]

I am not very smart with RS232 but I "Think" if the classics are wired together you can talk to all of them through 1 RS232 cable.

[boB]

Hopefully, eventually we can get Follow Me to work using only bi-directional RS232 cable
for multiple (more than two) Classics.

Our modbus is MODified...  What I mean is that normal modbus does not echo or forward
packets through to other devices.  We do this now but it can get bogged down if not
careful.  Follow me  using the loop-around works pretty well and a missed packet here
or there doesn't matter.  Flawless communications is my goal of course but that
just doesn't happen.  I'll settle for  close to flawless.

[laszlo]

I do like the idea of focusing on new product lines. There is no satisfactory resolution to current discussion thread because  original design was for proprietary but free bundled tools to monitor the Classic. 

But for the next seminal MN product, it would be a great idea to include right in the design phase  some API's that can be used by all developers to write software to communicate with the device. These API's ideally  should be RESTful API's that do not requires stateful processing and allow multi-access.  For critical comms,  standard queueing solutions such as rabbitmq could be used instead of prorietary SCADA protocols.

And a lot of the MN  engineers seem to have a lot of depth in software development already,  so perhaps their personal development plans could include going to  some conferences or reading some O"Reilly books on  learning how to to write good APIs and distributed computing.

Oh please don't get us wrong we are not asking anyone to bug off. We are simply trying to maintain a profitable business and develop new products the market needs. The real issue is the Classic is basically limited to what it can do on several fronts. We can design and build the ultimate charge controller but it will cost more. Maybe that's OK? Maybe we will sell thousands of them if we did? We just don't know.

What we are trying to do is work towards a line of Inverters and stuff and also Mario will be working on the Classic 2.0 So we are listening to all the suggestions and keeping an open mind. I still see some form of com box that is the do all be all device and it handles the Modbus server stuff so you can have 4 or 5 devices asking it stuff.

Ryan