Technical information

Programming - Advanced Topics
113
RMS Enterprise - NetLinx Programmer’s Guide
You'll notice above that a mixture of virtual and real devices are being assigned to have their source usage tracked. Non-controlled
devices should have their source usage tracked by passing in the virtual device. All controlled devices should be tracked by passing
in the actual device.
To activate source usage tracking on the Disc Device defined above, the following code would be used:
// Activate source usage tracking on dvDiscDevice and
// disable source usage tracking on all other devices
RmsSourceUsageActivateSource(3);
The above devices are having their source usage tracked in a mutually exclusive manner. In other words, when tracking of source
usage is activated for a device, such as the Disc Device in the above example, the previous selected device will have its source
usage tracking deactivated automatically. For example, in the below code, tracking of source usage will be activated for the
Document Camera device, and subsequently disabled for the Disc Device:
// Activate source usage tracking on dvDocCamera and
// disable source usage tracking on dvDiscDevice
RmsSourceUsageActivateSource(4);
The code below illustrates how you would manually deactivate source usage tracking for a device:
// Deactivate source usage tracking on dvDocCamera
RmsSourceUsageDeactivateSource(4);
Please review the RmsSourceUsage.axi code comments for more details on tracking source usage in RMS.
Implementing System Power
Because RMS Enterprise offers greater flexibility and support for multiple control system masters that can coexists in a single
location, RMS SDK 4.0 does not provide any concrete implementation of System Power. The RMS SDK provides the
communications infrastructure and state management for System Power, but the NetLinx programmer must provide the
implementation in the user program.
First, if you wish to provide System Power on the target NetLinx controller, you must first enable the compiler directive in the
RmsControlSystemMonitor module.
// comment out the HAS_SYSTEM_POWER precompiler variable
// if you do not wish to register a 'System Power' parameter
// and control methods for this control system. Some
// implementations may not warrant/desire the concept of
// a single System Power convention.
#WARN 'Define if you want a SYSTEM POWER parameter & control methods registered for this control system
...'
// to include the system power parameter and system power control methods
// this module definition is required
DEFINE_MODULE 'RmsSystemPowerMonitor' mdlRmsSystemPowerMonitorMod(vdvRMS,dvMaster);
Enabling this compiler directive will cause the System asset to register System Power asset parameter and control methods.
Next, you must implement the logic for what actions to take when the System Power status changes. You can use the event
subscription model to get notified when the system power state changes via callback methods invoked by the RmsEventListener.axi
Include File.
#DEFINE INCLUDE_RMS_EVENT_SYSTEM_POWER_REQUEST_CALLBACK
// THIS CALLBACK METHOD IS INVOKED AUTOMATICALLY WHEN
// RMS HAS REQUESTED THAT SYSTEM POWER BE CHANGED
DEFINE_FUNCTION RmsEventSystemPowerChanged(CHAR powerOn)
{
// IMPLEMENT LOGIC FOR SYSTEM POWER ON/OFF
}
This event subscriber and listener callback method are automatically provided for you
if you include the RmsSystemEventHandler.axi Include File.