Welcome, Guest
Username: Password: Remember me

TOPIC: OPC SERVER

OPC SERVER 5 years 4 months ago #8440

  • AutoMate
  • AutoMate's Avatar
  • OFFLINE
  • Expert Boarder
  • Posts: 130
  • Karma: 0
Hi Claes,

Welcome back and thanks for the OPC Gateway information. Regarding SOAP, my goal is not to reinvent the wheel. Proview functionality for OPC DA XML support is terrific. Several weeks ago, I started studying the SOAP XML structure and protocol to understand how it works for OPC DA XML debugging purposes.

I have been on the road for the last few weeks and had to suspend my Proview studies for awhile. However, I am very excited about a new opportunity to install Proview at a large, industrial power complex. The plan is to attach a virtual Proview machine to an existing DCS control system via OPC. The project involves coordination of multiple boilers with multiple fuels producing a million pounds of steam per hour (apologizes for those engineering units). And, coordination of three steam turbine generators producing a total of 100 MWs of electrical power. One TG is dual extraction back-pressure machine and the other two are dual extraction condensing machines. Also included is coordination of multiple pressure reducing valves, several atmospheric vents and time-of-use electrical pricing tie-line control. This is a great opportunity to demonstrate a working Proview control system in the US on a large industrial scale while saving millions of dollars per year in energy costs and reducing emissions and carbon foot-print. Proview is a replacement for our older Microsoft-based optimization controls currently installed at this location.

Over the past six months, a dozen or more custom control blocks have been built and tested in Proview to support this and other similar sites. The next hurdle is to establish a robust and reliable OPC control connection to their commercial DCS platform from a virtual Proview controller.

Thanks again for the OPC gateway information! It's too bad Kassl software is not very reliable because it runs as a service and does not require .NET framework. A few legacy control systems running Windows NT or 2000 cannot even run .NET. We tried it once and crashed a computer so badly the hard drive had to be reformatted and loaded from scratch. Then, we checked Microsoft Knowledge base that clearly states, "Don't Do it!". So, we may have to give Kassl a try anyway and debug their issues. Will keep you informed.

Regards,
/Ron
The administrator has disabled public write access.
The following user(s) said Thank You: marc

OPC SERVER 5 years 4 months ago #8466

  • AutoMate
  • AutoMate's Avatar
  • OFFLINE
  • Expert Boarder
  • Posts: 130
  • Karma: 0
Hi Claes,

Finally back to OPC debugging using open source SOAPUI tool. After some study of the OPC Foundation documentation on XML DA, several queries were built. Each query is tested on a public OPC XML DA server: advosol.com/xmldademo/ts_sim/OpcDaGateway.asmx and a local Proview OPC XML DA server attached to a test database. The Proview database also has an OPC Client connected to itself for comparison with query results from SOAPUI.

The first GetStatus request works, as expected. Below is a SOAPUI request and received response from Proview OPC XML DA Server. So far, so good:

drive.google.com/file/d/0B0SJKqcKSAEBSUp...Q1k/view?usp=sharing



Next, a general root browse request was made to Proview. Trouble: INVALIDCONTINUATIONPOINT. "The filter string is not valid".

drive.google.com/file/d/0B0SJKqcKSAEBUzM...OFk/view?usp=sharing



As a comparison test, the same Browse query was made to the public OPC XML DA server. The results are as expected, as shown below:

drive.google.com/file/d/0B0SJKqcKSAEBZGd...am8/view?usp=sharing




Do you have any comments, suggestions or pointers on source code searches? I've just started digging into the folders found under pwrsrc_5.4.0-2/opc.

Regards,
/Ron
Last Edit: 5 years 4 months ago by AutoMate. Reason: Attached picture links to Google Drive
The administrator has disabled public write access.

OPC SERVER 5 years 4 months ago #8468

  • claes
  • claes's Avatar
  • OFFLINE
  • Platinum Boarder
  • Posts: 2915
  • Thank you received: 422
  • Karma: 124
Hi Ron,

You will find the OPC server code in opc/exe/opc_server/src/opc_server.cpp.

The INVALIDCONTINUATIONPOINT is returned on line 1529.

I guess the test on line 1516

if ( s0__Browse->ContinuationPoint)

should be not only if the ContnuationPoint tag is present, but also that it's not a null-string

if ( s0__Browse->ContinuationPoint && !s0__Browse->ContinuationPoint.empty())

/Claes
Last Edit: 5 years 4 months ago by claes.
The administrator has disabled public write access.
The following user(s) said Thank You: AutoMate

OPC SERVER 5 years 3 months ago #8472

  • AutoMate
  • AutoMate's Avatar
  • OFFLINE
  • Expert Boarder
  • Posts: 130
  • Karma: 0
Hi Claes,

Your response was very helpful. By simply removing ContinuationPoint from the XML request, Proview responded correctly. This example makes me very aware of how difficult it is to cover every possible query combination and that the OPC Foundation specifications are loose enough to be open to a fair amount of interpretation by various vendors. This leads to the idea of using OPC Foundation verification tools to test for sanctioned, OPC Foundation, certified compliance. Years ago, we joined the OPC Foundation for one-year to gain access to source and compliance testing software. I will be digging through my archives to find those compliance testing tools.

