cancel
Showing results for 
Search instead for 
Did you mean: 
Read only

Unexpected results from PCo tag retrieve query

Former Member
0 Likes
630

I am getting an unexpected response when doing a standard PCo Tag Retrieve Query.

I am retrieving current values from an OPC data source. The correct values are coming in, but they are not coming in all in the same row of the results. Every column of results has a value, but they are split across different rows.

See attached screenshot.

I just asked for the current values of all tags; why wouldn't they all be in the same row?

Is this a problem with PCo? Is there a solution, or do I have no choice but to code around this?

I have:
MII 12.2.3 Build(179) on a Linux server
which connects to
PCo 2.2 (2.203.1190.245 Patch level 32692) on a Windows 2008 server
which connects to
FactoryTalk Gateway, an OPC DA server (OPC-DA 2.05a) running on the same Windows 2008 server

Thanks in advance,

Greg

Accepted Solutions (0)

Answers (1)

Answers (1)

jcgood25
Active Contributor
0 Likes

I would expect each tag to be in its own Rowset, not a single Row.  Each tag could have a different timestamp for when the 'current' value was last updated, and in a single row they would have the same timestamp, which could be quite misleading.

Your screen capture shows a single rowset - perhaps testing it in xml would help see the format better than the panel in the WB.

I'm not sure why tag retrieve should work differently than the same behavior in a Current tag query.

IntegrationCPI
Participant
0 Likes

Hi Gregory ,Jeremy,

I am new to PCO , need your help in fixing my issue  http://scn.sap.com/thread/3259330 . And also like to know how the PCO query logic works .

Thanks

Kishore K V

Former Member
0 Likes

Attached is a screenshot of the XML for the same query. The XML is no surprise considering the appearance of the table. One rowset as you say, with multiple rows for no reason I can understand.

Former Member
0 Likes

Hi Gregory,

Please stop the PCo Agent Instance and change the Logging Mode to Verbose.  Start the Agent, execute the tag query from MII and check the PCo log to see what command is sent to PCo, and post that. 

It appears that you are connecting to a ControlLogix PLC to read the tag data through FactoryTalk gateway, is this correct? If not, please indicate what the source system is that the FactoryTalk Gateway is providing the OPC Server connection to.

Regards, Steve

Former Member
0 Likes

Yes, it is a ControlLogix PLC.

I will try the verbose logging over the weekend and report back when I have the info. It will be both safer and easier to do this when no one else is using PCo.

Greg

Former Member
0 Likes

Here is the log for the query shown above:

11/2/2012|1:41:53 PM|137|.|14|63400|FTGatewayAgent|Verbose|OpcDaAgent|Retrieve for Tag clx/Online/_1084_q/upm [[clx]_1084_q.upm] succeeded.|""

11/2/2012|1:41:53 PM|137|.|14|63400|FTGatewayAgent|Verbose|OpcDaAgent|Retrieve for Tag clx/Online/_1084_q/reset_timestamp/Microsecond [[clx]_1084_q.reset_timestamp.MicroSecond] succeeded.|""

11/2/2012|1:41:53 PM|137|.|14|63400|FTGatewayAgent|Verbose|OpcDaAgent|Retrieve for Tag clx/Online/_1084_q/goodcount_status [[clx]_1084_q.goodcount_status] succeeded.|""

11/2/2012|1:41:53 PM|137|.|14|63400|FTGatewayAgent|Verbose|OpcDaAgent|Retrieve for Tag clx/Online/_1084_q/run_status [[clx]_1084_q.run_status] succeeded.|""

11/2/2012|1:41:53 PM|137|.|14|63400|FTGatewayAgent|Verbose|OpcDaAgent|Retrieve for Tag clx/Online/_1084_q/net_count/ACC [[clx]_1084_q.net_count.ACC] succeeded.|""

11/2/2012|1:41:53 PM|137|.|14|63400|FTGatewayAgent|Verbose|OpcDaAgent|Retrieve for Tag clx/Online/_1084_q/gross_count/ACC [[clx]_1084_q.gross_count.ACC] succeeded.|""

