Hi,

I'll probably never finish modifying and tweeking modbus_tcp. I have reached a point now where I believe It is possible to start stripping the code into two libraries. One which could be designed as a standard linuxplc I/O interface library and then the other which is the real I/O driver interface which will always be vendor specific.

I think that the code that I have developed is starting to head in the right direction but it is very much modbus_tcp specific which I don't particularly like. I would prefer to have some generic I/O module that then tells external vendor specific real I/O what to do. This would use some standard messaging system between the two processes that hopefully is easy to setup and
understand. (The smm is sort of this I suppose).

Its just that with each I/O module that gets developed, there must be a reasonable amount of code that would be duplicated by each developer. If we can identify what every I/O module developer is going do at the smm end of their
code then we can supply a set of functions for all to use.

we already have plc_update() which is standard for all modules.

we do not have a standard for io_update() or io_in() , io_out() and this is understandable because somewhere inside these functions is where the vendor specific code will probably sit..

<IDEA>
Is it feasible to pass pointers to functions that the vendor must use into io_in() Like.

int io_in( int (*standard_io_in_func)() );

io_in( vendor_read_function );

where vendor_read_function must be structured in a format that is the standard linuxplc I/O format for io_in(). The function that they produce must accept the arguments that we specify but they can do what they want from there.

Does this make sense? :-J
</IDEA>

I'll be OS for a little while but I want to take some ideas with me to think over for when I'm being idle.

Phil.


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

 

Philip Costigan wrote:

> (...)

> I think that the code that I have developed is starting to head in the right
> direction but it is very much modbus_tcp specific which I don't particularly
> like. I would prefer to have some generic I/O module that then tells
> external vendor specific real I/O what to do. This would use some standard
> messaging system between the two processes that hopefully is easy to setup and
> understand. (The smm is sort of this I suppose).
>

Sorry Phil, but are you suggesting that the module be run as two Linux processes? One for generic I/O code, and another for vendor specific code?

If that is the case I don't really like this. Why not write the generic I/O code as a common library? Why does it have to run as a separate process?


> Its just that with each I/O module that gets developed, there must be a
> reasonable amount of code that would be duplicated by each developer. If we can
> identify what every I/O module developer is going do at the smm end of their
> code then we can supply a set of functions for all to use.

Phil, you have some experience writing an I/O module, so maybe you are better placed to identify what part of the code could be generic.

I myself can't think of much. It seems to me that the only generic part is the main loop (with extra error logging code, and so on).

All the rest seems very vendor specific.

The parsing of the config file is vendor specific because the parameters required to setup the hardware is vendor specific. I can't see what could be made generic here. Maybe write a few higher level functions to read the config file?

Accessing the I/O is obviously vendor specific.

What else is left besides the main loop?

> we already have plc_update() which is standard for all modules.
>
> we do not have a standard for io_update() or io_in() , io_out()
> and this is understandable because somewhere inside these functions is where
> the vendor specific code will probably sit..
>
> <IDEA>
> Is it fesable to pass pointers to functions that the vendor must use into
> io_in() Like.
>
> int io_in( int (*standard_io_in_func)() );
>
> io_in( vendor_read_function );
>
> where vendor_read_function must be structured in a format that is the standard
> linuxplc I/O format for io_in(). The function that they produce must accept the
> arguments that we specify but they can do what they want from there.
>
> Does this make sense? :-J
> </IDEA>
>

The above is feasible, but it seems to me it only saves you from writing the main loop. That's a small percentage of code, and it could be done by copy and paste from a previously developed module. Any reason why this shouldn't be so? Am I
looking at this from the wrong angle?


Mario.

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


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

 

> Sorry Phil, but are you sugesting that the module be run as two Linux processes?
> One for generic I/O code, and another for vendor specific code?
>
> If that is the case I don't really like this. Why not write the generic I/O code
> as a common library? Why does it have to run as a separate process?

No! The common library is probably a better way. The idea further down is library oriented but up here I have sort of left it open to interpretation.


