-
Notifications
You must be signed in to change notification settings - Fork 74
Duplicate FBs with slightly different Interface. #2342
Hi,
https://github.com/eclipse-4diac/4diac-ide/blob/develop/data/typelibrary/iec61131-3-3.0.0/typelib/selection/F_LOWER_BOUND.fbt
https://github.com/eclipse-4diac/4diac-ide/blob/develop/data/typelibrary/iec61131-3-3.0.0/typelib/selection/F_UPPER_BOUND.fbt
and
https://github.com/eclipse-4diac/4diac-ide/blob/develop/data/typelibrary/iec61131-3-3.0.0/typelib/arrays/F_LOWER_BOUND.fbt
https://github.com/eclipse-4diac/4diac-ide/blob/develop/data/typelibrary/iec61131-3-3.0.0/typelib/arrays/F_UPPER_BOUND.fbt
Ref.
Regards,
Franz
All reactions
Replies: 4 comments 11 replies
@MartinMelikMerkumians can you look into that please?
All reactions
We have the Problem that the Versions with IN_OUT are needed. But the Version with IN is needed as well; as for Arrays coming from a OUT pin it is impossible to connect to a IN_OUT pin.
All reactions
I checked the standard, and in fact the version with the IN is the one as it is in the standard and sorry I didnt thoroughly checked the type library first. I didn't expect it to be classified as "selection" FB, as it doesn't select anything.
I tested in the IDE that I can connect an IN_OUT to the ANY_DERIVED IN of the function FB.
However, I do not understand @diplfranzhoepfinger how an variable length array shall come from an OUT in the current state of 4diac.
The standard says, that variable length arrays in FBs can only be VAR_IN_OUTs, so you can never have one as an OUT on an FB.
They are allowed ad INs, OUTs, and VAR_IN_OUTs of FB methods (not supported as a public interface in 4diac to my knowledge) and functions. However, if I instantiate a function as an FB in 4diac, the validator says that I cannot have a variable length array as input or output.
As a final remark, the FB definition has been added to the type library 3 months ago. Have there been plans to implement it, or are we now starting providing FBs with no implementation and calling dibs on FB definitions?
All reactions
I can live with that. However 3. would not be approve but a ready for 4diac FORTE message. If we approve it is to dangerous that that the 4diac IDE PR gets merged without the other.
All reactions
I can live with that. However 3. would not be approve but a ready for 4diac FORTE message. If we approve it is to dangerous that that the 4diac IDE PR gets merged without the other.
yes, a Message is as well OK in my Opinion. then we would have:
- Open PR in IDE
- maybe changes
- ready for 4diac FORTE message
- Open PR in FORTE
- maybe changes
- Approve both PRs
- Merge both PRs
All reactions
of course. but if you want to apply a LOWER_BOUND or UPPER_BOUND to any other Array, you cannot connect it.
Please reread my comment, the version of LOWER_BOUND and UPPER_BOUND with an IN instead of an IN_OUT suffices for both use cases.
all true. but the IEC 61131-3 Functions for Bounds should work for any array, not only dynamic ones, right ?
I think so (I would need to check), but I do not see much use for this, as for regular arrays the upper and lower bounds are all known at design-time, and i you do not use variable length arrays, the upper and lower limits of each consuming FB implicitly knows the upper and lower bounds. Getting static design-time information via a run-time call seems not to be the best design imho.
Thanks for hinting to VALUES2ARRAY, this seems to be a legacy FB only specifying the arrays length (this should then default to 0 start if I am not mistaken), which should be updated then to new style array with explicit upper and lower bounds.
As @franz-hoepfinger-4diac brought up the topic of many changes due to names, packages, etc. I would even suggest to create a dedicated issue first, where the proposed FB is first described and presented. There namings, packages, functionality can be discussed without early-on investments and anchoring the process already with a given proposal.
The related PRs can then easily link to the issue. So both PRs can be pushed without interrelations, as the topics which would influence each other should have been solved already anyhow.
All reactions
As @franz-hoepfinger-4diac brought up the topic of many changes due to names, packages, etc. I would even suggest to create a dedicated issue first, where the proposed FB is first described and presented. There namings, packages, functionality can be discussed without early-on investments and anchoring the process already with a given proposal.
The related PRs can then easily link to the issue. So both PRs can be pushed without interrelations, as the topics which would influence each other should have been solved already anyhow.
Oh yes I like this even more.
All reactions
-
👍 1
of course. but if you want to apply a LOWER_BOUND or UPPER_BOUND to any other Array, you cannot connect it.
Please reread my comment, the version of LOWER_BOUND and UPPER_BOUND with an IN instead of an IN_OUT suffices for both use cases.
you ARE right. IN_OUT can be connected to a IN, but a OUT can not be connected to a IN_OUT.
so the IN Version is for any use-case sufficient.
all true. but the IEC 61131-3 Functions for Bounds should work for any array, not only dynamic ones, right ?
I think so (I would need to check), but I do not see much use for this, as for regular arrays the upper and lower bounds are all known at design-time, and i you do not use variable length arrays, the upper and lower limits of each consuming FB implicitly knows the upper and lower bounds. Getting static design-time information via a run-time call seems not to be the best design imho.
some Block giving Arrays on OUT as ANY ... for example ...
Thanks for hinting to VALUES2ARRAY, this seems to be a legacy FB only specifying the arrays length (this should then default to 0 start if I am not mistaken), which should be updated then to new style array with explicit upper and lower bounds.
OK. how ? (but this will be another PR)
As @franz-hoepfinger-4diac brought up the topic of many changes due to names, packages, etc. I would even suggest to create a dedicated issue first, where the proposed FB is first described and presented. There namings, packages, functionality can be discussed without early-on investments and anchoring the process already with a given proposal. The related PRs can then easily link to the issue. So both PRs can be pushed without interrelations, as the topics which would influence each other should have been solved already anyhow.
yes, i started to do so, e.g. here: eclipse-4diac/4diac-forte#188 and other places, I thought it would be good.
All reactions
To get here to some ToDos: If I understand you all we should remove the new versions for this types (added by @MartinMelikMerkumians) and @franz-hoepfinger-4diac adds his 4diac FORTE implementation for:
https://github.com/eclipse-4diac/4diac-ide/blob/develop/data/typelibrary/iec61131-3-3.0.0/typelib/selection/F_LOWER_BOUND.fbt
https://github.com/eclipse-4diac/4diac-ide/blob/develop/data/typelibrary/iec61131-3-3.0.0/typelib/selection/F_UPPER_BOUND.fbt
Am I right?
All reactions
-
👍 1
Yes.
All reactions
@MartinMelikMerkumians can you make an PR for your blocks?
All reactions
-
👍 1
To get here to some ToDos: If I understand you all we should remove the new versions for this types (added by @MartinMelikMerkumians) and @franz-hoepfinger-4diac adds his 4diac FORTE implementation for: https://github.com/eclipse-4diac/4diac-ide/blob/develop/data/typelibrary/iec61131-3-3.0.0/typelib/selection/F_LOWER_BOUND.fbt https://github.com/eclipse-4diac/4diac-ide/blob/develop/data/typelibrary/iec61131-3-3.0.0/typelib/selection/F_UPPER_BOUND.fbt
should be simple FBs ?
then here is the first PR: #2373