dpSet to a powered down device blocks other comms on OPC UA driver
if (current PLC rolling counter != last value of PLC rolling counter) then send the SCADA rolling counter to the PLC
With both PLCA and PLCB running, everything works fine, problems happen when for example PLCA is powered down. The above mechanism tries to send the rolling counter to PLCA (via a dpSet), a device which isn't available, and whilst it's trying to achieve this, the rolling counter to PLCB also stops. I'm guessing this is due to the fact that all the data read from that "dead" PLC is being polled and ever single point fails as the device isn't available. What is strange though is that there doesn't seem to be a timeout, the driver will keep trying forever, blocking all other signals sent on that driver. I've tried to get around this by creating two separate drivers for each of the SCADA rolling counters (nothing else is using those drivers), but a similar thing happens, the driver for SCADA rolling counter to PLCB gets delayed, but this time it's not indefinite, it's for around 7-8sec. Again I think it's due to the Event Manager (?) being busy trying to process all the data polling to PLCA, which fails and timesout eventually.
So my question is, how does one handle a scenario like a power down of a device? Should separate drivers be created for PLCA and PLCB, with a control script running monitoring the connection to both and the disabling the "dead" device driver, so that it doesn't affect other comms?
Independent from the PLC connection state the Event Manager sends the signal to the driver if a dpSet() for a dp element with an output address is made.
With the debug flags "-snd 2 -rcv 2" (full output of processed messages) or "-snd 1 -rcv 1" (only header information) you can check when messages are send/received.
Probably with this information you can see where the delay in processing the signal occurs.
Senior Support Specialist
Am I correct to think that if I have for example 10 output signals on a single driver and the connection for one of them fails, doing a dpSet for that particular signal stops all the other 9 signals completely? Cause this seems to be happening to my two signals, if a dpSet is done on the one which lost comms, the other one stops being set as well ie. never reaches the PLC. Here's the scenario:
- two output signals, integers / rolling counters incremented by WinCC OA, one goes to PLCA and the other to PLCB
- both using the same UPC OA driver, both being written using a dpSet within a control script
- with both PLCs powered up I can see the counters incrementing in the PLCs
- if I power down PLCA, the counter in PLCB stops incrementing
The WinCC OA OPC UA client only has a communication to the OPC UA server.
Even if the OPC UA server has lost a connection to one or several PLCs the communication between the WinCC OA OPC UA client and the OPC UA server shall not be affected.
As written in the previous answer you have to check if
-- The CTRL script is still doing the dpSet calls
-- The OPC UA client receives the value changes
-- The OPC UA client sends the information to the OPC UA server
Probably the problem is related to the OPC UA server and not to WinCC OA.
Senior Support Specialist