Technical information

Getting Started
39
RMS Enterprise - NetLinx Programmer’s Guide
Getting Started
Source Code Samples
The RMS Enterprise Software Development Kit (SDK) provides a number of source code examples both for the Duet-based
implementation and the NetLinx-based implementation.
These examples can be found in the SDK installation directory and are also included in each of the two sample workspaces.
These samples include the following concepts:
Single Monitored Device Implementation
Single Monitored Device + Single Touch Panel & Client GUI Implementation
Multiple Monitored Devices + Multiple Touch Panels & Client GUI Implementation
Power Distribution Unit Implementation
Source Usage Tracking Implementation
System Power + System Mode Implementation
"Main-Duet" and "Main-NetLinx" sample files are also provided that are fully inclusive of all of the implementation samples fully
integrated into a single source project.
NetLinx or Duet Path?
When starting a RMS Enterprise project, one of the first things a control system programmer must determine is if they are going to
use Duet based device modules or if they are going to completely code all the device implementation in NetLinx.
Duet Device Implementation
If using Duet device modules, the RMS SDK implementation can be much simpler in that it can automatically communicate with
the Duet modules to determine device capabilities, device state, and listen for device change events. No custom NetLinx
programming is required to integrate the default device monitoring and control behavior with RMS. All that is needed is a
lightweight wrapper module defined alongside each Duet device definition.
Choosing the Duet route in RMS does not mean that the device monitoring and control logic is 100% predetermined and fixed. A
NetLinx programmer can override and/or extend the default implementation logic directly in the RMS Duet Monitor wrapper
module. There are callback methods included in the wrapper modules that provide the opportunity to register additional
parameters, metadata properties, and/or control methods.
Refer to the RMS Duet Device Monitoring Modules section on page 34 section for more information.
NetLinx Device Implementation
If not using Duet device modules, but rather implementing device functionality directly in NetLinx code or in NetLinx modules,
then the RMS SDK offers the RMS NetLinx Device Monitoring modules which provide the default implementation logic for
device monitoring and control with RMS. These monitoring modules are written completely in NetLinx code and are provided as
open source modules with the RMS SDK.
Implementing the RMS NetLinx Device Monitoring modules requires some additional programming effort on the part of the
NetLinx programmer. The RMS NetLinx Device Monitoring modules are programmed to provide a default implementation of
device monitoring and control but require some input to know when parameters or state has changed on a physical device.
The RMS NetLinx Device Monitoring modules use SNAPI as a convention for listening for these type of notifications. Therefore,
the NetLinx programmer must emulate the SNAPI communication for a particular device type to notify the RMS NetLinx Device
Monitoring module of any change on the physical device. Since these are fully open source, a programmer can make a custom
copy of the module and implement their own custom logic or extended behaviors as needed. There are callback methods included
in the monitor modules that provide the opportunity to register additional parameters, metadata properties, and/or control methods.
Refer to the RMS Duet Device Monitoring Modules section on page 34 section for more information.