|
|
|
|
|
|
|
|
|
|
|
|
|
|
Re: Write and Read OPC_UA Variables in the same server [message #1784213 is a reply to message #1784203] |
Fri, 23 March 2018 14:31 |
Jose Maria Jesus Cabral Lassalle Messages: 199 Registered: February 2016 |
Senior Member |
|
|
Oh I see what you're doing now. With the WRITE_INCREMENT you are accesing the absolut path of the variable from SUBSCRIBE_1. I'm not sure about this, but when you use a publish in your local server, it creates or tries to get the variables from the localserver using the ID plus the name and data input/output of the connected FB, like SUBSCRIBE_1 (which uses increment/IN). But if you specify an endpoint (like you did in localhost:4840) it doesn't try to create the variables but only to get them, in your case, it works, since it retrieves the varaible from the server at localhost:4840 (the forte server).
Now, if you don't use localhost:4840, as said it will try to get or create the variable. In your case it looks for Objects/incrementer/IN/NumToIncrement/OUT (since it uses the connected FB). I think the problems lies here because Objects/incrementer/IN is already a variable and it will try to create another variable in it.
I'd say to use the localhost:4840 trick for now, but also suggest to specify in the ID of the opc_ua somehow to specify that the parameter is a absolut path and don't use the connected FB (maybe just for the type but not for the name). This will need some opinion from Stepahn
|
|
|
Re: Write and Read OPC_UA Variables in the same server [message #1784235 is a reply to message #1784213] |
Fri, 23 March 2018 23:54 |
Felipe Adriano da Silva Gonçalves Messages: 35 Registered: February 2017 Location: Brazil |
Member |
|
|
Exactly Jose Maria,
I don't now again if this broke some principle of IEC 61499.
The idea of example is provide a way to the client (from HMI for example) write in some variable inside the application, running in the device througth opc_ua, but also to allow the own application write in this variable in some way.
See this example. The server internally create a Integer variable but it can internally (without additional connection) write in the created variable (see the function writeVariable).
This is so useful when some parameter can be alternated in the run time environment (PLC) by the operator thought an HMI (that is opc_ua client), but this variable under certain conditions can be modified internally by the application logic running in the PLC and in same time this value need to be updated in the HMI.
Thank for your attention.
[Updated on: Fri, 23 March 2018 23:58] Report message to a moderator
|
|
|
Re: Write and Read OPC_UA Variables in the same server [message #1784245 is a reply to message #1784235] |
Sat, 24 March 2018 13:00 |
|
No I don't think this breaks some principles of IEC 61499. The problem I see is that our current OPC UA interface is not suited to this use case. Interestingly we already started discussing that we need to expand/change the way how we represent OPC UA in IEC 61499 FBs. Not only because of your use case but with the upcoming pub/sub support, which is very interesting for 4diac we also need to find ways to represent that.
I proposal that I got inspired by your question/problems is the following:
- use the publish subscribes FBs solely for the OPC UA's pub sub mechanism
- for variable access introduce a new FB, which would allow use-cases like yours. I've attached a quick and dirty mock-up of such an FB:
What are your opinions on this?
[Updated on: Sat, 24 March 2018 13:01] Report message to a moderator
|
|
|
|
Re: Write and Read OPC_UA Variables in the same server [message #1784611 is a reply to message #1784250] |
Fri, 30 March 2018 11:19 |
|
If you need a inital value strongly depends on who is the master of your hmi data and how you system should be have when no UA client is connected. For many systems I understand that on startup some reasonable values should be present so that the system operates in a save mode. These values should be presented to the HMI and be tunabel by the HMI. In such cases an inital value is needed. However it could also be part of the config string.
Params would be anything needed to create the right node in the information model with as little configuration effort as possible.
|
|
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.05024 seconds