[ag-automation] OSADL FDDI remarks

[Peter Soetens]

Hi Robert,

On Wednesday 30 April 2008 18:07:39 Robert Schwebel wrote:
> Hi Peter,
>
> On Wed, Apr 30, 2008 at 05:22:53PM +0200, Peter Soetens wrote:
> > We're looking for a small C library which allows to communicate
> > different kinds of 'data' over any kind of bus (CAN, Ethernet,...)
> > from device A to device B and the other way round. We're happy with
> > 'hardcoding' the link from A to B in the lowest layers, so no
> > XML-configuration required yet. Instead of reinventing the wheel,
> > we're taking a look at the FDDI library.
>
> Good idea!
>
> > It looks like FDDI development stopped at the point where it got
> > interesting :-).
>
> Not at all :) It's just not visible to the outside at the moment, due to
> the fact that we are heavily working towards a new prototype which
> fulfills even more usecases.
>
> > It can 'discover' and 'command' devices, but not exchange data
> > (process variables). There are two use cases in the tests directory
> > which define the API for the to-be-written LDI.
>
> It turned out that the "bottom up" design doesn't necessarily lead so
> something useful, so we are currently coding another prototype which
> starts at the top level (application interface) and works down to the
> lower (fieldbus) layers. My current impression is that this will work
> out much better.
>
> >  * Is there any implementation/beta code of the LDI interface yet ?
> >  * Could you comment on the 'readyness' of the LDI API in the use cases,
> >    meaning, is it ripe/complete/final ?
>
> Well, we have a working prototype that is able to parse proprietary CAN
> protocols (you define an xml file that specifies that identifier
> $something has the engine speed encoded in little endian in bytes 2 and
> 3) and it magically maps that to process variables, whith locking,
> persistence, multi instance support, namespaces for actors (e.g. plc,
> cnc, LabView VI, Matlab or whatever).

Nice :-)

>
> Regarding the "readiness", we are currently writing down a project plan
> for how the remaining bits and pieces could be developed. As the
> interest throughout our customers as well as in OSADL seems to be
> immense, I'm currently positive that we get a working business plan for
> how to proceed with the missing things.
>
> >  * Also, is there by any chance uncommited code/documentation/examples ?
> > We're basically reverse engineering the code to understand what's
> > happening (which is ok given the small amount, but still...)
>
> No need to do that.

[...]

>
> All this is reality in our projects and has to be supported by a generic
> I/O framework. There is no sense in excluding a big part of the market,
> just because it uses the wrong programming language.

So you're talking a C library with language bindings.

>
> So how can we proceed? First of all, please wait a few days until I'm
> finished writing the technological proposal and finishing the next step
> of the prototype. I'd like to see the commercial perspective sorted out
> first; to finalize things in a professional way, it needs commercial
> commitments with the people who are interested. When we continue on a
> spare time base or with the speed of our customer projects, but that's
> probably not the fastest way go come to an end for the *generic*
> solution.

I'm waiting patiently, but I'll ping anyway :-). Am I correctly assuming that 
the end result will be an open-source library ? Do you have any info on code 
size / portability to 16bit-ers ? We're at a point where we'd like to take a 
descision on which framework we'll use. The competition for the FDDI is 
rather thin, so in absense of any real code, we'll start coding ourselves...

With kind regards,
Peter
-- 
Peter Soetens -- FMTC -- <http://www.fmtc.be>