Creating DeviceNet Windows-based applications is now easier than ever. Your C++ or VB application can now function as a DeviceNet Scanning Master. As a DeviceNet Scanning Master your application can make connections and exchange data with any DeviceNet Slave. You can turn valves on and off, read input points from DeviceNet PE, Prox Blocks and other DeviceNet I/O devices. And you can set or get any attribute in any device, just like RsNetworks.
The DeviceNet Master DLL wraps the standard Real Time Automation, Inc. DeviceNet application layer protocol stack and exposes the portion of the application layer needed by a MS Windows (or .Net) application. The remainder of the application layer protocol stack is internally processed by the DLL and hidden from the end user application.
Prior to enabling communications, the DeviceNet Master DLL must be configured. The configuration parameters are set from the consumer's application via a set of function calls to the DLL. These configuration parameters must be set before communications are enabled. Attempts to set these parameters, once communications are enabled, is considered an error.
The end user application can enable and disable communications via a pair of function calls. When communications are enabled, the DeviceNet Master Application layer protocol initiates connections with the DeviceNet Slaves and begins exchanging data as configured by the end user application. When communications are disabled, the DLL disconnects any existing Slave connections and disregards any further protocol traffic and network requests.
Internally, the DLL performs communications processing using a worker thread. This thread is created when communications are enabled and exits when communications are disabled. The thread runs in an endless loop waiting on sockets, timers, or a signal to exit.
Notifications from the DLL of messages that require custom processing are handled via callback functions to the end user application. These callback functions are defined to the DLL by the consumer's application prior to enabling communications. The consumer's application should be aware that these callbacks are called in a multi-threaded context, and must implement the callback functions in a thread-safe manner. Specifically, the consumer's application should (if necessary) provide thread-synchronization when accessing its own data/functions (e.g., using critical sections), and efficiently processing the callback and returning in a timely fashion.
|