My immediate focus is to connect to a specific industrial OPC DA server and test performance and throughput. Extensive testing is needed before connecting to a live system. For testing purposes, I have a trial version of Kassl XGate translation software running against a trial version of Northern Dynamics OPC DA server in an older Microsoft machine. In Proview, an OPC Client is connected to Kassl's XGate OPC XML DA Server. Proview successfully connects, browses and displays various information. The issue is that sometimes it works and sometimes it either doesn't work well or not at all. My goal is to find out why...

To determine the reasons, WireShark is used to analyse XML transactions between Proview OPC client and Kassl OPC XML DA server. Wireshark is also used to analyse communications between Proview OPC Client and various public OPC XML DA servers. This has been a very successful and revealing technique that has exposed numerous communication issues. However, because of variations and inconsistencies from server to server, it is difficult to pin-point if root causes are due to OPC compliance issues between various OPC servers. Since I've never seen an industrial OPC server use item names with spaces, all OPC servers with name spaces are ruled out for testing purposes. In industrial practice, there is no reason to support space-laden item names, so the State 12 error is solved by elimination.

Communication analysis has also been conducted between a Proview OPC Client connected to a separate Proview OPC server to review compatibility between it's own client and server. Surprisingly, a few transaction issues were uncovered. To dismiss any network communication issues these machines are now connected with short Cat5e cables through a hard-wired switch instead of via a WIFI router. Tests are on-going with the goal of determining exact transaction problems and finally to review Proview code for possible solutions.

For your review, the following WireShark transaction display is presented.

Subscribe query comparison: bad versus good
drive.google.com/open?id=0B0SJKqcKSAEBUmh5b0tvblItSDQ

Response from bad subscribe query: name contained an invalid character:
drive.google.com/open?id=0B0SJKqcKSAEBTkRPejB4dklVSHM

This is a transaction issue seen consistently enough to report. It usually occurs during Proview start-up, after GetStatus and all Browse and GetProperty queries are completed successfully. From xtt, opening an OPC Client object causes Proview to issue a Subscribe command. WireShark interprets Proview Client's subscribe query as Unrecognized Text, even though the command is clearly readable in the hex code. (see left side Bad Scuscribe Request).

When connected to a Proview OPC Server, this subscribe command is interpreted correctly. It's interesting that WireShark's XML decoder can't read it correctly. Also, Kassl's XGate server cannot read it either and always returns an error.

If an error is returned, Proview sends another Subscribe command that is then read correctly by WireShark and Kassl. A hex character comparison between the two subscribe commands (bad and good) are identical. The only difference found is the bad request specifies ReturnValuesOnReply> versus the good request specifies ReturnValueOnReply="false">. For some reason, both WireShark and Kassl are confused without the =false> included in the directive?

Regards,
Ron
Last Edit: 5 years 3 months ago by AutoMate. Reason: More info
The administrator has disabled public write access.
The following user(s) said Thank You: marc

OPC SERVER 5 years 3 months ago #8475

  • claes
  • claes's Avatar
  • OFFLINE
  • Platinum Boarder
  • Posts: 2915
  • Thank you received: 422
  • Karma: 124
Hi Ron,

ReturnValuesOnReply is a boolean and should be "true" or "false". In this case it's not set in the Proview code and should default to "false". The value is written in opc/lib/opc/src/opc_soap_C.cpp on line 5812. This is code autogenerated by gsoap, and I have hard to understand how it can not be "false". I have to run this in debug to see what is happening.

/Claes
The administrator has disabled public write access.
The following user(s) said Thank You: AutoMate

OPC SERVER 5 years 3 months ago #8476

  • AutoMate
  • AutoMate's Avatar
  • OFFLINE
  • Expert Boarder
  • Posts: 130
  • Karma: 0
Hi Claes,

Thanks for taking the time to looking into this OPC client Subscribe issue. Quite a few more experiments have been performed to confirm the following:

1) Subscribe issue is the same on both a development station or runtime.

2) A Subscribe error can be invoked consistently by starting Proview project or runtime. Then,

3) From xtt, open opc client object. By opening an object, a bad subscribe request. A good subscribe is never issued when manually opening objects in xtt.

4) Opening an Object Graph causes a good Subscribe, but the same same Subscribe is requested two or three times in a row for the same item name. After each redundant request, a SubscribeResponse is received with a separate ServerSubHandle assigned to each request. Frequently, the same Itemname is assigned three ServerSubHandles. (One may argue a smarter OPC server would not assign multiple SubHandles to the same object. But another may argue a smarter OPC Client wouldn't Subscribe multiple times to the same Item name.)

5) During object graph trending, a SubscriptionPolledRefresh command is issued each interval as expected, except each of the three ServerSubHandles for the same Item Name are asked per request.

6) A SubscriptionPolledRefreshResponse returns the same value for each SubscriptionHandle.

7) Externally, the Object Graph appears to update properly, but the same data is returned multiple times.

Over the weekend, I dug through the source code and did find the code you referenced. I don't completely understand all of the coding details. Quite a lot of study is required. It is interesting to know this code is self-generated via gsoap. Does that imply there may be a slight error in the opc.wsdl specification file?

Ron
The administrator has disabled public write access.
Time to create page: 1.303 seconds