> Phil, you have some experience writing an I/O module, so maybe you are better
> placed to identify what part of the code could be generic.
>
> I myself can't think of much. It seems to me that the only generic part is the
> main loop (with extra error logging code, and so on).
>
> All the rest seems very vendor specific.
>
> The parsing of the config file is vendor specific because the parameters required
> to setup the hardware is vendor specific. I can't see what could be made generic
> here. Maybe write a few higher level functions to read the config file?
>
> Acessing the I/O is obviously vendor specific.
>
> What else is left besides the main loop?
>
> > we already have plc_update() which is standard for all modules.
> >
> > we do not have a standard for io_update() or io_in() , io_out()
> > and this is understandable because somewhere inside these functions is where
> > the vendor specific code will probably sit..
> >
> > <IDEA>
> > Is it fesable to pass pointers to functions that the vendor must use into
> > io_in() Like.
> >
> > int io_in( int (*standard_io_in_func)() );
> >
> > io_in( vendor_read_function );
> >
> > where vendor_read_function must be structured in a format that is the standard
> > linuxplc I/O format for io_in(). The function that they produce must accept the
> > arguments that we specify but they can do what they want from there.
> >
> > Does this make sense? :-J
> > </IDEA>
>
> The above is feasable, but it seems to me it only saves you from writing the main
> loop. That's a small percentage of code, and it could be done by copy and paste
> from a previously developed module. Any reason why this shouldn't be so? Am I
> looking at this from the wrong angle?

There probably is no angle yet. It is just some feeling I have that if there is no structured external library for developers to use we will end up with a hotch potch of I/O servers each with there own interpretation of how to communicate to the linuxplc. I'm looking into the future a bit I supose and trying to see how the end user might configure their I/O. If they have 3
different types of I/O connected to the system it should be easier to have a similar configs for each I/O type. Similar because the I/O vendor developers have all used the same library to setup their I/O driver etc.

I also like to see some effort in making things structured across the board so to speak. If it can improve the system as a whole then its worth the effort. If not then we can drop it but I think these things should be discussed.


I'm going to bed ( It's 2:30 am argh )

Phil.

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

 

Hi Phil

These are the same questions I have been pondering lately, How we package the stuff thats common to several types and the stuff that's
unique. We need to think ahead some. By the way, it's good to see you contributing the modbus code as it will probably see a lot of service.
One thing I missed is what specific target you are working with. I have been too busy with stuff for my day job to pay proper attention but, I hope that will improve eventually. I'm not sure why the guys want to interface IO directly with the SMM rather than an IO services layer, but it will become clear if we have a lot of commonality in the drivers just what needs to be done.

Regards

cww


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

 

On Fri, 29 Sep 2000, Curt Wuollet wrote:
> Hi Phil
>
> These are the same questions I have been pondering lately, How we
> package the stuff thats common to several types and the stuff that's
> unique. We need to think ahead some.

I'll be doing some thinking over the next week or so before I start to attack the problem. I think the seed has been planted with the pointer to function method that I am employing in the modbus_tcp code. When I get back I'll move the relevant code into the io directory on the CVS and start to include the serial modbus (RTU and ASCII) functionality into the project. This may start to show areas that can be seen to be similar or different. We then can massage things to come up with a method that all can conform to. admittedly the protocol I'll use is the same but the methods are different. The next step would be to recode the existing dio48 code to use the same
library and structure. We just have to be ready for some obscure io device to arrive on the scene.

> One thing I missed is what specific target you are working with.

A this point in time I am using a modbus simulator that runs on Windoz98 but I hope to acquire momentum io from schneider soon to see how it goes.

I am also looking at weigh scales. Some of them have ASCII modbus serial ports.

> I'm not sure why the guys want to interface IO directly with the SMM rather
> than an IO services layer, but it will become clear if we have a lot of
> commonality in the drivers just what needs to be done.

This is why I asked the original questions.


Regards

Phil

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

 

Philip Costigan:
> If they have 3 different types of I/O connected to the system it should
> be easier to have a similar configs for each I/O type. Similar because
> the I/O vendor developers have all used the same library to setup their
> I/O driver etc.

To some extent this is a matter for policy rather than actual code.

We now have an actual inconsistency in linuxplc.conf style between your modbus.tcp module and Curt's dio48, so it's no longer academical. Yours maps points to hardware using the syntax
<keyword> <point> <details including direction>...
while the dio48 uses
<direction> <point> <details>...
(I think I wrote it that way).

Which is better?

> I also like to see some effort in making things structured across the
> board so to speak.

Yes, of course. I think there was one function already that was going into the IO library (point status points).

If you can think of other functions that would be useful to others - either other IO modules, or others in general - post on the list and they'll be added to lib/io or lib/smm or whereever they belong.

(Or just add them to lib/io yourself.)


Jiri
--
Jiri Baum <[email protected]>
What we do Every Night! Take Over the World!

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

 

On Fri, 29 Sep 2000, Jiri Baum wrote:
>
> > If they have 3 different types of I/O connected to the system it should
> > be easier to have a similar configs for each I/O type. Similar because
> > the I/O vendor developers have all used the same library to setup their
> > I/O driver etc.
>
> To some extent this is a matter for policy rather than actual code.

True.

> We now have an actual inconsistency in linuxplc.conf style between your
> modbus.tcp module and Curt's dio48, so it's no longer academical. Yours
> maps points to hardware using the syntax
> <keyword> <point> <details including direction>...
> while the dio48 uses
> <direction> <point> <details>...
> (I think I wrote it that way).
>
> Which is better?

