understanding opc diagnostics

8/3/2019 Understanding OPC Diagnostics

1/16

Understanding OPC DiagnosticsV4.110 and Up

Document v1.02

OverviewIf you have used KEPServerEX for a while then you have probably seen and used the channel

diagnostics. The channel diagnostics are an essential tool in diagnosing communications issues with

devices. Likewise, OPC diagnostics, a newer feature, allows us to diagnose the OPC process between

the server and a client application.

Note: One of the advantages of OPC diagnostics is the ability to save the diagnostics captureand then open it in the OPC diagnostics viewer again later. This makes it much easier tocompare tests.

How to Enable DiagnosticsDiagnostics is enabled or available at the server level. When developing custom client applications or

when experiencing problems with an OPC client, it is good practice to use diagnostics to see exactly

how the client application is connecting to and requesting data from the server if it is connecting at all.

For these examples we used the Kepware OPC Quick Client and the SimDemo project that installs

with the server. We manually created 2 client connections and used Disconnect and Connect to initiate

connections. We are also only using a couple of items in each connection.

1. In the server main menu, click on View|Diagnostics|OPC to open the OPC Diagnostics window.

KTAN-90041 Page 1 of 16


2/16

Start button

Figure 1

2. You could click on the Start button to start capturing OPC diagnostics right away but you willprobably want to take a look at the configuration settings first. Click on Diagnostics | Options to

display the Options dialog which displays the configuration settings.

Configuration Settings

Typically you will manually start the OPC diagnostic capture, but if you are launching the server as

a service or from a client connection, then you will want to enable it to start on startup. See Figure

2 below and a description of the Options settings.

Figure 2

a. You can decide whether or not OPC diagnostics information should be captured every

time the server is started by selecting the 'Automatically start capturing diagnostics on

startup' checkbox. Remember that the performance of the server is affected by capturing

diagnostic information, as it is an additional layer of processing that occurs between all

client/server communications. By default this functionality is turned off.

b. You can also decide whether or not to persist the OPC diagnostic information to disk

when the server is shutdown by selecting the 'Preserve diagnostics to disk on

shutdown'. This can be useful if you need to go back in time to determine where a

particular issue may have occurred. You can also create your own backup of diagnostics

data at any time through the File -> Save As menu option. By default this functionality is

turned on

Page 2 of 16 KTAN-90041


3/16

c. Since diagnostic information has an affect on memory/file storage, you can set the

maximum number of OPC diagnostic events to be captured at any specific time, by

modifying the 'Maximum number of diagnostics to capture'. This value only pertainsto the number of events and does not include the number of details, as the detail count for

a particular event could be potentially very high. The range for this setting is 1000 to

30000. The default value is 5000.

Filtering

The Filter Dialog allows you to select which events you want to capture. This aids in debugging aparticular issue by eliminating events that do not pertain to a particular issue.

Note: Most clients will make continuous GetStatus calls into the server to determine that theserver is still available. Filtering this event will simplify the diagnostics data to examine

Figure 3

Each method (e.g., GetErrorString) of every OPC Data Access 1.0, 2.0 and 3.0 interface (e.g.,

IOPCCommon) supported by the server is available as a filter. You can select a method by clickingthe checkbox to the left of the method name. Additionally, you can select all methods of an

interface by double clicking the interface name. By default, all methods for all interfaces are

selected.

Note: Filter changes apply only to new events captured. Previous events that meet the filtercriteria will not be removed from the view.



4/16

Capturing the DiagnosticsOnce you have everything configured you can start to capture OPC diagnostics. In our example we

manually started OPC diagnostics and then started our client application so that we could capture the

diagnostics from Connect to Disconnect. We are not filtering OPC transactions so ours gets busy very

quickly.

3. Start the diagnostics capture. (Figure 4)

Start button

Figure 4

4. Connect your application and you will see each OPC transaction posted in the diagnostic viewer.

(Figure 5).

