dpSet to a powered down device blocks other comms on OPC UA driver

Discussion about recent product features & solutions!
Search

Post Reply
4 posts • Page 1 of 1
tpjctrl
Posts: 49
Joined: Tue May 08, 2018 8:30 am

dpSet to a powered down device blocks other comms on OPC UA driver

Post by tpjctrl » Wed Dec 04, 2019 12:11 pm

I've got a OPC UA driver which is responsible for around 200 signals coming from / going to OPC KepServer which is connected to a PLC pair - PLCA and PLCB. Majority of those signals are being read by WinCC OA, there's around 10-20% which are being sent, but those are triggered by button clicks, so without any user interaction those are not sent out. There's two signals which are SCADA rolling counters, those are sent every second into both PLCA and PLCB. There's also rolling counters read from the PLCs, as long as those are changing, WinCC OA sends it's own rolling counter back to the PLCs. The mechanism for sending those is really simple:

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?

User avatar
leoknipp
Posts: 2031
Joined: Tue Aug 24, 2010 5:28 pm

Re: dpSet to a powered down device blocks other comms on OPC UA driver

Post by leoknipp » Thu Dec 05, 2019 8:04 am

The Event Manager does not have any information if the connection to a PLC is down or not. Also the polling mechanism is part of the driver and not of the Event Manager.
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.

Best Regards
Leopold Knipp
Senior Support Specialist

tpjctrl
Posts: 49
Joined: Tue May 08, 2018 8:30 am

Re: dpSet to a powered down device blocks other comms on OPC UA driver

Post by tpjctrl » Thu Dec 05, 2019 1:02 pm

Thanks for the info Leopold.

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

User avatar
leoknipp
Posts: 2031
Joined: Tue Aug 24, 2010 5:28 pm

Re: dpSet to a powered down device blocks other comms on OPC UA driver

Post by leoknipp » Wed Dec 11, 2019 2:00 pm

In your case when using a OPC UA connection the OPC UA server has the connection to the PLCs.
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.

Best Regards
Leopold Knipp
Senior Support Specialist

Post Reply
4 posts • Page 1 of 1