[ag-automation] LDI-Interface

[Thomas Rothfuss]

Sorry for the delay of this answer. Your reply and some other mails
from this mailing list were marked as spam :-(
I didn't get them.

  >>> A caller has to do following steps:
  >
  >
  >Thanks for posting your proposal. Please, when posting code, always give
  >us a statement about the license this code is released under. For the
  >code we already have in the fieldbus repository, we've taken GPL plus
  >Link Exception, so that would be the prerequisite for integrating the
  >code into the repository.
  >

FAPIA is based on the ACE library
(http://www.cs.wustl.edu/~schmidt/ACE.html). We decided to use the same
license. See text below or at http://www.theaceorb.com/product/license.html

  >
  >>> 1. Set the callback functions for the kind of responses needed:
  >>>
  >>>     fapia_set_callback_for_parameter_read_response_callback (
  >>>         fapia_parameter_read_response_callback)
  >>>
  >>>     fapia_set_callback_for_parameter_write_response_callback (
  >>>         fapia_parameter_write_response_callback)
  >>>
  >>>     fapia_set_callback_for_parameter_info_response_callback (
  >>>         fapia_parameter_info_response_callback)
  >
  >
  >Could you elaborate on the details of this read/write/info abstraction?
  >How does it map to different fieldbusses, and how is it supposed to be
  >used? I assume the async interface is tricky to be done in a fieldbus
  >independend way (in fact I cannot really imagine that it is possible at
  >all).
  >
  >Let's start some discussion how that fits into the abstraction we
  >already have in the FDDI. There are these objects:
  >
  >- fddi_iface:  interface (access object for a fieldbus)
  >- fddi_tpu:    transportation unit (for process data)
  >- fddi_device: physical or logical devices (like a bus coupler)
  >- fddi_param:  parameters (key/value)
  >- fddi_pv:     process variables (description of payload
  >
  >At the moment, an fddi_device has these methods for async communication:
  >
  >extern int fddi_dev_read_async(fddi_device_t *dev /* FIXME */);
  >extern int fddi_dev_write_async(fddi_device_t *dev /* FIXME */);
  >
  >So this would probably be the place where we would integrate the
  >structures.
  >

For FAPIA only parameters exist. They have a parameter name. In the
FAPIACommunication structure the logical_object_name has to be set as
the destination address. The parameter name specifies the parameter at
that logical device. Either the logical device is the communication
partner like "CNC" (see function fapia_init below) or a logical device
(e.g. "x-axis" which is mapped to the corresponding communication
partner (e.g. "ProfinetProcess") by using a configuration file.

There are three functionalities:

1. The information about a parameter can be obtained (struct FAPIAInfo)
2. Parameters can be read (struct FAPIAParameter for the request and
     FAPIAValue for the response)
3. Parameters can be written (struct FAPIAParameter and FAPIAValue for
     the request)



  >
  >>> 2. Call the init function:
  >>>
  >>>     fapia_init (argc, argv, "CNC")
  >>>     Runtime parameter could be "-FAPIADebugLevel <debug level>"
  >
  >
  >I'd change that into an interface which fits better into the object
  >oriented design we have for the rest of the code. But that's details; I
  >suppose that doing it in the same way as with the FDDI is a good method:
  >I refactored the original code in a posix like way and put it back into
  >the repository for review.

FAPIA internally has an object oriented design. But the interface is
pure C (only structs and functions). This is because any C or C++ (or
other languages) Application may use FAPIA.

  >
  >
  >>> 3. Do the communication
  >>>
  >>>     fapia_parameter_read_request (...)
  >>>
  >>>     The FAPIA-Lib has own threads. Within such a thread the
callback set
  >>>     by the application (in point 1 it's
  >>>     fapia_parameter_read_response_callback)is called. Within this
  >>>     function the application can handle the response.
  >>>
  >>>     Write and Info requests are similar.
  >
  >
  >If you already have the code as a lib, would you be able to post it
  >somewhere as a reference?
  >

I tried to send it but the message body was too big. Carsten Emde will
set up some space to put it there.

  >
  >>> A callee has to do following steps:
  >>>
  >>> 1. Set the callback functions for the kind of requests which are
expected:
  >>>
  >>>     fapia_set_callback_for_parameter_read_request_callback (
  >>>         fapia_parameter_read_request_callback)
  >>>
  >>>     fapia_set_callback_for_parameter_write_request_callback (
  >>>         fapia_parameter_write_request_callback)
  >>>
  >>>     fapia_set_callback_for_parameter_info_request_callback (
  >>>         fapia_parameter_info_request_callback)
  >
  >
  >What is a "parameter" in your abstraction, for example for CANopen?
  >

See comment above.

  >
  >>> 2. Call the init function:
  >>>
  >>>     fapia_init (argc, argv, "CAN1")
  >>>     Runtime parameter could be "-FAPIADebugLevel <debug level>"
  >
  >
  >Will probably be intergrated into the already existing code; the async
  >interface is, according to my understanding, just a part of the FDDI.
  >
  >
  >>> 3. Do the communication
  >>>
  >>>     When a caller sends a request the appropriate callback function
  >>>     which was set by the callee is called (e.g.
  >>>     fapia_parameter_read_request_callback (...)).
  >>>
  >>>     In this example the CAN1-Process may get a read request. It then
  >>>     reads the values from the CAN-bus (this may happen in the
  >>>     callback-function) and sends the result to the caller by function
  >>>
  >>>     fapia_parameter_read_response (...)
  >>>
  >>>     Write and Info are similar.
  >
  >
  >Are you talking about plain CAN here, or about CANopen? The FDDI and
  >higher layers never see plain CAN messages, and for CANopen, how would
  >that map to for example SDO transfers?
  >

FAPIA is totally independend from CAN. It is just a neutral communication
layer between processes. This was just an example we use.


Regards,
Thomas Rothfuss




       _________________________________________________________________

    Copyright and Licensing Information for the FAPIA of Homag AG, Germany

     The Homag AG FAPIA, following named as HomFapia, is copyrighted by
     the Homag AG, Germany, Copyright (c) 200x-20xx, all rights reserved.
     Since HomFapia is open source free software, you are free to use,
modify,
     and distribute the HomFapia source code and object code produced from
     the source, as long as you include this copyright statement along with
     code built using HomFapia.

     In particular, you can use in proprietary software and are
     under no obligation to redistribute any of your source code that is
     built using HomFapia. Note, however, that you may not do anything
     to the HomFapia code, such as copyrighting it yourself or claiming
     authorship of the HomFapia code, that will prevent HomFapia from
     being distributed freely using an open source development model.

     HomFapia is provided as is with no warranties of any kind,
     including the warranties of design, merchantibility and fitness for a
     particular purpose, noninfringement, or arising from a course of
     dealing, usage or trade practice. Moreover, HomFapia is provided
     with no support and without any obligation on the part of Homag AG,
Germany
     to assist in its use, correction, modification, or enhancement.

     Homag AG, Germany shall have no
     liability with respect to the infringement of copyrights, trade
     secrets or any patents by HomFapia or any part thereof. Moreover,
     in no event will Homag AG, Germany be
     liable for any lost revenue or profits or other special, indirect and
     consequential damages.

     By submitting comments, suggestions, code, code
     snippets, techniques (including that of usage), and algorithms,
     submitters acknowledge that they have the right to do so, that any
     such submissions are given freely and unreservedly, and that they
     waive any claims to copyright or ownership. In addition, submitters
     acknowledge that any such submission might become part of the
     copyright maintained on the overall body of code, which comprises the
     HomFapia software. By making a submission, submitter agree
     to these terms. Furthermore, submitters acknowledge that the
     incorporation or modification of such submissions is entirely at the
     discretion of the moderators of the open source HomFapia projects
     or their designees.

     The names HomFapia, and Homag AG, Germany may not be used to endorse or
     promote products or services derived from this source without express
     written permission from Homag AG, Germany. Further, products or
     services derived from this source may not be called HomFapia.