Hardware linkable variables. Best approach?

[PTKu]

There are several option that can be seen:

• GVL as list or primitive types
• GVL structured in more nested STRUCTs/FBs
• Directly in the FBs
• Directly in PRG
• Other approach

We used GLV and STRUCs organized in the same hierarchy as physical hardware. It is not a bad solution. However I guess this requires more in depth discussion.

[PTKu]

@philippleidig any insights on this?

[SankariNL]

In my opinion a GVL doesn't really make sense when using an OOP-approach for the rest of the software. I would propose to do it directly in the function block. This way if multiple instances exist, the IO is already defined.

When doing it inside a function block it can still be put into a struct to give it a specific place and for reusing IO declaration. Might also be easier when mocking the IO during testing? I have not much experience with that.

[PTKu]

OK... so the idea would be to have %Is and %Qs declared in FBs were we have control logic of the component and we would bind that directly to hardware?

[philippleidig]

I usually use some kind of dependency injection via the FB_Init.
This allows the user of the FB to decide for himself how and where he declares the IO variables.

In some cases it makes more sense to declare an array of IO variables instead of each instance of an FB individually.

[SankariNL]

OK... so the idea would be to have %Is and %Qs declared in FBs were we have control logic of the component and we would bind that directly to hardware?

Yes, inside the FBs the %Is and %Qs are declared.

It's just what I am used to, I don't really have another reference, so I'm open for other ideas. Just want to make sure that this aspect is not left 'we do it like we also do', but thought about and also setup in an OOP-way.

[PTKu]

Here is a brief description of a model that we use.

Two levels of abstractions:

Components abstraction level (CAL)

• Components (inputs, outputs, cylinders, barcode readers, robots, drives, rfids, etc) that are agnostic of specific hardware configuration.
• Even inputs and outputs (BOOL || NUMERICAL types) have wrapper classes that are also agnostic of physical hardware connection at this level of abstraction.

This approach make it possible to write and test the PLC program without prior knowledge about specific hardware installation.

Components

HMI Components

Hardware abstraction level (HAL)

Program structure that replicates physical structure/organization of the hardware IO and different components interfaces (different bus systems).
This layer is defined in global scope (this case GVL) as the IOs are accessible globally anyways.
This is the only place where we link variables to hardware.

Linking CAL and HAL

Assignment of hardware linked variables to component is done in dedicated method (IntializeComponents()), that is called at the beginning of the PLC cycle (or prior to code that uses the components).

Pros and cons

Pros

• Hardware and logical components separated
• Simple and well organized view of hardware installation
• Possibility to vary I/O for the components with additional logic (exchangeable production fixtures)

Cons

• Components initialization must be cyclical / or at least must be called prior to component use (when required VAR_INTPUT and VAR_OUTPUT variable type)
• One cycle delay on updating the state of I/O from the components.

Propositions / Questions

1. I think we should keep the components free from I/O linkable variables because of wider possibilities for testing and simulation.
2. We should decide where do we declare I/O linkable variables. As @SankariNL says should we get rid of GVL avoiding global scope or is the global scope acceptable in this specific case?
3. Do we go with @philippleidig suggestion assigning I/O at block construction with FB_init? @philippleidig how would we deal with the necessity to change I/O assignment should that become necessary. Let's have a cylinder that operates on different fixtures (each fixture has its own decentralized hardware e.g. EC coupler [separated EC groups]) we would need to reassign I/O for that cylinder for each fixture, how would we do that?

Any feed back is warmly welcomed

Thanks!

[PTKu]

I do agree with @Barteling that @philippleidig is the cleanest solution... it's worth exploring further I...

There is the question of what kind of workflow one adopts. We use VAR_IN/OUTPUT/IN_OUT for the I/O assignment because we write the software long before the el. drawings are ready, and so we just abstract from the specific hardware with the above-mentioned CAL level. Then when the hardware is ready we assign I/O variables.

@philippleidig could you sketch up an idea of how you DI via FB_init, for us?

[dhullett08]

Also I know there has been some discussion about dynamically assigning IO via pragmas so there is no need to manually link IO and activate. Has anyone done any testing or research of this method? I'm not suggesting that this is the best way as I haven't done IO this way but I know it is possible.

[Barteling]

this is possible with the attribute TcLinkTo.
https://infosys.beckhoff.com/english.php?content=../content/1033/tc3_plc_intro/3107974923.html&id=

But it does not sound good to me to use this in a library..

[PTKu]

We did do some attempts with TcLinkTo attribute. It may be useful in some scenarios, but I agree with @Barteling it is not useful in a library... we would need to know the whole path to the hardware which is not useful if we want to have structured blocks for hardware terminals, and from the library's perspective, we are blind about the consumer's configuration anyway.

We have a homegrown solution for this... but it is very opinionated, so I would not introduce it here. Anyway, I'd like to refurbish some aspects of it. It also uses attributes, but it is able to construct the path from structured blocks... concatenating attributes... this works when the structure of the plc blocks mirrors the hardware configuration.... but there are also other possible approaches, like generating block directly from the hardware configuration.

[chris-k84]

Hi guys, late to the party sorry about that.

