[ag-automation] LDI-Interface

[Thomas Rothfuss]

>>>For the OSADL framework, things will have to be integrated into the C
>>>code. But anyway, that's a thing we can do a little bit later, when the
>>>framework itself has stabilized.
>>
>>The interface is a C interface. See FAPIA.h.
> 
> 
> We want to keep the overhead low. Note that not all people out there are
> in the luxury situation to have a big machine under the code; note that
> there are also things like netX with 8 MB RAM, or ARM720 with 75 MHz,
> but CAN bus. We also want to keep the build prerequisites low.
> 
> 

We use it in our PC85L Control. There we have the necessary resources.
 From the programmers view: Using ACE means to have a very powerful
abstraction layer for many operating systems. We run FAPIA
under Linux and Windows. We don't want to code the abstraction
layer on our own since there are already very good ones available.

ACE itself is used for realtime applications like DDS
(http://www.opendds.org/). "Only" the storage is needed.

We do not run the FAPIA on small machines.



> Hardware address of ... what? Speaking of CAN, that doesn't have such a
> thing. It just has messages, identifiers and message payload, and they
> are communicated to the driver via sockets, so there is no need to know
> anything about hardware addresses outside of the kernel driver. Or
> CANopen? Do you mean Object Dictionairy addresses?
> 
> Note also that, at the moment, there is no such thing as a CAN process.
> All backend implementation is done with shared library "drivers", being
> loaded dynamically with dlopen. I suppose you are talking about these
> adapter code.
> 

This was a use case for our actual software topology. The address
includes the control unit, the slot, the port and the address of
the CAN.


> 
>>2. There is a logical device with parameters The CNC wants to set the
>>parameter "speed" at the "X-axis". The CNC-Process sets the
>>logical_object_name in the FAPIACommunication struct to "X-axis". In
>>the FAPIAParameter struct the parameter_name is set to "speed". In the
>>FAPIAValue struct the data_value is set. Now the function
>>fapia_parameter_write_request is called. FAPIA looks up in the
>>configuration file named fieldbus_conf.xml where the "X-axis" is
>>located. This is e.g. the "Profinet"-Process. So the message is sent
>>to the Profinet-Process. This process does the conversion from the
>>Logical Device Interface (LDI) to the FDDI.
>>
>>So the only thing FAPIA has to interpret is the configuration file to
>>retrieve the destination address.
> 
> 
> I had the impression that we would be talking about async communications
> here?

Oops you're right. Setting the speed of an X-axis is a cyclic
communication. But this example should has been an acyclic one.



Thomas