Figure 5

5. If you are going to send the captured OPC diagnostics data to Kepware Technical Support, you

will need to save the data. Click on File | Save As in the Diagnostics main menu. You can choose

to save the diagnostics as an OPCDIAG file that can be re-opened in the viewer later or, you can

save it as a text file to view offline. (Figure 6)



5/16

Figure 6

Note: We saved our example in both formats and will use parts of the text file in the nextsection to explain what you are seeing in the diagnostics.

Evaluating the DiagnosticsFor the rest of our examples we are going to use excerpts from the saved text file version of the OPC

diagnostics.

By now you have probably done your own OPC diagnostics and are trying to figure out what it is

telling you. In most cases you will be capturing the diagnostics to send to technical support. However

the following will explain a little about the file for you.

The default of the diagnostics is to capture and show all of the OPC transactions. If your goalis to verify the adding of Groups and Items as well as how they are polled etc., then you willwant to set some filters before doing the capture. See the Filtering section above.

Connecting to the ServerThe first transaction of importance is the actual connection of the client to the server. Note that the

connection is assigned a Diagnostic Client ID. This is useful if you have more then one client

application connecting to the server and only one client is exhibiting a problem. (See Text 1)

6/29/2006 12:08:20:662 PM IClassFactory::CreateInstance ()0000000000: Event started

0000000000: InterfacePointer = 0x01BB3F980000000000: [in] pUnkOuter = 000000000000000000: [in] iid = {00000000-0000-0000-C000-000000000046}0000000000: [in] ppvObject = 011CF478

0000000000: Created new server instance. Assigning diagnostics ClientID = 000000040000000000: Function succeeded. Result = 0x00000000.0000000000: [out] *ppvObject = 0x01C34B90

0000000000: Event complete

Text 1



6/16

Adding the OPC GroupNext, the OPC group is added from the client application. Notice that it has a unique name. OPC

group names cannot be duplicated within a client connection. The group is also set to active and the

update rate is being set for the group to 1000 msec. (See Text 2)

The server then sends a Group Handle ID and a Revised Update Rate back to the client application.

The revised update rate is usually the same as the requested update rate unless the requested rate is out

of range. (See Text 2)

The last thing that you should see with every event like this is an Event complete message. This

indicates that the client has acknowledged the response. (See Text 2)

6/29/2006 12:08:20:709 PM [ClientID: 00000004] IOPCServer::AddGroup ()0000000000: Event started0000000000: InterfacePointer = 0x01D26C10

0000000000: [in] Name = Test10000000000: [in] Active = True0000000000: [in] RequestedUpdateRate = 10000000000000: [in] ClientGroupHandle = 0x00A12580

0000000000: [in] TimeBias = 0

0000000000: [in] Deadband = 0.0000000000000000: [in] LocaleID = 10330000000000: Function succeeded. Result = 0x00000000

0000000000: [out] ServerGroupHandle = 0x01D5E3780000000000: [out] RevisedUpdateRate = 10000000000000: Event complete

Text 2



7/16

Adding the OPC ItemsWe have added the OPC group so now we have to add the collection of items to be polled by the

server for this group.

In our example we added 4 items. Of importance are the Item ID, the Requested Data Type, the Active

State, and a Client handle number. (See Text 3)

A. Count The number of items that were added.

B. Item ID This is the item in the server you want to have it poll (Channel_1.Device_1.Tag_3)C. Requested Data Type This how you want the value, for example as a short or a word. This is

sent as a value or canonical data type. In the highlighted text the Hex value 0x0002 is for the

short data type. (See our application note KTAN-90028, Canonical Data Types.)

D. Active State This is set to True so that the server will poll the item automatically.

E. Client Handle This is what the server will send back with data change events identifying the

item that has changed values.

6/29/2006 12:08:20:709 PM [ClientID: 00000004] IOPCItemMgt::AddItems ()0000000000: Event started

