We really want to use Proview as the main scada for an application at our University (NTNU, Trondheim), and to be able to do so we need a working Opc Client. While trying to change opc_provider.cpp to fit our needs, a few questions has arisen. This will most likely be the first of many post regarding the proview opc implementation...

1) Would anybody else be interested in a working opc_client

2) Code spesific questions: (where to start...)

Our first goal is to have the OpcServerState-object correctly configured. As of now this turns up as a leaf-node with no properties other than a strange _O0.0.250.9:....
opc_provider.cpp:main():
provider.get_server_state(); this function runs and returns server-info from the actual opc-server, but somehow this does not turn up in the browser. Anybody got clues why not?

Are there any documentation on the procom ? (As this module does not use qbus, I guess that procom communicates with the rt?

3) Any other comments to shed some light on this implementation would be greatly appreciated.

Have a nice day!
Bernt

Hi Bernt,

The status object problem is probably because the Opc class volume is not loaded. All the opc objects are placed in a specific class volume named Opc and only classvolumes that have an instance object in the database are loaded by default. So you can either create a dummy object, for example an Opc_Float, somewhere in the database, or you can add a ClassVolumeLoad object named Opc in the directory volume under the NodeConfig object.

There is no documentation about procom. The source is found in
src/lib/rt/src/rt_procom.cpp but I don't think you have to dig to much into it. If I would try to give a short explanation you could say that a provider simulates a Proview volume in a remote node. When mounting an remote volume the information about this volume and its objects is transferred by the nethandler process (rt_neth). The protocol contains a number of different message types to get info about object parents, siblings and children, to read and write attribute values etc, thus making it possible to show these remote objects as if they were present on the local node. Procom also implements the nethandler protocol and presents external data as if it was a Proview volume with an object tree and Proview objects, even if the data originally can have an entirely different structure. The messages are defined in src/lib/rt/src/rt_net.x. When you for example set an attribute value from rt_xtt a message of type SetObjectInfo is sent from xtt to the provider. The OPC provider sends an OPC write request, and returns a SetObjectInfoR with a status when the OPC response is received.

/Claes

Thank You very much for your quick reply.
We are two students working full time on this scada implementation, so all help is appreciated.

By adding a dummy variable we got the ServerStatus object, and the other nodes finally showed as Opc_Hier (progress from O0.0.0...). We had actually done what you suggested (found in another tread) and added a volumeload-object, but we thought that it should be named similar to the mountobject, so that was why our opc-class was not loaded.

Now we are finally able to read values from one of the two opc-xml-servers. But the following is a problem:

1) While using GE to read values we get this error: ** GetValue: Suspicious format "" (testPlant-VolOpc-maths-sin.Value##Float32)

2)
One of our servers does not return values on the getProperties request, the datatype value is always xsd:unknown. The only way to get the datatype is to look at the data-type-name in the value when doing a read request. As we can understand from the opc-xml-spec this is legal. How could we overcome this problem in the Proview implementation? Is is possible to set the datatype manually for all the tags, or could one implement a read function that provides the datatype?

A jolly good weekend to you all!
Bernt

Hi Bernt,

1) You have to set a float format in the Ge field, eg "%6.2f".

2) Today there are no configuration at all of the tags in the development environment, so if you want to configure the type you have to invent something. The easiest would be a text file with tag name and type. But I think the best would be to always make a read request if the type is unknown.

/Claes

Hi Claes!

We have now gotten browsing to work with the Proview OPC client. When we add our OPC XML DA server we can see all the tags, with the correct datatype set, also the ServerStatus object is now properly populated. However, we have run into another problem regarding the Subscription of variables. The Proview OPC client does not set the field "SubscriptionPingRate" in the subscription request sent to the server. As far as we can see, this is a required attribute according to the OPC XML-DA Spec. Leaving this attribute unset, causes the server to clean all resources associated with the Proview OPC client, and this again causes the following error:

Now, we think we found the solution in the file opc.wsdl where the default value of "SubscriptionPingRate" can be set. We modified this file by setting:and then ran the following commands:
The problem occurs when we try to compile the OPC module using "pwre". When launching the commands:

we get a number of errors from the build of opc_soap_C.cpp, which mostly complain about the macro "SOAP_NEW" not being declared in this scope.

Are there some step we are missing, or are there any other ways to set the attribute "SubscriptionPingRate"? Any help regarding this problem would be greatly appreciated!

- Bernt

Hi Bernt,

The files opc/lib/opc/src/stdsoap2.cpp and .h are copies from the gsoap release, and now when you generate code from a newer gsoap version you probably have to update these files from the source of the current gsoap.

/Claes