|
|
| Re: Some idea about how to implement persistence of input parameters in 4diac-forte [message #1808551 is a reply to message #1808286] |
Wed, 26 June 2019 17:27   |
|
This is an interesting use case. I like Jose's approach because it is very generic and can be applied for different things. The only thing you have to ensure is that the value in the OPC UA server is also updated so that a remote configuration tool will always see the correct value.
This brings me to another Idea which I don't know if it is possible and if it makes sense: As the for your application the main source of the config value is OPC UA should OPC UA be in charge of managing the persistence of such values? Is this foreseen in OPC UA or even possible? Or is this the wrong place for doing such things?
|
|
|
| Re: Some idea about how to implement persistence of input parameters in 4diac-forte [message #1808576 is a reply to message #1808263] |
Thu, 27 June 2019 05:42 |
 Felipe Adriano da Silva Gonçalves
Messages: 35
Registered: February 2017
Location: Brazil |
Member |
|
|
I spend some time trying understand lms_ev3 module, but due the lack of example/hardware to test the FB I could not clear understand how to use fileRead and fileWriter to figure out the persistence problem.
I think that the fileWriter and fileReader is related with some IO functionality reading a linux device (e.g. /dev/gpio) and updating IO Function Blocks. As said by Alois in the previous message the main drawback is ensure that OPC UA Variable in the server will be updated in the INIT sequence (after forte starting up again), with the values stored in some file after forte has been restart for some reason (e.g. from some error).
I also don't know if is a good idea OPC UA manage this persistence. I think that the forte.fboot and back initialization is the solution (mainly based in my experience of retain variables in IEC 61131-3, which is not managed by communication protocols*) because if the forte.fboot file is updated (internally due the information that FB Input is retentive or using a FB to write in the forte.fboot XML) the back initialization will initialize output of predecessor FB (OPC UA Subscribe) using the values of successor FBs like example bellow.
Due the back initialization the OPC-UA SUBSCRIBE Will be initialized with the values of KP, KI and KD from PID function block in the INIT sequence (OPC UA server is also updated so that a remote configuration tool will always see the correct value).
The forte.fboot file have the following lines related with this values in a kind of XML format.
EMB_RES;<Request ID="3" Action="WRITE"><Connection Source="1.9" Destination="PID.KP" /></Request>
EMB_RES;<Request ID="4" Action="WRITE"><Connection Source="2.5" Destination="PID.KI" /></Request>
If the OPC UA Variable (in subscribe FBs) already is initialized using back initialization, is not a good idea have some functionality to make PID.KP, PID.KI and PID.KD variable in PID FB as Retained variables and provide some way update the forte.fboot always that this value is changed?
Thank you for the attention to the problem.
* In IEC61131-3 RETAIN is used to indicate retentive variables, i.e. variables whose values are to be retained during a loss of power.
[Updated on: Thu, 27 June 2019 16:19] Report message to a moderator |
|
|
Powered by
FUDForum. Page generated in 1.73182 seconds
] 
Search
Help
Register
Login
Home