Niether I think now. Mayby we should look at <details and direction> as a seperate entity like........

<SNIP>

[node_list]
# format
# "node", node name, io module to use, module args, ... #variable arg list?
node control_pnl_dsply modbus_tcp 192.168.47.123 1 dout
node control_pnl_buttons modbus_tcp 192.168.47.124 1 din
node weigh_scale modbus_asc /dev/ttyS1 1 ain
node local_in dio48 in
node local_out dio48 out

[modbus_tcp]
#format
# "io", point, node name, absolute address at node, fail state
io mcn1filsol control_pnl_dsply 101 off
io mcn1fulllmp control_pnl_dsply 102 last

io mcn1startpb control_pnl_buttons 101 off
io mcn1stoppb control_pnl_buttons 102 off

[dio48]
#format
# "io", point, node name, absolute address at node, fail state
io i1 local_in 0 off #addressing may need to change from 1A 0 etc to a flat
io i2 local_in 1 on #map starting at 0 and extending to 24. ???

io q1 local_out 0 last
io q2 local_out 1 off

[modbus_asc]
#same format as above
io hopper_weight weigh_scale 112 3000 #fails to a full hopper

</SNIP>

Maybe the node entries could go in the module areas or somthing but you should get the jist of what I'm trying to achieve.

That covers the config being close to uniform.

The big challenge is in making a library that allows all this to happen without people re inventing the same code.

>
> > I also like to see some effort in making things structured across the
> > board so to speak.
>
> Yes, of course. I think there was one function already that was going into
> the IO library (point status points).
>

One step at a time is good.

> If you can think of other functions that would be useful to others - either
> other IO modules, or others in general - post on the list and they'll be
> added to lib/io or lib/smm or where ever they belong.
>
> (Or just add them to lib/io yourself.)
>

I'll see what I can do. (and at the same time not stepping on others toes? B-)

I'll catch all the Goss when I get back.

Phil

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

 

Curt Wuollet:
> I'm not sure why the guys want to interface IO directly with the SMM
> rather than an IO services layer,

Mostly, I'm not sure what you expect to have in that layer. In the absence of any known content, the layer sort of vanishes...

> but it will become clear if we have a lot of commonality in the drivers
> just what needs to be done.

Exactly.

There's now an "io module library" in lib/io; is that's what you had in mind?


Jiri
--
Jiri Baum <[email protected]>
What we do Every Night! Take Over the World!

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

 

Hi Jiri:

It's kinda hard to explain. Don't think you have to stop everything and do this :^) even if you agree. I'll use your opening to talk about that and some of the very basic things that drove me to starting lplc and what impedes the use of Linux in automation, the hardest part is drivers. It is a very ambitious persuit to support a broad range of diverse stuff and we need everything we can throw at the problem and every advantage we can gain. I have a little time today.

Where it's wandering around to in those corners of my mind not crammed full of robot cruft is a layer that would contain protocols and code for "hardwareless" IO, userland stuff that would be more or less independent of transport. Don't take this too literally at this point, I haven't been able to focus much, I've been in panic mode on other stuff. For example, in the case of Modbus, the actual engine that parses the packets would sit here and do the interaction with the SMM. The code below this would consist of the transport specific parts, for modbus, a serial "driver" and a TCP/IP "driver". The IO layer provides an interface so that the drivers need only deal with the media and pass the reassembled packet to the "Modbus interface". Said same interface could now be used for serial, Ethernet, and Modbus boards (if such a thing exists). Why you ask? Because the low level stuff could then execute kernel mode for real time or even on a card. Devicenet is probably a better example here. We can do Devicenet at least two ways. We can use a CAN card with a Devicenet engine in the IO layer. or we can use a coprocessor card with a "register" or shared
memory interface. The CAN card approach is a lot more generic and much cheaper if we have the Devicenet stuff in the IO layer. But we could
use either fairly easily if this IO layer has a virtual register IF and a "CAN for Devicenet" IF. The same situation exists for Profibus. It runs on a serial protocol rsXXX ( I forget which at the moment ) and with realtime execution, we could do Profibus in software and use a cheap serial card. Or of course, we can use another $1000.00 dollar processor card that has a shared memory interface.

I'm not simply trying to make life difficult, I have been looking at what is really available to put these "real world" protocols on lplc. On PC hardware there are three basic levels of IO, "dumb" IO where you for example, use the serial port or a port card and everything
else, protocol, timing, diagnostics, etc would now be in the "driver". "Smart IO" where the protocol runs on a processor on the board and
uses memory locations for communications (virtual registers). For these we still need a "protocol" to sort out addressing, etc. this would be in the "driver" now. Ethernet IO where any and every
protocol known to man will be layered on top of TCP/IP or UDP.

