add Cylinder proposal STRUCT

[runtimevic]

Hi,
create a Cylinder proposal STRUCT......
proposal of component structure, for example the cylinder component has been chosen, but the PTP axis could also have been made, I hope this helps to make everything clearer ...

[HAHermsen]

Current cyclinder proposal

VAR_INPUT
	In : ST_Cyl_inputs;
END_VAR
VAR_OUTPUT
	Out : ST_Cyl_inputs;
END_VAR
VAR
	Config:	ST_Cyl_Config;
	Control: ST_Cyl_Control;
	Status: ST_Cyl_Status;
	Diag: ST_Cyl_Diagnosis;
VAR

Suggestion proposal based on practical / empirical knowledge;

FUNCTION_BLOCK Cylinder IMPLEMENTS ICilinder
VAR_INPUT
	Config : ST_Cyl_Config;
	AutoControl : ST_Cyl_AutoControl; // Control signals from internal automated logic
	ManControl : ST_Cyl_ManControl; // Control signals from HMI
END_VAR
VAR_IN_OUT
	IO : ST_Cyl_IO; // Contains IO based in & outputs
END_VAR
VAR_OUTPUT
        Status: ST_Cyl_Status; // I personally think DIAG can be embedded int the status struct, like so;
	// Status.Diag.CylHealth
	// Status.Diag.Error 
END_VAR

This way ICilinder should expose all methods / properties contained in the traditional parameters

[runtimevic]

Propuesta actual de ciclólica

VAR_INPUT
	In : ST_Cyl_inputs;
END_VAR
VAR_OUTPUT
	Out : ST_Cyl_inputs;
END_VAR
VAR
	Config:	ST_Cyl_Config;
	Control: ST_Cyl_Control;
	Status: ST_Cyl_Status;
	Diag: ST_Cyl_Diagnosis;
VAR

Propuesta de sugerencia basada en conocimientos prácticos /empíricos;

FUNCTION_BLOCK Cylinder IMPLEMENTS ICilinder
VAR_INPUT
	Config : ST_Cyl_Config;
	AutoControl : ST_Cyl_AutoControl; // Control signals from internal automated logic
	ManControl : ST_Cyl_ManControl; // Control signals from HMI
END_VAR
VAR_IN_OUT
	IO : ST_Cyl_IO; // Contains IO based in & outputs
END_VAR
VAR_OUTPUT
        Status: ST_Cyl_Status; // I personally think DIAG can be embedded int the status struct, like so;
	// Status.Diag.CylHealth
	// Status.Diag.Error 
END_VAR

De esta manera ICilinder debe exponer todos los métodos / propiedades contenidas en los parámetros tradicionales

Current cyclinder proposal

VAR_INPUT
	In : ST_Cyl_inputs;
END_VAR
VAR_OUTPUT
	Out : ST_Cyl_inputs;
END_VAR
VAR
	Config:	ST_Cyl_Config;
	Control: ST_Cyl_Control;
	Status: ST_Cyl_Status;
	Diag: ST_Cyl_Diagnosis;
VAR

Suggestion proposal based on practical / empirical knowledge;

FUNCTION_BLOCK Cylinder IMPLEMENTS ICilinder
VAR_INPUT
	Config : ST_Cyl_Config;
	AutoControl : ST_Cyl_AutoControl; // Control signals from internal automated logic
	ManControl : ST_Cyl_ManControl; // Control signals from HMI
END_VAR
VAR_IN_OUT
	IO : ST_Cyl_IO; // Contains IO based in & outputs
END_VAR
VAR_OUTPUT
        Status: ST_Cyl_Status; // I personally think DIAG can be embedded int the status struct, like so;
	// Status.Diag.CylHealth
	// Status.Diag.Error 
END_VAR

This way ICilinder should expose all methods / properties contained in the traditional parameters

Hello @HAHermsen ,
I think it is all correct, you can start from what you have modified and when you add the new components you can improve to change as we see....

[PTKu]

Hi guys, I will be happy for this thread to continue further, just I would like to point out few things:

• In order to get to a unified look, we have a document that describes some basic conventions, we can discuss the document further. However, it was decided early on to get rid of Hungarian notation. There are some exceptions as you will find in the document (pointer, ref, etc). I know there is a tradition for it, and people are used to it but, with modern IDE they are not so useful. I really do not want the discussion about personal preferences to run forever otherwise we will not move anywhere.
• There is some work done and already discussed in early discussions, so before you come up with a structure it would be useful to get familiar with the work already done. Otherwise we will be running around circles. I am open to discuss that work, the document might be not clear enough, but let's improve that.
• Here is an article that I wrote introducing TcOpen and explaining how do we want to proceed.
• The last thing in this regard, we want to aim at more as declarative paradigm (declarative vs imperative). I would also highly recommend this article

[runtimevic]

Hola chicos, estaré feliz de que este hilo continúe más, sólo me gustaría señalar pocas cosas:

• Para llegar a un aspecto unificado, tenemos un documento que describe algunas convencionesbásicas, podemos discutir el documento más a fondo. Sin embargo, se decidió desde el principio deshacerse de la notación húngara. Hay algunas excepciones como encontrará en el documento (puntero, referencia, etc.). Sé que hay una tradición para ello, y la gente está acostumbrada a ello, pero, con el IDE moderno no son tan útiles. Realmente no quiero que la discusión sobre las preferencias personales funcione para siempre de lo contrario no nos moveremos a ninguna parte.
• Hay algunos trabajos realizados y ya discutidos en las primeras discusiones, por lo que antes de llegar a una estructura sería útil familiarizarse con el trabajo ya hecho. De lo contrario, correremos por círculos. Estoy abierto a discutir ese trabajo, el documento podría no ser lo suficientemente claro, pero vamos a mejorar eso.
• Aquí hay un artículo que escribí presentando TcOpen y explicando cómo queremos proceder.
• Lo último en este sentido, queremos aspirar más como paradigma declarativo (declarativo vs imperativo). También recomendaría encarecidamente este artículo

