|
| Re: OPC_UA Subscribe FB Var Initialization [message #1767478 is a reply to message #1767436] |
Thu, 06 July 2017 10:18   |
|
hi,
this is an interesting problem you are pointing out here. I think I don't have a quick solution for you. But I also think that we need to provide you with a solution for that. One of the problems I see is that setting a default value on the RD_x outputs is maybe not the thin you would like to have. the problem is that even if you could set here a default value it would not come to your FB as this would require an event and this is not happening.
Therefore I would propose a different solution:
1. specifiy the default value on the input of your FB, either as default value in your FB type, or as parameter value in the application
2. on initionalisation this value is mirrored back to the RD_ output into the opc UA server
In order that this is working we would need to change a bit in the download process for supporting the second part of 1 and a change in the OPC UA layer. Although I think the latter should be pretty straight forward.
What do you think?
|
|
|
|
| Re: OPC_UA Subscribe FB Var Initialization [message #1767516 is a reply to message #1767492] |
Thu, 06 July 2017 17:06 |
|
Jose this is an excelent quick solutionfor Felipe's issue.
However I would still like come back to my proposal from above. As you can see in the attached screenshots it would eliminate quite some FBs. The only problem is that currently in 4diac we only write constants during deployment when they are not connected and we don't show them when there is a connection. Espcially changin the deployment would just mean to remove an if. However I wanted to get feedback from other 4diac users and IEC 61499 experts if they see an issue when we change the behavior?
P.S.: Changing the behavior would have also an aditional benefit that it would be very easy to set a type of an any input and we wouldn't need these int2int blocks like you used them in your example. Insteady write the constant INT#0 on the input of the FB_SEL.
|
|
|
| Re: OPC_UA Subscribe FB Var Initialization [message #1767517 is a reply to message #1767492] |
Thu, 06 July 2017 17:07 |
|
Jose this is an excelent quick solutionfor Felipe's issue.
However I would still like come back to my proposal from above. As you can see in the attached screenshots it would eliminate quite some FBs. The only problem is that currently in 4diac we only write constants during deployment when they are not connected and we don't show them when there is a connection. Espcially changin the deployment would just mean to remove an if. However I wanted to get feedback from other 4diac users and IEC 61499 experts if they see an issue when we change the behavior?
P.S.: Changing the behavior would have also an aditional benefit that it would be very easy to set a type of an any input and we wouldn't need these int2int blocks like you used them in your example. Insteady write the constant INT#0 on the input of the FB_SEL.
|
|
|
|
|
|
| Re: OPC_UA Subscribe FB Var Initialization [message #1767881 is a reply to message #1767773] |
Tue, 11 July 2017 20:34 |
|
I've spent some time with the standard and 4diac code. As far as I can see there is nothing in the standard that would prohibit to have a parameter and a connection on a data input of a FB instance. However I will also ask the IEC 61499 experts in the standardization working group to get further feedback.
Furthermore I noticed that if you would out a default value on your PIDs input (e.g., type default value), which would anyhow be a good design pattern for parameters that shouldn't be zero (e.g., Kp or Tr), on the creation of the connection the value would be automatically back-propagated to the RD_x output of the SUBSCRIBE FB. The reason for that is that the RD_x output is of type any and on creation of the connection the RD_x output will get its type from the other end of the connection. During this process currently not only the type but also the value is propagated. so for my point 2. above we only need to use RD_x's value and apply it to the OPC UA servers value.
Regarding the point Jose was mentioning with just removing a simple if in the IDE we can show the value and the connection on an FB input (see the attached screenshot). Although it is graphically not very nice it would work for experiments.
Therefore my proposal would be that we implement my suggestion in the current development branch so that if you agree Felipe can give it a try. With that we can get more experience on the usability and suitability of this approach.
What do you think?
|
|
|
| Re: OPC_UA Subscribe FB Var Initialization [message #1767960 is a reply to message #1767881] |
Wed, 12 July 2017 12:10 |
 Martin Melik Merkumians
Messages: 117
Registered: March 2016 |
Senior Member |
|
|
Hi all!
Your problem sounds like you would need some kind of MVC pattern in FORTE. Although Alois approach would definitely work, I am not sure if the behavior will be comprehensible and uniform for all different situations with this back-propagating mechanism.
Perhaps we should give a thought on how a clean MVC could be implemented in FORTE, which provides a clean separation of all three components and a comprehensible and uniform interface.
Best regards,
Martin
[Updated on: Wed, 12 July 2017 12:10] Report message to a moderator |
|
|
|
| Re: OPC_UA Subscribe FB Var Initialization [message #1768546 is a reply to message #1768202] |
Wed, 19 July 2017 20:50 |
|
I would like to add to Stefan's post that this is need so that there is a consistency between the values in IEC 61499 model and in OPC UA.
The question to Martin is then what would be the model. I would see it in the information model of OPC UA and the HMI as well as the 1499 application acts as View/Observer or Controller. The way how we are currently creating this model is that we are partly reflecting the IEC 61499 model. This has the advantage that it can be done rather quick and does not need to much FBs. But may not be to sufficient for bigger applications. But I guess with have to make more experience to say that.
|
|
|
|
|
| Re: OPC_UA Subscribe FB Var Initialization [message #1768975 is a reply to message #1768919] |
Tue, 25 July 2017 10:35 |
|
The initialization on OPC UA side has been implemented. However currently 4diac-ide is not downloading the paramters yet. As written above I wanted to confirm with the IC 61499 standardization working group before implementing it. At this was a good decision. We had some discussion if it is allowed, should be allowed and how to implement it, with the result that we should allow it. For this two changes are required in 4diac-ide (see Bugs [1] & [2]).
However till this is fixed it should be possible that you test this already by specifying initial values for the respective data inputs in your FB Type. As I pointed out above this is anyhow a good practice to do this for critical values like Kp or Ti. Also if the default initial values are chosen well it may even reduce the configuration burden for the user of your FB.
[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=520137
[2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=520136
|
|
|
|
| Re: OPC_UA Subscribe FB Var Initialization [message #1769090 is a reply to message #1769041] |
Wed, 26 July 2017 12:38 |
|
The problem is that that the value is only written back the first time the connection is created. Therefore you would need to set the value and then create the connection. 4diac has for this a feature where you can online create connections and FBs. but this is rather clumsy to use. Especially in your setup. As pointed out already three times above. You should give initial values in your FB Type. I see this as crucial for a good FB like yours.
In addition I did a quick fix in the ide to implemented the the features which I have pointed above with the bug reports. Unfortunately I do not have time for testing today. So please use them with caution and let us know if you experience any issues.
BTW: you can also subscribe to 4diac's bugzilla to get informed about new bugs and changes to bugs via email. The description can be found in 4diac's developers mailing list.
|
|
|
Powered by
FUDForum. Page generated in 0.04383 seconds
] 
Search
Help
Register
Login
Home
