[ag-automation] LDI-Interface

[Robert Schwebel]

On Thu, Jul 05, 2007 at 04:18:20PM +0200, Herbert.Graf at homag.de wrote:
> we introduce a very small LDI.
>
> Our opinion is, to have a very small interface for cylic data. For all
> other data, there is acyclic interface.
>
> The interface is realized with CoDeSys.
 
> 1. cyclic interface
> 
> The cyclic interface is very small and has less overhead. There are
> only values, which are transported cyclic between PLC/CNC and drives.

The process variable interface should not care about cyclic vs. acyclic,
these two transportation scenarios are only use cases of a generic
infrastructure. That's what the 3S proposal already includes.

These definitions...

> Definition of typAxisRef:
>         TYPE typAxisRef :
>         STRUCT
>         wVersionId          :SGN16;
> 
>         dSetPosition        :SGN32;          (* 0,1µ *)
>         dSetVelocity        :SGN32;          (* 0,1µ/s *)
>         dSetAccaleration    :SGN32;          (* 0,1µ/s² *)
>         dSetTorque          :SGN32;          (* Nm/10000 *)
>         dAxisControl        :typAxisControl; (* e.g. Start Referenz, cycl, .. *)
> 
>         tCommand            :typMotionCommand;
> 
>         tDriveState         :typDriveState
>         dActPosition        :SGN32;           (* 0,1µ *)
>         dActVelocity        :SGN32;           (* 0,1µ/s *)
>         dActAccaleration    :SGN32;           (* 0,1µ/s² *)
>         dActTorque          :SGN32;           (* Nm/10000 *)
>         dCapturePosition    :SGN32;           (* 0,1µ *)
>         dAxisState          :SGN32;
>         dActError           :SGN32;           (* act. state/error *)
> END_STRUCT
> END_TYPE
> 
> Definition of typAxisControl:
> TYPE typAxisControl :
> STRUCT
>         bStartHoming        :BOOL;            (* start homing *)
>         bCylicPosition      :BOOL;            (* interpret data as a data stream *)
>         bClearError         :BOOL;            (* clear actual error *)
>         bPowerOn            :BOOL;            (* enable power *)
>         bEnable             :BOOL;            (* enable moving *)
>         bCapture            :BOOL;            (* enable capture *)
> END_STRUCT
> END_TYPE
> 
> Definition of typMotionCommand:
> TYPE typMotionCommand :
> (
>         idle                :=0,
>         SetPosition         :=1,
>         SetVelocity         :=2,
>         SetTorque           :=3
> );
> END_TYPE
> 
> Definition of typDriveState:
> TYPE typDriveState :
> STRUCT
>         bHomed              :BOOL;             (* homing done *)
>         bPowerOn            :BOOL;             (* power on *)
>         bEnabled            :BOOL;             (* drive enabled
> *)
> END_STRUCT
> END_TYPE

... are concrete application "objects" (or process variable sets); IMHO
the important link between this example and the fddi interface is the
mapping layer, which is what we need a proposal for.

> 2. acyclic interface
> All other parameters for the drives (e.g. software endposition, jerk, ..) can
> be read or written by the FAPIA-Interface (Fieldbus-APplication-Interface-A
> cyclic).
> The FAPIA-interface consists of:
> 
>   * ReadRequest:            to get the value of the parameter
>   * WriteRequest:           to write the value of the parameter        
>   * InfoRequest:            to get the properties of the parameter
> 
> FAPIA lib is available from HOMAG.

Please post it somewhere, to make it possible to start review. The
important thing wrt. design is the abstraction and configuration/mapping
concept here as well.

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