I've done some work with the pragmas they are very good once you combine them with conditional pragmas. So in projects I have my plc a hardware simulation plc then actual hardware. By simply defining real or sim I can change the entire linking structure. Which is nice. But its a lot of work at the start :-)

I generally make a structure or even a class for the io and pass that into the block through the init method.

However you must be careful the init isn't a constructor if you have layers of injection then you end up calling the init methods of the internal classes from the top level init method.

So say you have a hmi object, you pass it into your robot, which passes it to the individual elements. In the robot init method you will have to call the fbinit of the other components to pass the ref through.

I still think injection is the best way simply because it helps with TDD. Instead of passing a real valve island class we can pass a sim one for example.

Hope all that makes sense. Its quite late and my brain is fried.

[runtimevic]

I think the most successful thing is that the component itself has its own error diagnosis.

[PTKu]

Just for reference @runtimevic remark relates to #36

[PTKu]

@SankariNL @dhullett08 @SankariNL @jozefchmelar @philippleidig
Hi guys, we will need to make decisions here for us to continue working; this topic will soon become the blocking point.

Here is my proposal and few additional points:

• Components will not contain I/O variables directly (for testing/mocking/simulation).

• Component will take in I/O variables via FB parameters (INPUT, OUTPUT, VAR_IN_OUT),

• The body of the FB must be called prior to any other call that uses the component.

• Whenever the VAR_IN_OUT parameter is used, it must be ensured/checked in all methods/properties that such parameter is assigned (valid)

• It is advisable that the I/O variables are declared in a GVL/PRG, organized in a structure that resembles the actual hardware topology; this is not mandatory, and it is up to the application developer where the I/O variable is placed.

• I do not have a clear vision of the implementation details of Dependency Injection mentioned above (@philippleidig), but I would love to know more.

• The parameter transfer via FB_init would be a nice solution as we can enforce the parameters. However, I feel that FB parameter transfer gives more leverage to us and also to the application developers.

I'd really like to make a decision next week, thanks!

[SankariNL]

I agree with your proposal. I think it's a good idea to transfer the inputs and outputs via VAR_INPUT and VAR_OUTPUT. It's up to the user how to connect those (either global representing hardware structure, or maybe in programs or modules) to the components.

[chris-k84]

Hi guys,

I agree with passing by var in and out and the var_in_out. Or properties. Its easier and more flexible than fbinit which cannot be changed once done. Also nested classes are hard and you end up having to recall it to pass through dependencies.

From you more experienced people what is missing from dependancy injection in ST?

If I take a object for an el9227 for example. And pass it into the property of another object using an interface. What am I missing something big and stupid or something more nuanced?

[chris-k84]

On the fb cyclic calls I prefer not to cyclical call methods.

I tend to have a method as a trigger for an action that is executed in the main body this then provides feedback by properties and methods.

For example I am writting an xts plc block right now. I have wrapped the mc_reset function in a block. It has busy, error and done properties. It has a reset method and a hasreset method.

So my logic can then look for a done or error etc.

To be honest though its plc, its cyclic so we are going to have to call something cyclically. I guess for me using the body means we can seethe internal vars in the editor which you cannot with a method.

[philippleidig]

Hi guys,

Regarding the use of FB_body vs a cyclical update method. I would also opt for a method if there we had 'method overload' capability. If we were to add/remove parameters to say 'Cyclic' method we would need a method with another name. Also in case of the override (in derived block) of such method would require the identical method signature.

My point is that in case of 'Cyclic' method we would lose some unification how to initialize the component's, especially in case of block extension (Of course we could use composition, but I would not cut out the inheritance scenario.). It would not be always necessarily 'Cyclic' method. I believe that passing the I/O as parameters into FB_body is the most versatile option so I would go that way. When using FB_body we can at least add parameters in the derived blocks. Let me know if this explanation makes sense to you.

@PTKu, I really like this approach. To be honest, I've never thought about it that way before. The lack of method overloading is definitely limiting.
So far, I have assumed a more declarative approach to passing the HW IO in the declaration part of the function module. But here your approach with the FB_Body is definitely much more flexible.

Briefly back to the ITcoLogger.

Currently, I use @Barteling's fluent interface approach for logging, for example, in order to make the definition of arguments flexible and arbitrarily long. However, this also inflates the ITcoLogger interface somewhat. I'm curious about your PR :-)

_ipLogger
.ForCategory(LogCategory.IO)
.Args.AddDecimal(123213).AddString('sdfsd').Result
.Error('My log message {%d} with parameters {%s}');

[PTKu]

Hi guys,

I did start to draft the document about the components... please have a look.... in the second part there are some concepts that I will need to explain better.... anyway whoever of you with English mother tongue would like to help please do so... it is soooo painful for me to write in English.... and it takes so much time... I will leave it to you to comment on for a couple of days and then will continue. Thanks!

here is the link to the branch where I was working on that document
https://github.com/TcOpenGroup/TcOpen/blob/131-Create_document_with_best_practices_to_write_components/docs/Component.md

@philippleidig I will draft a PR for logging with some entry point into messenger... I would leave it to your creativity to make some proposal of logging, fluent syntax is great! I guess we should use it more... there is an implementation of StringBuilder that can also be used....

UPDATE: please post also questions here, it helps me to understand where I need to focus.