11/2/2012|1:41:53 PM|100|.|14|63400|FTGatewayAgent|Verbose|PCoQueryRequestHandler|Raw request string: [MII   <?xml version="1.0" encoding="UTF-8" standalone="no"?><pco:request xmlns:pco="uri:sap-pco-request" pco:version="1.0"><pco:tag><![CDATA[RETRIEVE 'clx/Online/_1084_q/gross_count/ACC' RENAME 'gross_count','clx/Online/_1084_q/net_co|""

11/2/2012|1:41:53 PM|100|.|14|63400|FTGatewayAgent|Verbose|OpcDaAgent|Retrieve Tag Query recieved for 6 items.|""

11/2/2012|1:41:53 PM|100|.|14|63400|FTGatewayAgent|Information|AgentBase|Tag Query:  RETRIEVE 'clx/Online/_1084_q/gross_count/ACC' RENAME 'gross_count','clx/Online/_1084_q/net_count/ACC' RENAME 'net_count','clx/Online/_1084_q/run_status' RENAME 'run_status','clx/Online/_1084_q/goodcount_status' RENAME 'goodcount_status','clx/O|""

11/2/2012|1:41:53 PM|100|.|14|63400|FTGatewayAgent|Information|AgentBase|Query:  <pco:tag xmlns:pco="uri:sap-pco-request"><![CDATA[RETRIEVE 'clx/Online/_1084_q/gross_count/ACC' RENAME 'gross_count','clx/Online/_1084_q/net_count/ACC' RENAME 'net_count','clx/Online/_1084_q/run_status' RENAME 'run_status','clx/Online/_1084_q/good|""

Former Member
0 Likes

Gregory,

it appears that the valiues are being returned from the OPC Server with separate and different time stamps.  can you re-run the MII query and expand the timestamp field to see if there are mSec differences in each row? 

What are the settings for PCo Source Agent and Agent Instance? Are you using Demand, Cache, or Alias for the Agent Instance Tag Query mode?

Regards, Steve

Former Member
0 Likes

I don't think I can expand the timestamp field or make it more accurate. When I look at the raw XML (as shown above), it is coming in with hours, minutes, and seconds, but no microseconds or such.

For my source system, I have the settings below. Thank you for pointing my attention to this. The "group settings" especially look worth looking into. Is there documentation on the meaning of "update rate" and "time difference"? It looks like I need to adjust the time difference, and I will try that tomorrow. Would appreciate any suggestions on a good value for these.

The cache mode of the agent instance is "demand." Do you think this might need to be changed?

SOURCE SYSTEM:

Server:
Name: FTGateway
Machine: localhost
OPC Servers Available on: localhost
OPC Server Description: FactoryTalk Gateway
Specification: DA 2.05A
Program ID: FactoryTalk Gateway

Settings - OPC DA Settings:
Acquisition Mode: Synchronous
Force Flat Namespace: False
Synchronous Read Source: Device
Acceptable Data Quality: Good
Activate Items: Good

Settings - Group Settings:
Name: Subscription Group
Update Rate: 00:00:01.000
Time Difference: 00:00:00.000
Deadband: 0.0%

Aliases:
Nothing

Reliable Connection:
Max Number of Tries: 3
Retry Interval: 30 s

AGENT INSTANCE:

Tag Query:
Cache mode: Demand
Mask: [none]
Alias: [none]
[Am not seeing other settings on the agent instance that look relevant, but could provide more info if needed.]

Former Member
0 Likes

Two updates:

First of all, sorry for asking whether there is documentation. I have encountered undocumented aspects of PCo before, but this is not such a case. I shouldn't have typed before I looked. So for other people's future reference: http://help.sap.com/saphelp_pco22/helpdata/en/46/a00344d44852b7e10000000a155369/frameset.htm

Second, I have tried changing up the following settings with no success. I keep hoping there is a magical configuration setting that will solve this irritating problem, but I have not found that to be the case thus far. Any further ideas, anyone?

Here's what I've tried changing, without achieving the desired result:

SOURCE SYSTEM:
Settings - OPC DA Settings - Acquisition Mode: Synchronous
Settings - Group Settings - Time Difference: 00:00:00.000
Settings - Group Settings - Deadband: 0.0%

AGENT INSTANCE:
Cache mode: Demand

Former Member
0 Likes

Gregory,

It appears as if the timestamps are the issue.  Can you try thiis:

1.  query a single tag, then two tags, then 3 tags, etc. from the PCoQuery until you get the multiple rows in the rowset.  You migh try some different subset compbinations of the tags to see if a particular combination generates multiple rows.

2.  Do you have the opiton of installing a different OPC Server to see if the issue is not related to the FactoryTalk Gateway server?  You can get trial versions of OPC Servers that are fully functional for either a short period of time (2 hours) before requiring a restart, or just for a fixed number of days.  I would recommend to test either KepServerEX or Matrikon OPC Explorer.  We have used  both with PCo with excellent results.

Regards, Steve

Former Member
0 Likes

1. I tried this and got the same results as I was expecting. I was able to restrict the number of tags in my query and get my data all in the same row, but only by specifically looking at which tags are showing up on the wrong rows.

2. I'll consider trying out a different OPC server. It may be difficult to arrange, but I'll think about it.

Let me describe this in a bit more detail, in case it is of any help.

Attached is a spreadsheet of two different sets of  observations. Too bad I couldn't attach an .xlsx file, but the .txt file attached is in Excel .csv format.
- On 2012-11-02, I recorded the values in columns B-G, and columns H-M tell which values appeared outside of the first row.
- On 2012-11-14, I didn't bother recording the values, but recorded again which values in my query were outside of the first row.

Example 1 - Equipment Number 1084:
The example I initially gave in this thread was for Equipment Number 1084. It was originally showing value 5 on Row 2, and value 6 on Row 3. In the days since, that problem has gone away on its own. But that does not fix my problem, since new problems are appearing...

Example 2 - Equipment Number 2121:
Originally all was well with Equipment Number 2121, but now values 3, 4, 5, and 6 are all on Row 2.

This spontaneous "problems appearing" and "problems resolving themselves" does not happen much on a minute-to-minute basis, but does sometimes happen on a day-to-day basis.

Incidentally, in the past week, we have upgraded from MII 12.2.3 to 12.2.4. This does not seem to have affected the problem described here, either for better or worse.

I am going to open up a help request with SAP on this. At this point I am doubtful that anyone will be able to help without remoting into our network and seeing it for themselves -- although I definitely appreciate your suggestions!

Greg