As is logical, the most expensive solutions are the easiest to do. The coprossor cards do all the "hard parts" and you simply talk to memory locations. They have the licensing and certification and protection racket money all paid up front The "driver" is fairly
straightforward but still, anything but trivial. Having a free PLC and paying $1000.00 for a protocol board would be ludicrous in any other field, but in automation is somewhat viable as people will routinely waste huge amounts of money for simplicity and ease of use.

LPLC will not provide substantial value over commercial offerings if we do much of that. Where our value will be is offering the same
functionality with the base cards. This requires protocols, soft and sometimes hard realtime, working around or with the various organizations and either goodwill donation or funding for "memberships". This is why I made an appeal to them to help us out.

Be that as it may, these silly notions I have been having are an effort to provide in LPLC the various services and interfaces needed to make using what's out there as easy as possible. It's important because the system that supports the most stuff wins. We all want LPLC to open things up and be significant in the market along with
other less universal goals. Writing low level software is hard and if we don't find the ways to make it easier we aren't going to make that goal. This is the time I would like those of you familiar with the hardware we have to work with to contribute what you know to propose ways to interface classes of hardware and families of protos so we can become viable quickly.

Examples:

From what I've seen, one memory interface could possibly be made to deal with several SST cards and thus several protocols in one fell swoop. Not easy, but possible.

An Ethernet framework or skeleton that takes care of the boilerplate and common programming for IP protos.

The modbus engine sketch.

As programmers, we look at how a piece of hardware works and what it has to talk to and write code that does that. This is the stage we
are at now. Eventually someone notices that quite a bit of hardware works in basically the same way, or there is code to do the same thing in this bunch of drivers and solves the general case. This is where much of the PC industry is. We have help from ideas like the Comedi project at "the Linux Lab Project" This is sort of a driver generator for DAQ cards. This is what a programmer does after writing one too many drivers.

I know these ideas are fuzzy and sketchy at this time and there are major omissions like how to deal with all the setup and config detail. This is stuff I've been pondering on and off for years in trying to put Linux into the automation world. I'm not wanting to delay the contributing guys from what they are doing. I'm trying to get some
more minds working on this very big and important area for lplc. I know that I am not smart enough or good enough to be able to do this on my own. But, I have a secret weapon.

We have people lurking that constitute a major part of what has been done with IO in the real world, what works, what doesn't, and most important, how it should be. With that kind of talent we should be able to do it the best way ever. If we can be revolutionary rather than evolutionary we will do for automation what Linux is doing for the internet, becoming the best tool for the job. If you've ever longed for that chance, here it is.


Regards

cww

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

 

Curt Wuollet <[email protected]> writes:

> As is logical, the most expensive solutions are the easiest to do.
> The coprossor cards do all the "hard parts" and you simply talk to
> memory locations. They have the licensing and certification and
> protection racket money all paid up front The "driver" is fairly
> straightforward but still, anything but trivial. Having a free PLC
> and paying $1000.00 for a protocol board would be ludicrous in any
> other field, but in automation is somewhat viable as people will
> routinely waste huge amounts of money for simplicity and ease of use.
>
> LPLC will not provide substantial value over commercial offerings if
> we do much of that. Where our value will be is offering the same
> functionality with the base cards. This requires protocols, soft and
> sometimes hard realtime, working around or with the various
> organizations and either goodwill donation or funding for "memberships".
> This is why I made an appeal to them to help us out.

Sorry, I don't agree with this. LPLC can provide at least two important types of value: price and choice. I agree that hooking a Linux box up to expensive IO won't provide any price advantage, but this overlooks the, IMHO, more important benefit of choice. Choice means choice of hardware components, communication protocols, external interfaces, etc. It is fundamentally the difference between choosing how automation will work in your company and letting your vendor
choose how automation will work in your company. As LPLC moves into commercial use, I believe that this will be the type of value that makes companies decide to use it.

Despite that, I agree with almost everything else you wrote

Dan Pierson

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

 

That's okay Dan, I hope you're right. I just haven't seen the enthusiasm for choice that I've seen in the general computing world. To tell the truth I don't know what the criteria are for selecting automation systems. Sadly, I think that good marketing and looks cool are a part of it. I can't explain the Windows invasion either. Apparently familiar and easy to use are above all those pesky technical details.

I guess reading it again, we _will_ provide value. We need for it to provide compelling value to get people to jump. If choice and value were all it takes everyone would be using Linux already:^) In any case we'll probably support
it all........... so people can have a choice..

Regards

cww

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