Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly
Appearance settings
This repository was archived by the owner on Mar 25, 2025. It is now read-only.
Discussion options

PTKu
May 3, 2021
Maintainer

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

Following discussion:

#13 (comment) and related

and
#13 (comment)
#21 (reply in thread)
You must be logged in to vote

Replies: 4 comments · 1 reply

Comment options

HAHermsen
May 13, 2021

moved to #75
You must be logged in to vote
0 replies
Comment options

PTKu
May 13, 2021
Maintainer Author

@HAHermsen is this a comment to #75 ?
You must be logged in to vote
0 replies
Comment options

HAHermsen
May 17, 2021

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
You must be logged in to vote
1 reply
@runtimevic
Comment options

runtimevic May 17, 2021

Algunas ideas basadas en el enfoque popular del paradigma de diseño DCS que se utiliza tanto en el 800xA como en el PCS-7. el paradigma es en realidad muy inteligente y permite un sofisticado y fino esquema de control de granos para el módulo de control. Para ser honesto, podría escribir un documento masivo sobre él, pero será mejor que empecemos pequeños, así que aquí está mi idea preliminar

El FB más interno que utiliza el enfoque OOP

  • El FB más interno expondrá un mínimo de parámetros tradicionales para mantener la instanciación rápida y limpia.
  • La configuración de la instancia FB se puede realizar a través de la estructura Config o a través del método config que acepta una estructura de configuración.
  • Mi sugerencia sería evitar el uso de FB_Init ya que esto hará que el FB sea un poco más rígido, ya que ese uso es obligatorio con la declaración, mientras que la configuración real se puede hacer a través de una estructura de parámetros o método que permite una mayor flexibilidad en el código.

Wrapper FB (utiliza enfoque clásico principalmente)

  • El envoltorio debe encapsular la mayor parte interna de FB por composición para permitir un máximo de uso continuo para el usuario final, ya que todavía puede usar herencia o composición
  • Las estructuras tradicionalmente conectadas como parámetros se conectarán a los métodos del FB encapsulado
  • Una estructura para controlar el FB a través de código automático (llamado auto en el mundo DCS),
  • Una estructura para colntrolling el FB a través de HMI (llamado manual / mano en el mundo DCS),
  • Un conjunto de señales en el estado del objeto que indican que el FB está en automático o manual, controlado localmente o incluso en modo de salida de etiqueta
  • El interruptor de control local / remoto se conecta a través de la estructura de E/S que es IN/OUT a la vez así que se declaran las señales de entrada y salida. Algunos ejemplos de señales de E/S en el

IO.iFbOn, // bastante autoexplicativo,
Retroalimentación abierta alcanzó IO.iFbCls, // bastante
autoexplicativo, Feedback close reached IO.oCmdOpen, // bastante autoexplicativo, comando abierto, podría ser
pulsado o continuo dependiendo de un ajuste de configuración, normalmente continuo hasta que se alcanza una retroalimentación IO.oCmdClose, // bastante autoexplicativo, comando close, podría ser pulsado o continuo dependiendo de un ajuste de configuración, generalmente continuo hasta que se alcanza
un feedback IO.iRemoteControl // Si enabled el dispositivo se controla a través de señales manuales /automáticas del FB, si es false, el operador contoliza el dispositivo localmente (en el campo)
IO. TagOut // El dispositivo está DESHABILITADO y APAGADO para su uso, ha sido etiquetado por lock out, procedimiento tag out. El sistema de control puede NUNCA enviar señales de E/S al dispositivo, als incomming señales de E/S deben / serán ignorados

  • El conmutador de control remoto/local indica al FB si simplemente necesita seguir el campo (control local) o puede enviar comandos al campo (a través de AUTO / HAND) Status.eCtrlMode // Estado actual de la enumeración Mano, Auto, Local o TagOut

@PTKu puede mover este post a su discreción a una discusión

@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...
Comment options

PTKu
May 17, 2021
Maintainer Author

@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
You must be logged in to vote
0 replies
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
3 participants
@PTKu @runtimevic @HAHermsen
Converted from issue

This discussion was converted from issue #28 on May 17, 2021 11:55.

Morty Proxy This is a proxified and sanitized view of the page, visit original site.