0000000000: InterfacePointer = 0x01D274300000000000: GroupName = Test10000000000: [in] Count = 4

0000000000: [in] ItemID [0] = Channel_1.Device_1.Tag_30000000000: [in] AccessPath [0] = (null)0000000000: [in] RequestedDataType [0] = 0x00020000000000: [in] Active [0] = True0000000000: [in] ClientHandle [0] = 0x00A26AD8

0000000000: [in] Blob [0] = 0x000000000000000000: [in] BlobSize [0] = 00000000000: [in] ItemID [1] = Channel_1.Device_1.Tag_2

0000000000: [in] AccessPath [1] = (null)0000000000: [in] RequestedDataType [1] = 0x00020000000000: [in] Active [1] = True

0000000000: [in] ClientHandle [1] = 0x00A233680000000000: [in] Blob [1] = 0x000000000000000000: [in] BlobSize [1] = 00000000000: [in] ItemID [2] = Channel_1.Device_1.Tag_1

0000000000: [in] AccessPath [2] = (null)0000000000: [in] RequestedDataType [2] = 0x00020000000000: [in] Active [2] = True0000000000: [in] ClientHandle [2] = 0x00A232E00000000000: [in] Blob [2] = 0x00000000

0000000000: [in] BlobSize [2] = 00000000000: [in] ItemID [3] = Channel_1.Device_1.Bool_10000000000: [in] AccessPath [3] = (null)0000000000: [in] RequestedDataType [3] = 0x000B

0000000000: [in] Active [3] = True0000000000: [in] ClientHandle [3] = 0x00A0F9C80000000000: [in] Blob [3] = 0x00000000

0000000000: [in] BlobSize [3] = 0

Text 3

The server will respond back to the client in the Add time transaction with a Function succeeded

Result, and then for each item added an Error code, the canonical data type of the item a Server handle

and Access writes. The last transaction is an Event Complete message which is the client

acknowledging that it has received the response. (See Text 4)



8/16

F. Function Succeeded This is a success code for the event. A code of 0x00000000 indicates

that all items were added successfully. A code of 0x00000001 indicates that one or more of

the items added to the server failed.

G. Item Error code If the item was added successfully then this code will be 0x00000000. If it

did not get added successfully then you will get an error code like 0x80040005. When an item

fails you should check the Server message log for an error as well.

H. Item Canonical Data Type This is the numerical code for the Data type of the Item. In the

highlighted example 0x0002 is for the Short or signed integer data type, which is what was

requested for this item.

I. Item Server Handle This is a unique number created by the server for each item that isrequested by the OPC client.

Note: If you add the same item to the server 50 times then the server will track it with 50different Server handles in a database that it creates. Doing this causes the server to usemore System RAM and can easily impact the performance of your system.

J. Item Access Rights This lets you know whether the item is configured for Read/Write (3) or

Read Only (1). If it is Read Only then any attempt to write to the device will fail.

0000000000: Function succeeded. Result = 0x000000000000000000: [out] Error [0] = 0x00000000

0000000000: [out] CanonicalDataType [0] = 0x00020000000000: [out] ServerHandle [0] = 0x01DBBBE0

0000000000: [out] AccessRights [0] = 30000000000: [out] dwBlobSize [0] = 0

0000000000: [out] Error [1] = 0x000000000000000000: [out] CanonicalDataType [1] = 0x0002

0000000000: [out] ServerHandle [1] = 0x01DBBD880000000000: [out] AccessRights [1] = 30000000000: [out] dwBlobSize [1] = 00000000000: [out] Error [2] = 0x00000000

0000000000: [out] CanonicalDataType [2] = 0x00020000000000: [out] ServerHandle [2] = 0x01DBBF300000000000: [out] AccessRights [2] = 30000000000: [out] dwBlobSize [2] = 0

0000000000: [out] Error [3] = 0x000000000000000000: [out] CanonicalDataType [3] = 0x000B0000000000: [out] ServerHandle [3] = 0x01DBC0D8

