Home » Eclipse Projects » 4DIAC - Framework for Distributed Industrial Automation and Control » OPC READ question
| OPC READ question [message #1816980] |
Wed, 13 November 2019 10:19  |
 Mariusz Balon
Messages: 11
Registered: July 2019 |
Junior Member |
|
|
Hi All,
We have been working on creating some function block to interact with a remote OPC_UA server. The example below shows inputs on the left and output on the right hand side. It is implemented by using an E_CYCLE event to drive clock timer (this is on the EMB_RES page), which clocks the OPC_UA READs for the inputs and WRITEs for the outputs.
As an example, IN_I4R, is a 4 input Integer (16 bit), The ID1 gets mapped to a OPC_UA string used for in the CLIENT_0_1 with a ID like this: opc_ua[READ;opc.tcp://opcserver:4840#;,1:s=VAR.ROV_TIMEOUT]. The output function blocks uses the CLIENT_1_0 with an ID opc_ua[WRITE;opc.tcp://opcserver:4840#;,1:s=VAR.V01_OPEN_TGT].
The detail behind the IN_I_R4 function block is as below:
The logic is started as follows:
We have been running a number of tests, and depending on the E_CYCLE time we are able force an ERROR on the OPC side, which halts the execution of the function blocks.
The error message is as below:
ERROR: T#2238025426562556: External event queue is full, external event dropped!
ERROR: T#2238025476186537: External event queue is full, external event dropped!
ERROR: T#2238025525995700: External event queue is full, external event dropped!
ERROR: T#2238025576552918: External event queue is full, external event dropped!
ERROR: T#2238025626205658: External event queue is full, external event dropped!
ERROR: T#2238025676023760: External event queue is full, external event dropped!
ERROR: T#2238025726143467: External event queue is full, external event dropped!
ERROR: T#2238025775948851: External event queue is full, external event dropped!
ERROR: T#2238025826754605: External event queue is full, external event dropped!
ERROR: T#2238025876478113: External event queue is full, external event dropped!
ERROR: T#2238025926494999: External event queue is full, external event dropped!
ERROR: T#2238025976312135: External event queue is full, external event dropped!
ERROR: T#2238026026007815: External event queue is full, external event dropped!
ERROR: T#2238026075956888: External event queue is full, external event dropped!
ERROR: T#2238026126076168: External event queue is full, external event dropped!
ERROR: T#2238026175973393: External event queue is full, external event dropped!
ERROR: T#2238026226864769: External event queue is full, external event dropped!
ERROR: T#2238026275879642: External event queue is full, external event dropped!
ERROR: T#2238026326850251: External event queue is full, external event dropped!
ERROR: T#2238026376536168: External event queue is full, external event dropped!
ERROR: T#2238026426437297: External event queue is full, external event dropped!
ERROR: T#2238026476747651: External event queue is full, external event dropped!
ERROR: T#2238026525923038: External event queue is full, external event dropped!
It would appear that triggering the REQ too fast can cause the event to be dropped, and it doesn't seem to ever recover and thus the entire program halts as we cannot READ or WRITE to / from the external OPC_UA server. We have of cause been pushing the system by setting the the DT to 50ms, however, we would expect a deterministic outcome regardless of the cycle time.
Questions:
1. Are we doing something incorrect, or is there a workaround?
2. Is there a deterministic way of setting the maximum cycle time for the CLIENT_x_x?
3. Is additional error handling needed to better manage the external event queue?
As a note, we have tried using the SUBSCRIBE, to make the logic more event driven on change, but currently have decided against it.
|
|
|
| Re: OPC READ question [message #1816985 is a reply to message #1816980] |
Wed, 13 November 2019 12:08  |
Jose Maria Jesus Cabral Lassalle
Messages: 199
Registered: February 2016 |
Senior Member |
|
|
Hi,
The external queue full means that you are creating external events (in this case from E_CYCLE) faster than forte can process them, so you need to reduce this processing time
Some thoughts about this:
1- VAR_PATH_OPC_READ_2 has an empty input and is not actually reading anything. Remove it if not used, or skip the CNF triggering
2- Maybe, and I'm not sure about this, but maybe it's better to not have 2 events coming out of CNF, but just to the next CLIENT and then to the int2int and follow the change with the rest of the int2int similarly
3- You could use a CLIENT_0_4 to pack all READ in one, making only call to the OPC UA stack instead of 4 of them. I think that'll help a lot.
But to have a deterministitc behaviour you should start looking into real time systems I think. I know there are some FBs for it, but @Alois could give more information about it, since he used them a while ago.
|
|
|
Goto Forum:
Current Time: Thu Sep 19 02:38:20 GMT 2024
Powered by FUDForum. Page generated in 0.03704 seconds |
] 
Search
Help
Register
Login
Home