Hello @PTKu ,
I think it would be good to have a structure for the components, so everything would be more declarative as I think it is what we want ...

[runtimevic]

Hi @PTKu
I think it would be good for the components that had the best declared structure possible and the most unified for all the components, so we would have good and reusable components ...
I have proposed a cylinder component to start with one of the simplest components that we can find and I think it is a good starting point, with what has been suggested I can make the second version of the proposed cylinder component .....

[PTKu]

@runtimevic absolutely!!! I do agree with you...what I am trying to say is that there is some work already done and we have to align to it. I am going to wrap my head around your proposal to understand the deeper reasoning behind these examples. Will also come up with a PR that we can discuss. Nice weekend everybody!!! Get some rest!!!!

[PTKu]

Hi guys, hope you had a nice weekend!
I do recognize a value in this PR. So just to summarize and open further questions:

Config

• Is a structure that contains data relative to settings of the component
• Can contain additional structures to organize the information
• Must NOT contain FBs only STRUCTs
• Must be stored in a backing field _config of a given type and exposed as property Config which should be REFERENCE TO <config_structure_type>
• All data must be initialized to default values (e.g. timeouts, etc) that represent the data-set of a fully operational component.
• The default settings should not prevent the component from functioning
• Mandatory settings relative to specific hardware or configuration must be clearly outlined in the documentation, as well as an example configuration data set with detailed explanation must be provided.
• Property Config can be mutable (can have setter) when it is necessary to provide an external configuration set at runtime, otherwise it is preferable to keep it not-settable (without setter) only individual data items can be modified.

Status

• Should contain arbitrary status information data
• Can contain additional structures to organize the information
• Must NOT contain FBs only STRUCTs
• Must be stored in a backing property _status of a given type and exposed as property Status which should be REFERENCE TO structure_type

Control

I am not exactly sure what would be encapsulated here. I suppose it should be a container for FBs @runtimevic could you elaborate more on this? In that case, it will need to be an FB that extends TcoObject.

Diag

@runtimevic can you describe what should be contained here... and how would that relate to TcoMessenger? And how the proposition of @HAHermsen to bend Diag into Status sounds to you?

Few comments about the code above:

• we should follow conventions as said somewhere above

INPUT and OUTPUT for Complex structure OK for a complex component like drive for simple components I would keep simple down to a series of primitive types. The consumer of the code will need to create two two-member wide structures for each cylinder.

VAR_INPUT
	In : ST_Cyl_inputs;   
END_VAR
VAR_OUTPUT
	Out : ST_Cyl_inputs;
END_VAR
VAR
	Config:	ST_Cyl_Config;
	Control: ST_Cyl_Control;
	Status: ST_Cyl_Status;
	Diag: ST_Cyl_Diagnosis;
VAR

@HAHermsen proposition
This design seems to be going in direction of traditional use where the control is made via control variables AutoControl and ManControl structures. I am not OK with this approach. We should do traditional implementation in wrapper classes for traditional use, let's open discussion about this and we can also create a specific project for this kind of activity. There is actually an issue opened on that #28 (we can convert it in discussion) and discuss it further.

The good idea here seems to me the use I/O based variables as IN_OUT, there are several good reasons for us to prefer it to pure INPUT or OUTPUTS. The only problem is that we will need to make sure we work with a valid reference inside the block. Here we need to close discussion #15

Passing Config as INPUT. If we use Config property we can setup the individual settings directly on the component without a need to declare a separate structure somewhere else. If we implement a setter (above question mutable vs immutable) we can pass external config structure when necessary.

FUNCTION_BLOCK Cylinder IMPLEMENTS ICilinder
VAR_INPUT
	Config : ST_Cyl_Config;
	AutoControl : ST_Cyl_AutoControl; // Control signals from internal automated logic
	ManControl : ST_Cyl_ManControl; // Control signals from HMI
END_VAR
VAR_IN_OUT
	IO : ST_Cyl_IO; // Contains IO based in & outputs
END_VAR
VAR_OUTPUT
        Status: ST_Cyl_Status; // I personally think DIAG can be embedded int the status struct, like so;
	// Status.Diag.CylHealth
	// Status.Diag.Error 
END_VAR

[HAHermsen]

We should do traditional implementation in wrapper classes for traditional use, let's open discussion about this and we can also create a specific project for this kind of activity. There is actually an issue opened on that #28 (we can convert it in discussion) and discuss it further.

Agreed on both. CYA in #28

[runtimevic]

We should do traditional implementation in wrapper classes for traditional use, let's open discussion about this and we can also create a specific project for this kind of activity. There is actually an issue opened on that #28 (we can convert it in discussion) and discuss it further.

Agreed on both. CYA in #28

@HAHermsen ,
I think it's a very good idea, if you want to make a proposed ptp motion cylinder or axis and I study it and tell you what I think, I have made a proposed cylinder in the repository but it is a first beta version, but if you think it is better your idea from my front, I will be waiting to study it...

[HAHermsen]

A demonstrative implementation and a basic idea on how the structs will be, go hand in hand.
my idea is that there is really no right or wrong, as long as the chosen solution is easily "grokable".