Design a way for wrapping OOP blocks into blocks with traditional interface.

[PTKu]

Prototype an example of wrapper class... + design testing and documentation.

Following discussion:

#13 (comment) and related

and
#13 (comment)
#21 (reply in thread)

[HAHermsen]

moved to #75

[PTKu]

@HAHermsen is this a comment to #75 ?

[HAHermsen]

Some ideas based on popular DCS design paradigm's approach which is used in the both 800xA and PCS-7. the paradigm is actually very smart and allows for a sophisticated and fine grained control scheme for the Control Module. To be honest I could write a massive document on it but we better start out small so here are is my preliminary idea

The innermost FB which uses OOP approach

• The innermost FB will expose a minimum of traditional parameters as to keep the instanciation quick and clean.
• Setup of the FB instance can be done via the Config struct or via the the config method which accepts a config struct.
• My suggestion would be to avoid using FB_Init as this will make the FB slightly more rigid as that usage is mandatory with declaration, while the actual setup can be done via a parameter struct or method which allows for more flexibility in the code.

Wrapper FB (uses classical approach mostly)

• The wrapper should encapsulate the inner most FB by composition to allow for a maximum of continued use for the end user as he she can still use inheritance or composition
• The traditionally connected structs as parameters will be connected to the methods of the encapsulated FB
• A struct for controlling the FB via Automatic code (called auto in DCS world),
• A struct for colntrolling the FB via HMI (called manual/hand in DCS world),
• A set of signals in the object Status which tell that the FB is in Auto or Hand, Locally Controlled or even in Tag Out mode
• The Local / Remote control switch is connected via the IO struct which is IN/OUT at once so both in and out signals are declared.Some examples of IO signals in the

IO.iFbOn, // pretty self explanatory, Feedback open reached
IO.iFbCls, // pretty self explanatory, Feedback close reached
IO.oCmdOpen, // pretty self explanatory, command open, could be pulsed or continuous depending on a config setting, usually continous until a feedback is reached
IO.oCmdClose, // pretty self explanatory, command close, could be pulsed or continuous depending on a config setting, usually continous until a feedback is reached
IO.iRemoteControl // If Enabled the device is controlled via either hand /auto signals of the FB, if it is false, the operator contols the device locally (in the field)
IO.TagOut // The device is DISABLED and POWERED DOWN for use, it has been tagged out by Lock Out, Tag Out procedure. The control system may NEVER send IO signals to the device, als incomming IO signals should/will be ignored

• The Remote/Local control switch tells the FB if it simply needs to follow the field (Local control) or can send commands to the field (via AUTO / HAND)
  Status.eCtrlMode // Enumeration current Hand, Auto, Local or TagOut status

@PTKu you may move this post at your discretion to a discussion

[PTKu]

@HAHermsen sounds good to me... let's first close the topic around component structure #75
Then we will need to see where do we place wrapper blocks, as I am thinking about it would be better to have them in a separate project(s).

I am converting this to discussion