RE: [jModbus-devel] Proceeding

[Proctor, K. <Kel...@al...>]

> -----Original Message-----
> From:	Wimberger Dieter [SMTP:die...@td...]
> Sent:	Sunday, November 04, 2001 3:03
> To:	jmo...@li...
> Subject:	[jModbus-devel] Proceeding
> 
> Hi Kelvin,
> 
> Sorry for submerging the last days, but things have been going up and
> down a little bit.
> Allthough it was pretty busy I have manged to come up with a Modbus
> ASCII Implementation that fits with
> my oo design.
> However, I think you were right that it is much better to receive a
> complete frame, so I am
> now doing that and wrapping the frame into a ByteArrayInputStream for
> reading with the Message classes.
> 
	[Proctor, Kelvin]  
	This is becoming vitally important for the RTU transport, there is
no way it could work without looking for whole frames.  I was working on
that over the weekend and I'm having real trouble coming up with system for
doing this under the javax.comm API.  Most implementations that are floating
around on the net (under any language) are Master devices and simply write a
frame, pause and then read until there is no more to read.  This works fine
for the master only cause but I would like something that conforms to the
spec a little better and is more suitable for use in either a master or a
slave.  The implementations that really do stick to the spec (such as PLC's)
have access to the UART in more primitive and powerful way usually.  I'll
find some way to solve this but it might take some more work yet.
	 
> I have also done a LRC, it would be good to have some results to test
> against..it is much simpler then the version you created, and it gives
> the same results but anyway, maybe there is some official way to test
> this.
> 
	[Proctor, Kelvin]  
	I'll be fascinated to see this, the version I came up with was
pretty small already.  With a function like this (and more importantly for
the CRC for RTU) getting a fast implementation is the most important issue,
even at he expense of 10 vs 5 lines of code.  I have not had a serious think
out run time of my algorithm yet, I just hacked up something that worked.
	 
> Another point I did not have the time to figure out are  the
> specifications for the serial communication. As each cycle is a
> Transaction (Request by Master, Response by addressed Client) there must
> be some mechanism that repeats frames if there is no answer from any
> client (timeout??) or to notify the master that a frame is corrupt etc. 
> Any clue about this so far?
> 
	[Proctor, Kelvin]  
	You are correct here.  The spec is a little vague about how all of
this should be handled.  My original code does not handle any of this at all
really, only working out if a packet was sent correctly or not and returning
true or false.  The method you have used in creating a Connection class is a
good solution to this.  You can set it up to know how many times to retry,
set the timeouts etc.. and it can reference the transport.  It adds another
layer but I think it is justified.

> If you are still interested, I can make the package accessible to you
> again (when I am done with clean ups).
> I was also thinking about how we are going to proceed, because I am not
> exactly sure if you feel confident with 
> my whole design.
> I also think that for the TINI it is probably too heavy weight, it runs,
> but I would not dare to let it do so without some optimizations.
> Specifically I am thinking of an ObjectPool (which is not always the
> best thing to do, but in this case it could be).
> 
	[Proctor, Kelvin]  
	This was always likely to be that hardest part of the design.  My
design was written with the TINI in mind and written to be able to act as a
master or a slave.  You code was written with the master only in mind and
designed to be run from a PC or similar.  These two setups have very
different requirements.

	Until we work out where we want to go with this I'll keep plugging
away with my transport code under my old architecture (as it's more basic
and hence a little simpler to integrate into).  I'll have another go at the
serial stuff tonight and see where it gets me. 

	I'm interested in what you would intend to use the ObjectPool for?
I have usually seen this term used in the context of web servers where a set
of threads is created and then reset after a connection assigned to them
dies, as opposed to creating a new thread each time.  If this is the case
I'm note sure it would really help this all that much.  In my experience of
control type application this is not as much of a problem.  In the case of a
web server you will have a  lot of very short sessions open and closed all
the time, each dealing with only a single request.  In the case of ModbusTCP
this is unlikely as most application will open a single connect and keep it
open send possibly millions of requests across a single connection.

	If I have your definition of an ObjectPool wrong let me know.

	Cheers,

	Kelvin

> Let me know what you think,
> Dieter
> 
> 
> 
> _______________________________________________
> jModbus-devel mailing list
> jMo...@li...
> https://lists.sourceforge.net/lists/listinfo/jmodbus-devel

Alcoa World Alumina Australia is a trading name of Alcoa of Australia Limited,  ACN 004 879 298