cancel
Showing results for 
Search instead for 
Did you mean: 

Testing PCo 2.1

Former Member
0 Kudos

Hi all,

I'm testing around with the new PCo 2.1 and for our testcases I need to push the following parameters into the message for the MII transaction:

- tagname

- actual tagvalue

- quality

- timestamp OPC

The message that is sent to the configured MII transaction contains the following fields:

<NotificationMessage>
  <Header>
    <Name>Test_MII_Transaction</Name>
    <Description />
    <Destination>TA_test</Destination>
    <CreatedDate>2010-02-24T09:51:19</CreatedDate>
    <ID>4259f385-f6c0-4eaa-91b7-6ae3ddb11b48</ID>
    <Status>Delivered</Status>
 </Header>
 <Body>
    <Values>
       <Log_Memory_1 type="xsd.short">
         <![CDATA[1
       
    
  
  
]]>

So I think I can use the field below values for the tagname (I use the tagname as the output name) and the value is set in the CDATA-field (I hope that I can interprete this field with MII, but I did not try it yet).

But now I'm not sure if the CreatedDate is equal with the OPC timestamp or if there could be a delay between the value change on the OPC server and the message creation?!

And how can I detect the quality of the tag and put it in the message? Is that even possible?

Thanks

Anika

Accepted Solutions (0)

Answers (2)

Answers (2)

former_member196557
Active Contributor
0 Kudos

Anika,

I believe the CreatedDate element in the Notification Message is the timestamp of the trigger event that generated the message.

I don't think you can access OPC quality but I do not think Pco will pass a bad quality value to an Agent Instance. However, if you are passing several OPC items in the notification message assume that only the last good quality value will be included in the message.

You can just query the notification message with xPath and it will correctly parse the CDATA wrapper around the value and just return the value.

- Steve

Former Member
0 Kudos

So you mean, it is not possible to access OPC quality and OPC timestamp?

But I saw a configuration option called "acceptable data quality" and there you can even configure "None" or "Uncertain" etc. So I thought I could tell the PCo to ignore the quality but pass it as a paramter via the message. But I guess it's not possible. Also to access any other values besides the value?!

Maybe you can help me also with another question: What is the lowest checking interval? Is it possible to use something like "00:00:00.000" (is that hh:mm:ss.ms?) to notice every change if the OPC server supports quite fast intervals?

Thanks a lot!

Anika

former_member196557
Active Contributor
0 Kudos

Anika,

There are two sample intervals to consider for OPC data. One is the rate at which the OPC server queries the device for data, the other is the Update Rate Interval that you define for the OPC Agent in Pco. You can probably set the Update Rate in Pco to a value as low as 00:00:00.010, but if your OPC Server update rate is set a 1 second, you will only see changed values every 1 second. There are some other OPC Server update methods that involve the PLC sending Unsolicited Data to the server, but those are rare.

The other consideration is the system performance if you have OPC data changing 10 to 100 times a second and each change

triggers a notification and a transaction...

Former Member
0 Kudos

Hey Steve,

yes, I wanted to know the lowest possible interval for the update rate in PCo. If we defined the rate in the OPC server with 50ms I would like to set this value also in the PCo.

>

...

> The other consideration is the system performance if you have OPC data changing 10 to 100 times a second and each change

> triggers a notification and a transaction...

That's what we want to test: the performance and the stability of the PCo and the collaboration with MII .

former_member196557
Active Contributor
0 Kudos

I just did a quick test with Pco 2.1, KepServerEx 4.0 using the Sim driver, I was able to set an Update rate in Pco of 00:00:00.010 and get notifications in Pco. If you can use the KepServerEx OPC server for testing it comes with a Simulation driver that generates some high speed (10mSec) OPC data value changes.

Former Member
0 Kudos

Thanks a lot Steve.

We will use Simatic NET OPC Server for our test with S7. The server is configured with 50ms and I will configure the PCo also with this value.

But unforutnately I miss the OPC timestamp etc. for this tests. I thought this would be possible via OPC.

Former Member
0 Kudos

I just checked the Kepware simulation tags. The lowest scan rate I could see is 100 ms. The values didn't update any faster even when I changed it to 10 ms. Still remained at 100 ms.

former_member196557
Active Contributor
0 Kudos

On my version V4.300.449.0 U, using the Simulation driver, the tag Channel_0_User_Defined.Ramp.Ramp1 updates at 10 mSec intervals by definition, but actual update rate is more like 15-20mSec. However, even for a 100mSec update that is 10 notifications a second at Pco. That is still a high rate for testing.

former_member196557
Active Contributor
0 Kudos

Anika,

You still have the Notification timestamp and that is within (OPC Scan + Pco Update) of the ACTUAL data change date in the PLC. What do you need the actual OPC timestamp for?

Former Member
0 Kudos

We want to calculate the time between the data change on the OPC server and the transaction execution in MII. So if there's already a delay between the data change and the message creation in PCo, we miss this difference.

Former Member
0 Kudos

We had the same problem. I think its possible to get the MII transaction execution time from the logs. But OPC/PCo part is still a challenge.

Former Member
0 Kudos

The transaction itself is the easiest part I guess. We will store a little XML file with the relevant data containing datenow and so on. So for the simple tests we have to write down the timestamps manually by looking at the OPC client that initiates the value change. But for the more complex tests it is not possible.

Former Member
0 Kudos

That is the timestamp when the notification was created; could be different from when the value was changed.

Ideally they need to be the same. But you can expect a difference.