Feature/additions to tcopneumatics

[PTKu]

• Synched with dev (Merge branch 'dev' into feature/addition_to_tcopneumatics')
• Fixies Resolve failing tests TcoRtc #98 removed Rtc synchronization that produced failed tests.
• Additions to pneumatic cylinder relates to add Cylinder proposal STRUCT #75

Pneumatic Cylinder

Config, Status

• Implementation of Config property of CyclinderConfig that contains times to reach home/work position (for reporting/alarming/simulation)
• Frankly do not know what I would add into Status of CylinderStatus as all information is available via TcoTask(done, busy, error...) and diagnostics via TcoTask.Messenger; I just added an action description, but do not see that necessary either.

Actions

• Actions are under Action folder.
• The implementation of action is TcoTask, there are two possible implementations one represents an extension of TcoTask (move home/work) and direct use of TcoTask (stop task). You'll find the implementation in the body of `Cylinder.

And in action

Untitled.Project.mp4

[runtimevic]

@PTKu ,
I see that you have added a config, status and actions,
I have been reforming the PTP axis a bit to make it more complicated and see how it would look, this is its last aspect:

VAR_IN_OUT
Input : ST_Axis_Input;
InConfig : ST_Axis_InConfig;
InControl : ST_Axis_InControl;
Output : ST_Axis_Output;
OutStatus : ST_Axis_OutStatus;
OutError : ST_Axis_OutError;
OutDiag : ST_Axis_OutDiagnosis;
END_VAR
VAR
sVersion : STRING := '2.0.2';
Stat : ST_Axis_Static;
END_VAR

[PTKu]

@PTKu ,
I see that you have added a config, status and actions,
I have been reforming the PTP axis a bit to make it more complicated and see how it would look, this is its last aspect:

VAR_IN_OUT
Input : ST_Axis_Input;
InConfig : ST_Axis_InConfig;
InControl : ST_Axis_InControl;
Output : ST_Axis_Output;
OutStatus : ST_Axis_OutStatus;
OutError : ST_Axis_OutError;
OutDiag : ST_Axis_OutDiagnosis;
END_VAR
VAR
sVersion : STRING := '2.0.2';
Stat : ST_Axis_Static;
END_VAR

@runtimevic I am not OK with bloating FB parameters with a long list of structures. We will need to create separate instances of structures in order to be able to use components, it's extra work, that is not necessary if we use properties. The intention here is to make use of OOP design. What you present above is an old-good way of doing components and we have #91 to discuss how to make OOP components usable in the "classical paradigm".

[jozefchmelar]

I gotta agree with @PTKu here. That's just way too many input parameters for a function block...the goal should be to make as simple as possible, but not simpler :)

[runtimevic]

@PTKu, veo que ha añadido una configuración, estado y acciones, he estado reformando un poco el eje PTP para hacerlo más complicado y ver cómo se vería, este es su último aspecto:
VAR_IN_OUT Entrada : ST_Axis_Input; InConfig : ST_Axis_InConfig; InControl : ST_Axis_InControl; Salida : ST_Axis_Output; OutStatus : ST_Axis_OutStatus; OutError : ST_Axis_OutError; OutDiag : ST_Axis_OutDiagnosis; END_VAR VAR sVersion : STRING := '2.0.2'; Estadísticas : ST_Axis_Static; END_VAR

@runtimevic No estoy de acuerdo con la hinchazón de los parámetros FB con una larga lista de estructuras. Tendremos que crear instancias separadas de estructuras para poder usar componentes, es trabajo adicional, que no es necesario si usamos propiedades. La intención aquí es hacer uso del diseño OOP. Lo que presentas anteriormente es una vieja y buena manera de hacer componentes y tenemos #91 para discutir cómo hacer que los componentes de OOP sean utilizables en el "paradigma clásico".

@PTKu @jozefchmelar

VAR_IN_OUT

Input : ST_Axis_Input;
InConfig : ST_Axis_InConfig;

Output : ST_Axis_Output;
OutStatus : ST_Axis_OutStatus;
OutError : ST_Axis_OutError;

END_VAR
VAR
sVersion : STRING := '2.0.2';
Stat : ST_Axis_Static;
END_VAR

can then be deleted: InControl : ST_Axis_InControl; (and make them just the methods) and deleted: OutDiag : ST_Axis_OutDiagnosis (and come from the properties);
so it would look better??