0000000000: [out] AccessRights [3] = 30000000000: [out] dwBlobSize [3] = 00000000000: Event com lete

Text 4



9/16

The Data Change EventNow that the items are added, you will start getting data change events. (See Text 5)

The data change event occurs any time that the value received when polling the PLC has changed from

the previous poll or when the item quality changes.

A. Group Name This is the name of the OPC group for which the data change event is sent.

B. Intializing Call for x Items- This is the number of items sent in the change event.C. Item ID This is the item that is being updated. This is for debugging purposes. This is not

part of the data change event that the client receives.

D. Client Handle This is how we identify the item in the client. It is the handle that was

returned to the client when the item was added.

E. Value This is the value of the item now that the value or the quality has changed.

F. Time This is the time that the change occurred.

G. Quality This is the quality of the data. A value of 0x00C0 (192) indicates that the value that

is displayed is from a successful poll of the device.

H. Error This is an error code that indicates the possible reason for the bad quality. Typically

you will get an error code of 0x80040005 which is a generic error code. This should prompt

you to check the server message log.

I.

Sending Client On Data Change This indicates that the data change was sent to the clientapplication.

J. Call Succeeded result This indicates that the client application received the data change

event. It will respond with a result code of 0x00000000 that it was successful or 0x00000001

that it failed.



10/16

6/29/2006 12:08:20:725 PM [ClientID: 00000004] IOPCDataCallback::OnDataChange ()0000000000: Event started

0000000000: InterfacePointer = 0x0019EF740000000000: GroupName = Test10000000000: Initializing call for 4 item updates.0000000000: [in] ItemID [0] = Channel_1.Device_1.Bool_1

0000000000: [in] ClientItemHandle [0] = 0x00A0F9C80000000000: [in] Value [0] = 00000000000: [in] Time [0] = 12:08:20:7250000000000: [in] Quality [0] = 0x00C0

0000000000: [in] Error [0] = 0x000000000000000000: [in] ItemID [1] = Channel_1.Device_1.Tag_10000000000: [in] ClientItemHandle [1] = 0x00A232E0

0000000000: [in] Value [1] = 1420000000000: [in] Time [1] = 12:08:20:7250000000000: [in] Quality [1] = 0x00C00000000000: [in] Error [1] = 0x00000000

0000000000: [in] ItemID [2] = Channel_1.Device_1.Tag_20000000000: [in] ClientItemHandle [2] = 0x00A233680000000000: [in] Value [2] = 1420000000000: [in] Time [2] = 12:08:20:725

0000000000: [in] Quality [2] = 0x00C00000000000: [in] Error [2] = 0x000000000000000000: [in] ItemID [3] = Channel_1.Device_1.Tag_3

0000000000: [in] ClientItemHandle [3] = 0x00A26AD80000000000: [in] Value [3] = 1420000000000: [in] Time [3] = 12:08:20:7250000000000: [in] Quality [3] = 0x00C00000000000: [in] Error [3] = 0x00000000

0000000000: [in] ClientHandle = 0x00A125800000000000: [in] TransactionID = 0x000000000000000000: [in] MasterQualityResult = 0x00000000

0000000000: [in] MasterErrorResult = 0x00000000

0000000000: Sending client OnDataChange notification.

0000000000: Call succeeded. Client result = 0x00000000

0000000000: Event com lete

Text 5

Other Ways to Get DataNow lets talk about the other ways to read and write to the server. They are Synchronous Reads for

Device or Cache and Asynchronous Reads for getting the data. There are Synchronous and

Asynchronous Writes for sending data down to the device. We will show you what these methods

look like in the diagnostic view. See other Kepware white papers for pros and cons of using the

different methods.



11/16

Synchronous Device ReadsSynchronous Device Reads tell the server to read the request items from the device and return the

items whether data has changed or not. See Text 6 and Text 7 for the details of the Synchronous

