For the I/O Object, the ReadAvail state sets when a new input message is received from the network. The ReadAvail state clears when you call ncReadDnetIO. For example, for a change-of-state (COS) I/O connection, the notification occurs when a COS input message is received.

The typical behavior for your callback function is to call ncReadDnetIO to read the new input data, perform any calculations needed, call ncWriteDnetIO to provide output data, then return from the callback function.

For the Explicit Messaging Object, the ReadAvail state sets when an explicit message response is received from the network. The ReadAvail state clears when you call ncReadDnetExplMsg. An explicit message response is received only after you send an explicit message request using ncWriteDnetExplMsg.

Although using a notification for an explicit message response allows for execution of other code while waiting, it is often more straightforward to use the following sequence of calls: ncWriteDnetExplMsg, ncWaitForState, and ncReadDnetExplMsg. This is the sequence used internally by ncGetDnetAttribute and ncSetDnetAttribute.

The ReadAvail state is not needed when using the explicit messaging functions ncGetDnetAttribute and ncSetDnetAttribute because both of these functions wait for the explicit message response internally.

For the Explicit Messaging Object, the Established state is clear (not established) before you start communication using ncOperateDnetIntf. After you start communication, the Established state remains clear until the explicit message connection has been successfully established with the remote DeviceNet device. After the explicit message connection has been established, the Established state sets and remains set for as long as the explicit message connection is open.

Until the Established state is set for the Explicit Messaging Object, all calls to ncGetDnetAttribute, ncSetDnetAttribute, or ncWriteDnetExplMsg return the error CanErrNotStarted. Before you call any of these functions in your application, you must first wait for the Established state to set.

After the Established state is set, unless communication problems occur with the device (CanErrFunctionTimeout), it remains set until you stop communication using ncOperateDnetIntf.

While waiting for one of the above states, if an error occurs (such as a communication error or an initialization error), the notification returns immediately with the appropriate error code. For example, if you call ncCreateNotification with DesiredState of ReadAvail, the notification function will return when data is available for a read, or when a DeviceNet communication error (such as connection timeout) is detected.

NCTYPE_STATE	_NCFUNC_ Callback(
   NCTYPE_OBJH	ObjHandle, 
   NCTYPE_STATE	CurrentState, 
   NCTYPE_STATUS	Status, 
   NCTYPE_ANY_P	RefData);

Object handle originally passed to ncCreateNotification. This identifies the object generating the notification, which is useful when you use the same callback function for multiple objects.

Current state of the object. If one of the desired states occurs, it provides the current value of the ReadAvail and Established states. If the Timeout expires before one of the desired states occurs, it has the value 0.

Current status of the object. If one of the desired states occurs, it has the value 0 (DnetSuccess). If the Timeout expires before one of the desired states occurs, it has the value BFF62001 hex (CanErrFunctionTimeout).

Pointer to your reference data as originally passed to ncCreateNotification.

The value you return from the callback indicates the desired states to re-enable for notification. If you want to continue to receive notifications, return the same value as the original DesiredState parameter. If you no longer want to receive notifications, return a value of 0.

If you return a nonzero value from the callback, and one of those states is still set, the callback is invoked again immediately after you return. For example, if you return ReadAvail from the callback without calling ncReadDnetIO to read the available data, the callback is invoked again.

When the NI-DNET device driver calls your notification callback, it does so in a separate thread within the LabWindows/CVI process. Your application's front panel indicators and controls can only be accessed within the main thread of the LabWindows/CVI process. Although you can call NI-DNET functions and perform generic C calculations in your notification callback, you cannot call LabWindows/CVI functions which access the front panel (the User Interface Library). To use the LabWindows/CVI User Interface Library, save any data needed for front panel indicators using global variables, then register a deferred callback using the LabWindows/CVI PostDeferredCall function. Since a LabWindows/CVI deferred callback executes in the main thread of the LabWindows/CVI process, you can call any LabWindows/CVI function, including the User Interface Library.

When the NI-DNET device driver calls your notification callback, it does so in a separate thread within your process. Therefore, it has access to any process global data, but not thread local data. If your callback function needs to access global variables, you must protect that access using synchronization primitives (such as semaphores) because your callback is running in a different thread context. For an explanation of these concepts and other multithreading issues, refer to the online help of the Microsoft Win32 Software Development Kit (SDK).