get OPC Value from each Connectivity Server
I would like to see the value of a Variable from both CS OPC Server:
VariableX CS1 = value?
VariableX CS2 = value?
Im quit sure, that one of ours Controller isn't sending OPC Vaules to de Connectivity 1. But on the GUI i get the "smile".
I also didn't find solution in the a Afwapplogviewer.
Voted best answer
I assume you are using AC800M, since you mention 'smilys'.
Using (e.g.) the AdvDsOPCClient, connect to each of your connectivty servers connect to the ABB.AC800MC_OpcDaServer.3 in question.
Add an "OPC Group", "Advise" using OPC 2.0 then "Add Item" for your 'Property' using the 'Item Id' column of the 'OPC Tab' in the Control Module aspects config view.
You should be able to verify whether one of the two AC800M OPC Servers reports bad or not data. More likely, you cannot find the OPC Item in the OPC Servers address space.
Hi. What are you trying to do here? You cannot "see" both servers CS 1 & 2 if you have configured them as redundant servers. The "smiley" face is an indication that you can communicate with the controller, via either primary or redundant connections (OPC status). You can check what each server is giving you for a value by forcing a change from Primary to Redundant server.
If you have a controller not sending values on either of it's Control networks or from Primary controller to Redundant controllers, then you will have several alarms associated with these problems, either from CS1 or 2, RNRP error, or one of the controllers having a event detailing the main problem.
If you really want to see what the CS servers are seeing on their OPC servers, use a thrid party OPC client and set a scan group one for each of the CS's. The subscribe to the PV from each of the servers and compare values. This is meant for testing only and not as a substitute for proper CS redundancy in a production system.
One way is to check is by using OPC Tunneller. Use Matrikon OPC and browse your first connectivity server. Add some items and check for data quality and values. Repeat the same process for your second connectivity server.
Another method is to use Advdsopcclient as suggested in 1st comment
Yes, de second CS ist the redundant of the first one.
Theres a third Party "OPC sniffer" as a Service on both Connectivity Servers. He send the Value to a Level2 Application. If the Level2 Application doesn't get Values from one CS, he switch to the other CS.
- Level 2 took the Values from Sniffer CS2
- There was a download from a ControlBuilder
- Level 2 realized, there was a Timeout on Sniffer CS2
- Level 2 switch to the Sniffer on CS1
- Level 2 get the Values form CS1 EXCEPT from one Controller!
Now I'm trying to figure out why the OPC data from this Controller comes on CS2, and on CS1 not.
It is not possible to select what service provider (=OPC Server) to use from within a client (eg a display element). The selection is defined by affinity, or randomization if no affinity is used.
A non-smiley in the AC800 OPC Server panel shall result in a system alarm (which can be read as OPC DA by subscribing to the alarm object's Alarm Global Properties:IsAlarmActive property)
If you need to compare OPC Server 1's value with OPC Server 2's you must connect to them directly without using the regular 800xA OPC DA framework; eg via VB-code and DCOM - in PG2 you do not have this option.
By subscribing locally in a workplace running ON the OPC Server nodes themselves you will see local data (if OPC Server is up and running, healthy and connected by the OPC DA Connector service).
There exists a lesser known method to probe the different providers in a redundant service group:
Members of the IndustrialITAdmin group can enable "Edit Mode" of the AfwServiceConnectionViewer tool (launch it from the AfwTray icon in the System Tray). In Edit Mode you can click an active connection (marked with a small green arrow to the right) to disable/ignore it (icon becomes grey) and force an instant failover to next available peer.
1) You can ignore any service!
2) Think twice before blocking - you can cause "starvation" by blocking too many connections
3) All services in the local node will be affected (don't "play" with this at server nodes unless you know what you are doing)
4) Remove all blockings before leaving (or else they will remain until reboot)
5) Failover is instant, but fallback is delayed by 60 to 180 seconds for existing client connections (new will use current setting immediately).