[ag-automation] FDDI (Fieldbus Device Driver Interface) Update

[Robert Schwebel]

On Mon, Jun 18, 2007 at 11:09:56PM +0200, Robert Schwebel wrote:
> ... and a first autotoolized version as my personal playground is here:
> 
> 	https://www.osadl.org/svn/osadl/software/fieldbus-framework/fddi-20070618-1-ptx1

The trunk based on that proposal is here, btw:

	https://www.osadl.org/svn/osadl/software/fieldbus-framework/fddi-20070618-1-trunk

The current state is that I've implemented the 3S proposal using
standard POSIX mechanics (basically an object model following the idea
of pthreads). It now has the API interface more or less consistent with
the 3S proposal; to get the picture how it is supposed to be used,
please have a look at the unit test programs in tests/. Note that it is
far from being functional, but it's in a state where one can fill in the
needed functionality for a real life fieldbus.

The tests/ directory does also contain an example how an external piece
of code (like a commercial fieldbus stack), living in libexamplebus.so,
can be wrapped by an fddi adapter library, libfddi_examplebus.so, which
is automatically pluged into libfddi.so with lt_dlopen. Note that the
current mechanics how to identify the fieldbus class/type and instance
is not final; it will probably has to be integrated into some global
configuration model.

On Tue, Jun 26, 2007 at 09:42:11AM +0200, Herbert.Graf at homag.de wrote:
> it's not neccessary to have a hacking session.

I still think it would be a good idea. The two hours we've played with
the code after the general assembly in Stuttgart was a pretty good thing
with regard to getting all relevant information together.

> There are some ambiguous points concerning bus controlling and
> interpreting FDDI-Data. We have to discuss these points at homag this
> week. Afterwards we publish our fddi-layer proposal.

For bus control, please have a look at the fddi_iface_cmd() method; I'm
not sure if it provides enough abstraction for all fieldbusses, but I
suppose if that method works in CoDeSys, it cannot be too bad :-)
Nevertheless, please let's discuss your ideas here.

Wrt. interpreting FDDI data, my impression is that the transportation
units are a good abstraction for "packets of process variables" which
can be transferred at once. The description model is still a little bit
rudimentary; I'd like to see a more sophisticated description here,
taking into account that for example in measurement technology there are
some other requirements than in automation. But as far as I see now, the
abstraction is good and it's all a matter of what attributes a process
variable object will have.

Regarding configuration, I think it should be possible that each stack
implementation can have its own idea how configuration works; in the
end we'll have to live with commercial configurators out there which
won't change just because we are appearing on stage. Nevertheless, it
would be good to have an OSADL configuration xml format which _can_ be
used in cases that can be controlled by us. Mr. Hess promised that he
could open up the 3S config format, so I'm looking forward to seeing its
definition.

Regards,
Robert Schwebel
-- 
 Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
   Handelsregister:  Amtsgericht Hildesheim, HRA 2686
     Hannoversche Str. 2, 31134 Hildesheim, Germany
   Phone: +49-5121-206917-0 |  Fax: +49-5121-206917-9