Device Read transaction.

A. GroupName Name of the OPC Group Sending the request.

B. Source This parameter tells where the read should come from, the device or the disk

memory cache.

C. Count This is the number of items being requested.D. ServerHandle This is the server handle that was reported back to the client when the item

was added to the OPC group.

Text 6

7/11/2006 5:18:43:829 PM [ClientID: 00000004] IOPCSyncIO::Read ()

0000000000: Event started0000000000: InterfacePointer = 0x01BEF2100000000000: GroupName = Test10000000000: [in] Source = OPC_DS_DEVICE

0000000000: [in] Count = 10000000000: [in] ServerHandle [0] = 0x01BF93680000000000: ServerHandle 0x01BF9368 -> ItemID = Channel 1.Device 1.Tag 1.

E. Function Succeeded This is a success code for the event. A code of 0x00000000 indicates

that all items were read successfully. A code of 0x00000001 indicates that one or more of the

items to be read in the server failed.

F. Error If the date is in error this will have a code that can indicate the reason for the error.

G. Value The value from the device or last value if in error.

H. Time The time that this items value and quality were updated to the server.

I. Quality The current Quality of the data as it was update to the server.

J. ClientHandle This is the client handle that the client application assigned to the item when it

was added.

K. Event Complete This indicates that the client has acknowledged the response from the server

and the transaction is now completed.

Text 7

0000000016: Function succeeded. Result = 0x000000000000000016: [out] Error [0] = 0x000000000000000016: [out] Value [0] = 972

0000000016: [out] Time [0] = 17:18:43:8290000000016: [out] Quality [0] = 0x00C00000000016: [out] ClientHandle [0] = 0x00A0CD58




12/16

Synchronous Cache ReadsThe Cache read is no different from the device read other then the source parameter that is used. This

tells the server to read the last value that was stored in the disk memory cache.

7/11/2006 5:18:47:670 PM [ClientID: 00000004] IOPCSyncIO::Read ()0000000000: Event started

0000000000: InterfacePointer = 0x01BEF210

0000000000: GroupName = Test10000000000: [in] Source = OPC_DS_CACHE0000000000: [in] Count = 2

0000000000: [in] ServerHandle [0] = 0x01BE5B480000000000: [in] ServerHandle [1] = 0x01BF93680000000000: ServerHandle 0x01BE5B48 -> ItemID = Channel_1.Device_1.Bool_1.0000000000: ServerHandle 0x01BF9368 -> ItemID = Channel_1.Device_1.Tag_1.

0000000000: Function succeeded. Result = 0x000000000000000000: [out] Error [0] = 0x000000000000000000: [out] Value [0] = 0

0000000000: [out] Time [0] = 17:18:46:7330000000000: [out] Quality [0] = 0x00C00000000000: [out] ClientHandle [0] = 0x00A0CDE00000000000: [out] Error [1] = 0x00000000

0000000000: [out] Value [1] = 975

0000000000: [out] Time [1] = 17:18:46:7330000000000: [out] Quality [1] = 0x00C00000000000: [out] ClientHandle [1] = 0x00A0CD58

0000000000: Event com lete

Text 8



13/16

Asynchronous ReadsAsynchronous reads are similar to the Synchronous read requests in that they return all of the

requested item values whether there has been a change or not. The difference is that the client does not

wait for the server to complete the read request; instead the server sends an Asynchronous Read

Complete message to the client when it has completed the request.

Read Request

Since the read is in 2 parts there are a few differences in the format of the read transaction. See Text 9for the parts that are different from a Synchronous Read.

A. TransactionID This is a unique ID that is provided by the OPC client. If they are sending

several read requests this allows the client to verify that it gets a response to each request.

B. CancleID This is returned by the server to the client application. The client application can

use this ID to cancel these requests before it completes.

C. Error You can get errors when making the request of the server for data which are returned

here.

Text 9

