undecided

  • Thread starter Philip Costigan
  • Start date
P

Thread Starter

Philip Costigan

Hi

I'm working on the modbus stuff and have come to a point where I would like a directional nudge.

I had the idea that I should make modbus.asc modbus.rtu and modbus.tcp all just one module but I'm finding it a little bit more difficult than it probably should be. I now think that having each as a seperate module is not such a bad idea. (for now anyway :)

Is this ok.

It probably means duplication of code, but time is the issue just at the moment.

--

Regards

Philip Costigan

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
M

Mario de Sousa

> Is this ok.

It is my opinion that it is not only ok, but the right way to go. Others may disagree.

> It probably means duplication of code, but time is the issue just at the moment.

Maybe you should right a common function library, used by all modules, instead of wrapping them up in the same module? We can leave this for later, anyway.

If you have the time, do you think you could come up with a demo for the modbus modules?
Maybe have two linuxplcs communicating over modbus.tcp, one running the chaser, and the other the vitrine?


Cheers,

Mario.

----------------------------------------------------------------------------
Mario J. R. de Sousa
[email protected]
----------------------------------------------------------------------------

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
It's up to you how to do it. Personally, I'd try to avoid the methodology you are looking at. There are two layers to the modbus protocol, the protocol and the transport. The messages that are sent across Serial or TCP/IP are identical. The only different is the routines used to send them and to read data. As a result, most implementations of this use a base class that implements all of the modbus protocol stuff, then derive a derived class to handle the Reading/Writing transport specific stuff. There is an excellent example on the web at:

http://members.tripod.com/~mbserver/
 
P

Philip Costigan

> If you have the time, do you think you could come up with a demo for
> the modbus modules?
> Maybe have two linuxplcs communicating over modbus.tcp, one running the
> chaser, and the other the vitrine?
>

I don't want to spoil the excitment but........
The module at this stage only acts as a master which means that it can only drive and monitor external I/O modules like momentum or Beckoff I/O.
There is no means yet to reply to a request for data.

I don't think I'll have time to implement it before January. I'll be traveling soon but it is a good idea for a demo.

Regards

Philip Costigan

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
W

Wayne Johnston

In a sense, you want to take both approaches.

I suggest that you break the implementation into two layers. One should handle the reception and transmission of messages. You will have to
implement a separate module for RTU, ASCII and TCP protocols.

The other layer should handle the message parsing, formatting of responses,
etc. Ideally, this would be a library used by each of the protocol modules. Since the core message data is the same for all protocol variants you can easily implement a standard interface.

In this way the common part of Modbus is implemented only once, but you overcome the difficulties of implementing the three different protocols in a single module.

Regards,
Wayne Johnston


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
C

Curt Wuollet

Hi Phil

Whatever makes sense for you. You've done the heavy lifting and research, if you don't have time and someone wants to use it really badly, I'm sure the structure can be cleaned up. Have you tested it with Beckhoff/Wago IO? I have some of this around and could probably get a modbus interface module. Seperate modules might be easier to understand and/or configure for now
anyway.

Keep up the good work!

Regards

cww

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
P

Philip Costigan

On Fri, 10 Nov 2000, Curt Wuollet wrote:
> Have you tested it with Beckhoff/Wago IO? I
> have some of this around and could probably get a modbus interface module.
> Seperate modules might be easier to understand and/or configure for now
> anyway.

I haven't had the opertunity to test it on physical I/O yet. I'm just using a simulator on another box ( M$ with modsim software ). So If anyone out there can try testing on real I/O cards then by all means please help.

As for coding.
I intend on creating three directories under io/modbus called modbus.asc modbus.rtu and modbus.tcp. The code in each directory will look almost exactly the same. When I get time to weigh up the differences I'll then create a
library of the common functions. Or change the whole thing to be structured in a better way.

I hope this is ok for the interim.

--

Regards

Philip Costigan


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
M

Mario de Sousa

> As for coding.
> I intend on creating three directories under io/modbus called modbus.asc
> modbus.rtu and modbus.tcp. The code in each directory will look almost exactly
> the same. When I get time to weigh up the differences I'll then create a
> library of the common functions. Or change the whole thing to be structured in
> a better way.

Hi Philip,

May I suggest using a single directory /io/modbus and subdirectories for
the code. Something similar to
/io/modbus/lib -> place for the (future) common protocol and config
parsing libraries
/io/modbus/asc -> driver for ascii version
/io/modbus/rtu -> ...
/io/modbus/tcp -> ...

Please feel free to disagree.

Cheers,

Mario.


----------------------------------------------------------------------------
Mario J. R. de Sousa
[email protected]
----------------------------------------------------------------------------

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Top