7/11/2006 5:18:52:401 PM [ClientID: 00000004] IOPCAsyncIO2::Read ()0000000000: Event started0000000000: InterfacePointer = 0x01BF0520

0000000000: GroupName = Test1

0000000000: [in] TransactionID = 0x013D30410000000000: [in] Count = 40000000000: [in] ServerHandle [0] = 0x01BE5B48

0000000000: [in] ServerHandle [1] = 0x01BF93680000000000: [in] ServerHandle [2] = 0x01BF39680000000000: [in] ServerHandle [3] = 0x01BE65E00000000000: Initializing an AsyncIO2::Read transaction.

0000000000: ServerHandle 0x01BE5B48 -> ItemID = Channel_1.Device_1.Bool_1.0000000000: ServerHandle 0x01BF9368 -> ItemID = Channel_1.Device_1.Tag_1.0000000000: ServerHandle 0x01BF3968 -> ItemID = Channel_1.Device_1.Tag_2.0000000000: ServerHandle 0x01BE65E0 -> ItemID = Channel_1.Device_1.Tag_3.0000000000: Function succeeded. Result = 0x00000000

0000000000: [out] CancelID = 0x01C833600000000000: [out] Error [0] = 0x000000000000000000: [out] Error [1] = 0x00000000

0000000000: [out] Error [2] = 0x000000000000000000: [out] Error [3] = 0x000000000000000000: Event com lete



14/16

Read CompleteIn the read complete message you get the same items in the packet that you do for data change events,

plus you get the Transaction ID as well. A client application that is keeping track of these will be able

to clear this from its list of outstanding request.

Text 10

7/11/2006 5:18:52:401 PM [ClientID: 00000004] IOPCDataCallback::OnReadComplete ()0000000000: Event started

0000000000: InterfacePointer = 0x00195E6C0000000000: [in] Count = 40000000000: [in] ClientHandle = 0x00A1DDD8

0000000000: [in] TransactionID = 0x013D30410000000000: [in] MasterQualityResult = 0x000000000000000000: [in] MasterErrorResult = 0x00000000

0000000000: [in] ClientItemHandle [0] = 0x00A0CDE00000000000: [in] Value [0] = 00000000000: [in] Time [0] = 17:18:52:4010000000000: [in] Quality [0] = 0x00C0

0000000000: [in] Error [0] = 0x000000000000000000: [in] ClientItemHandle [1] = 0x00A0CD580000000000: [in] Value [1] = 9810000000000: [in] Time [1] = 17:18:52:401

0000000000: [in] Quality [1] = 0x00C0

0000000000: [in] Error [1] = 0x000000000000000000: [in] ClientItemHandle [2] = 0x00A11F400000000000: [in] Value [2] = 981

0000000000: [in] Time [2] = 17:18:52:4010000000000: [in] Quality [2] = 0x00C00000000000: [in] Error [2] = 0x000000000000000000: [in] ClientItemHandle [3] = 0x00A11EB8

0000000000: [in] Value [3] = 9810000000000: [in] Time [3] = 17:18:52:4010000000000: [in] Quality [3] = 0x00C0

0000000000: [in] Error [3] = 0x000000000000000000: Sending client OnReadComplete notification.0000000000: Call succeeded. Client result = 0x00000000


Sending Data to the DeviceWe have seen what it looks like when the server sends updates to the client or responds to a request for

data, now lets see what happens when the client application sends data to the device. There are 2

options for sending data and they are via Synchronous or Asynchronous Writes.

Synchronous WritesSynchronous writes, like Synchronous reads, require the server to execute the write and respond back

to the server before doing anything else. Likewise, the client application is waiting for the response

before it can do anything else.

A. Group Name Group containing the item that is being written to.B. Count Number of items being written.

C. ServerHandle Server handle received when the item was added to the server

D. Value Value that is being written to the item.



15/16

E. Result Code This is a success code for the event. A code of 0x00000000 indicates that all

items were written successfully. A code of 0x00000001 indicates that one or more of the

items failed to be written to.

F. Error Any item that failed will have an event code. A typical error code for writes is

0xC0040006 which means the item does not have Write access writes.

G. Event Completed This indicates that the client application has acknowledged receiving the

update from the server.

Note1: The server does writes one at a time unless you are writing to an array. This meansthat it can take a long time to complete a Synchronous write transaction if you are writing to alarge number of items.

Note2: Completion of the write means that the device has accepted the write request for theitem, not that it has actually changed the value in its register. The server will not change thevalue that it is holding in its cache for this item until that item is read and the value is differentfrom the one currently held.

Text 11

7/11/2006 5:19:02:769 PM [ClientID: 00000004] IOPCSyncIO::Write ()0000000000: Event started

0000000000: InterfacePointer = 0x01BEF2100000000000: GroupName = Test10000000000: [in] Count = 10000000000: [in] ServerHandle [0] = 0x01BF3968

0000000000: [in] Value [0] = 10000000000: ServerHandle 0x01BF3968 -> ItemID = Channel_1.Device_1.Tag_2.

0000000016: Function succeeded. Result = 0x00000000

0000000016: [out] Error [0] = 0x00000000


Asynchronous WritesLike Asynchronous reads, Asynchronous writes are comprised of 2 parts: the Write request and the

Write complete.

Write Request

Like Reads, the Write request is similar to its synchronous counterpart except that it also has aTransaction ID, a Cancel ID, and an error code if the request is reject by the server.

Text 12

7/11/2006 5:19:23:067 PM [ClientID: 00000004] IOPCAsyncIO2::Write ()0000000000: Event started

0000000000: InterfacePointer = 0x01BF05200000000000: GroupName = Test10000000000: [in] TransactionID = 0x013DA821

0000000000: [in] Count = 20000000000: [in] ServerHandle [0] = 0x01BF39680000000000: [in] ServerHandle [1] = 0x01BE65E00000000000: [in] Value [0] = 0

0000000000: [in] Value [1] = 00000000000: Initializing an AsyncIO2::Write transaction.

0000000000: ServerHandle 0x01BF3968 -> ItemID = Channel_1.Device_1.Tag_2.0000000000: ServerHandle 0x01BE65E0 -> ItemID = Channel_1.Device_1.Tag_3.

0000000015: Function succeeded. Result = 0x000000000000000015: [out] CancelID = 0x01BE76400000000015: [out] Error [0] = 0x000000000000000015: [out] Error [1] = 0x00000000




16/16

Write Complete

The Write complete message contains an error code resulting from sending the request to the device

and a completion message when the client application acknowledges that it received the completion

event.

Text 13

7/11/2006 5:19:23:083 PM [ClientID: 00000004] IOPCDataCallback::OnWriteComplete ()

0000000000: Event started0000000000: InterfacePointer = 0x00195E6C

0000000000: [in] Count = 20000000000: [in] ClientHandle = 0x00A1DDD8

0000000000: [in] TransactionID = 0x013DA8210000000000: [in] MasterError = 0x00000000000000: [in] ClientItemHandle [0] = 0x00A11F400000000000: [in] Error [0] = 0x00000000

0000000000: [in] ClientItemHandle [1] = 0x00A11EB80000000000: [in] Error [1] = 0x000000000000000000: Sending client OnWriteComplete notification.


Note: The same conditions apply to the Asynchronous write as they do the Synchronous

write with one exception. The client does not wait for the write to complete. It is informedwhen the write is completed by the server and can continue with other tasks after sending thewrite request.

SummarySo now you understand something about the key OPC transactions. Knowing what is happening can

help to solve any number of OPC issues between the client and server. This can also help to identify

whether an issue lies in the OPC layer or the device layer. When OPC and Channel diagnostics are

used together they can provide a detailed snapshot of the entire automation process.


understanding opc diagnostics

Documents