NetLinx Programmer’s Guide RMS Resource Management Suite® 3.
AMX Limited Warranty and Disclaimer AMX Corporation warrants its products to be free of defects in material and workmanship under normal use for three (3) years from the date of purchase from AMX Corporation, with the following exceptions: • • • • • • Electroluminescent and LCD Control Panels are warranted for three (3) years, except for the display and touch overlay components that are warranted for a period of one (1) year.
Software License and Warranty Agreement LICENSE GRANT. AMX grants to Licensee the non-exclusive right to use the AMX Software in the manner described in this License. The AMX Software is licensed, not sold. The AMX Software consists of generally available programming and development software, product documentation, sample applications, tools and utilities, and miscellaneous technical information. Please refer to the README.
Table of Contents Overview ............................................................................. 1 System Requirements ....................................................... 3 Concepts ............................................................................ 5 Network Configuration ............................................................. 5 Device Monitoring Framework ................................................ 7 Device Values ............................................................
Control Failure ...........................................................................32 Device Information ....................................................................32 Monitoring Source Usage ...................................................... 33 Source Select ............................................................................33 Monitoring Many NetLinx-connected Devices ....................... 35 RMSNLDeviceMod ...................................................................
Commands ............................................................................... 67 Module Definition ...................................................................... 67 Touch Panel Pages .................................................................. 68 RMSNLDeviceMod Module ................................................... 69 Commands ............................................................................... 69 Module Definition ....................................................
Commands ................................................................................80 Channels ...................................................................................80 Module Definition ......................................................................81 Touch Panel Pages ...................................................................81 i!-ConnectLinx .................................................................. 83 Using i!-ConnectLinx .......................................
Overview Overview The Resource Management Suite® products are PC server applications designed to manage rooms and equipment. The RMS server also monitors equipment in the rooms and sends notifications for room problems and help requests. The RMS server allows for the logging of room and device use, errors that occur, and offline events. The RMS server offers a variety of build-in reports for historical and statistical analysis, as well as device monitoring through a user extensible framework.
Overview 2 RMS NetLinx Programmer’s Guide
System Requirements System Requirements The RMS SDK is a set of NetLinx and TPDesign files that are included in your control system programs. To utilize this SDK, you will need the following applications installed: NetLinx Studio 2.5 (or later) TPDesign 4 v2.
System Requirements 4 RMS NetLinx Programmer’s Guide
Concepts Concepts Network Configuration The RMS application is a client/server application where the NetLinx system acts as the client and the RMS application server listens for connections from NetLinx systems. NetLinx and the RMS application server communicate using TCP/IP sockets. In order to establish communication, each NetLinx system must be able to resolve and connect to the RMS application server.
Concepts and each NetLinx system. In the RMS server, this is accomplished through the Configuration Wizard. In NetLinx, this is accomplished through the 'SERVER-' command in NetLinx programming. If using the ServerInfo.txt file, append a ":" and the port number to the server IP address or host name. MeetingManager 1.0 used port 9090 for communications. If you are upgrading from MeetingManager 1.0, you may wish to continue to use port 9090.
Concepts Device Monitoring Framework RMS provides device monitoring through a user extensible framework. This framework allows you to customize what devices are monitored, the conditions that indicate a problem or fault, and what type of problem or fault this condition represents. RMS generates notifications when a fault condition occurs, as determined by the notification configuration. Each room has one or more monitored devices.
Concepts Device Values Each monitored device has a set of values used in its description. These values are supplied when the device is registered and consist of the following: Device Values Device Number This is the device number of the device, as defined in the NetLinx program. Devices are tracked by Device ID so this value must be unique within the devices of a given room. For instance, you can have multiple "1:1:0" devices as long as there is only one device with a Device ID of "1:1:0" in the room.
Concepts Parameter Values Each parameter has a set of values used to determine what conditions indicate a problem and what type of problem this condition represents. These values are supplied when the parameter is registered and consist of the following: Parameter Values Name This is the name of parameter. This name is displayed on the RMS server console and readily identifies the parameter. Parameters are tracked by name so this name must be unique within the parameters of a given device.
Concepts Parameter Values Status Type The status represents the type of problem a faulted condition represents. Status Types include "Help Request", "Maintenance Request", "Room Communication Error", "Control System Error", "Network Error", "Security", and "Equipment Usage." For example, when "Lamp Hours" changes from an un-faulted (not greater than 1000) to a faulted (greater than 1000), this change represents a "Maintenance Request" status that requires an AV technician to repair the equipment.
Concepts Status Types RMS supports the following status types for device monitoring: "Help Request", "Maintenance Request", "Room Communication Error", "Control System Error", "Network Error", "Security", and "Equipment Usage." While there are no firm rules for what these status types mean and how they are used, AMX provides the following description of each status type and recommends that your usage is consistent with these descriptions.
Concepts Notification Process As NetLinx sends parameter updates to the RMS server, the RMS server checks to see if the parameter's threshold value has been reached. This comparison is made by checking the previous value of the parameter against the threshold and by checking the new version of the parameter against the threshold using the threshold comparison operator. If the comparison for the old value is False and the comparison for the new value is True, then the parameter triggers an Alert message.
Concepts change results in an Alert message being logged using the RMS logging settings. Also, a message is sent to all users registers for a notification matching the parameters group, room and status type. If the Lamp Hours changes from 1001 to 999, the RMS server triggers an Advise message. If the parameter is configured to send Advise messages, the message is sent to the log and to all users registered for a notification matching the parameters group, room, and status type.
Concepts 14 RMS NetLinx Programmer’s Guide
Getting Started Getting Started In order to monitor devices from an RMS system, you will need to add programming to your NetLinx project. Only the devices and parameters that you register from NetLinx can be monitored; the administrator cannot add parameters from the RMS console. While all of the device monitoring programming can be done manually, RMS CodeCrafter can generate code for your project.
Getting Started Projector (RMSProjectorMod): Device Online/Offline, Power, Lamp Hours, Communication Status for Serial devices, Control Failure (Optional), IP Address of Socket-based devices. Transport (RMSTransportMod): Device Online/Offline, Power, Run Time, Communication Status for Serial devices, Control Failure (Optional), IP Address of Socket-based devices.
Getting Started Interfacing with the RMS SDK Once you have used RMS CodeCrafter to generate the device monitoring code for your system, you will need to communicate device status to the RMS support modules. First, you will need to notify RMS when the system power is turned on and off.
Getting Started Where DeviceIdentifier is the identifier for the real device, such as dvProj, and Value is the lamp hour's value. For transport devices, you will need to notify RMS when the transport state changes. If you are using an AMX Comm module to communicate to your device, the RMSTransportMod will communicate with the Comm module to determine transport state automatically. If you are using an AMX system call with no feedback offset, i.e.
Getting Started Service Mode RMS supports a service mode where no errors will be reported. Service mode is designed to allow a technician to work on a room without causing error reports. For instance, if a projector needs to be replaced or serviced, RMS would report Device Not Communicating when the technician disconnected the power cable or communication cable. To prevent this error from being reported to RMS, put RMS in service mode using the 'SERVICE-ON' command.
Getting Started To clear out all monitored devices and parameters, delete the room and then add the room back. Deleting a room from RMS deletes all associated monitored devices and parameters from the RMS server. Optionally, you can delete a device or a parameter from the RMS console provided the device is not the "System" device and the parameter is not one of its parameters.
Custom Device Monitoring Programming Custom Device Monitoring Programming The RMS SDK is made up of a series of modules and include files. The following diagram is a visual description of the architecture of the RMSMain.axi and the RMS support modules: FIG. 2 Architecture of The RMSMain.
Custom Device Monitoring Programming RMSCommon.axi RMSCommon.axi is an included file designed to help perform many device monitoring tasks. This file provides device-monitoring constants, functions that generate device monitoring SEND_COMMANDs to RMS, as well as providing a "callback" function for important device monitoring RMS events. In order to use this include file, your program will need to define the RMS device and a couple of functions.
Custom Device Monitoring Programming RMSDevMonSetParamCallback() The function is called when the RMS administrator chooses "Reset" for a parameter that can be reset on the RMS console. You can determine which parameter was reset by checking the value of dvDPS and cName. All parameters values are sent as a string so you will need to convert it appropriately.
Custom Device Monitoring Programming standard power channels and provide feedback to i!-ConnectLinx for system power, this information will automatically be read by RMS. See the RMS engine module definition for details about the module and its parameters.
Custom Device Monitoring Programming ON: { SWITCH (CHANNEL.CHANNEL) { CASE 1: RMSSetRackPowerRackPower(1) break } } // Channel Off OFF: { SWITCH (CHANNEL.
Custom Device Monitoring Programming RMS Device Monitoring Support Modules Next, you will want to consider adding RMS device monitoring support modules for monitoring basic devices. Adding these support modules will handle most of the monitoring requirements for these devices. RMS offers the following support modules: RMSBasicDeviceMod This module monitors basic devices. For each device, this module will register and monitor online/offline status, communication status, control failure, and power.
Custom Device Monitoring Programming RMSProjectorMod This module monitors projectors. For each projector, this module will register and monitor online/offline status, communication status, control failure, power, and lamp hours. Communication status is registered only if the device is a twoway device. This includes serial devices and IP sockets. Control failure is registered only if enabled via a SEND_COMMAND, and is based on the ability to control power.
Custom Device Monitoring Programming RMSTransportMod This module monitors transport devices. For each transport device, this module will register and monitor online/offline status, communication status, power, and run time. Communication status is registered only if the device is a two-way device. This includes serial devices and IP sockets. Control failure is register only if enabled via a SEND_COMMAND, and is based on the ability to control power.
Custom Device Monitoring Programming RMSSldProjMod This module monitors slide projectors. For each projector, this module will register and monitor online/offline status, power, and lamp hours. Lamp hours are determined by counting the time that the device's power is On. The following diagram is a visual description of the architecture of the RMSSldProjMod module: FIG.
Custom Device Monitoring Programming Programming These modules require a virtual device, the real device of the device to be monitored, and the RMS Engine module's device. If you are using an AMX module for communicating with a device, the virtual device used for the Comm module can be passed to the device monitoring support module. Since the support modules are written to listen for the messages for the particular device types they support, no additional programming is needed.
Custom Device Monitoring Programming Notify Modules Turn Power On: RMSSetDevicePower(dvProj,TRUE) SEND_STRING vdvVPROJ,'POWER=1' PULSE[vdvVPROJ,27] ON[vdvVPROJ,255] Turn Power Off: RMSSetDevicePower(dvProj,FALSE) SEND_STRING vdvVPROJ,'POWER=0' PULSE[vdvVPROJ,28] OFF[vdvVPROJ,255] Set Lamp Hours RMSSetLampHours(dvProj,Value) SEND_STRING vdvVProj,'LAMPTIME=Value' Set Transport State (1=Play, 2=Stop, etc…): RMSSetTransportState(dvVCR,State) SEND_STRING vdvVCR, 'TRANSPORT=State' PULSE[vdvVCR,State+240]
Custom Device Monitoring Programming as both the virtual and real device of the support module. However, in this case, you cannot use SEND_STRING for notifying the module of transport state. You may notice that for transport state, you can pulse a channel between 241-248 to set the transport state. Since AMX SYSTEM_CALLs use those channels to store transport state, no additional programming is needed to send transport state to the module when using a SYSTEM_CALL.
Custom Device Monitoring Programming } } The RMSSetDeviceInfo () is defined in the RMSCommon.axi include file. Monitoring Source Usage RMS can monitor source usage by using the RMSSrcUsageMod module. RMSSrcUsageMod will track the amount of time, in minutes, a given source is selected and logs this information to RMS when a new source is selected. This information can be used to generate reports to determine the actual usage of a device in a room.
Custom Device Monitoring Programming be registered as a custom source. For instance, a custom action called "Select Slide To Video" will register a source called "Slide To Video.
Custom Device Monitoring Programming FIG. 7 Architecture of The RMSSrcUsageMod Module Monitoring Many NetLinx-connected Devices RMSNLDeviceMod This module monitors one or more NetLinx-connected devices. For each device, the module will register and monitor the online/offline status. This module provides a very simple way to monitor NetLinx-connected devices. However, it does not allow the naming of these devices.
Custom Device Monitoring Programming DEFINE_MODULE 'RMSNLDeviceMod' mdlNLD(dvMonitoredDevices, vdvRMSEngine) The following diagram is a visual description of the architecture of the RMSNLDeviceMod module: FIG.
Custom Device Monitoring Programming Monitoring A Single NetLinx-connected Device The RMSCommon.axi include file provides two functions that help to monitor the Online/Offline status of a NetLinx connected device. You can use these functions to monitor a device like a touch panel or bus box. These two functions are: RMSNetLinxDeviceOnline(dvDPS, cName) RMSNetLinxDeviceOffline(dvDPS) RMSNetLinxDeviceOnline() will register the device and the online/offline parameter as well as set the parameter to online.
Custom Device Monitoring Programming Registering Devices The RMSCommon.axi include file provides some simple functions for registering devices. The functions can be used in the RMSDevMonRegisterCallback() function, called when RMS engine module connects to the RMS server. These functions generate SEND_COMMANDs, which you can generate manually. However, using these functions may help eliminate syntax issues.
Custom Device Monitoring Programming The combination of Number and String parameters types and enumeration lists provide four unique kinds of parameters to the NetLinx program. These are: Registering Parameters Number Parameter Number parameters are parameters of type number with no enumeration list. These are commonly used for values that are programmatically available and displayed in numeric form. Examples of number parameters are projector lamp hours and VCR run time.
Custom Device Monitoring Programming The include file provides four functions for registering these parameters.
Custom Device Monitoring Programming RMSRegisterDeviceEnumParam(dvDPS, cName, cThreshold, nThresholdCompare, nThresholdStatus, bCanReset, cResetValue, nInitialOp, cInitial, cEnumList) Optionally, you can register a parameter with a Unit field. The Units field will be displayed next to the parameter value and threshold. You might want to use a Unit field to add a "V" if you or monitoring voltage or "%" if you are monitoring percentage.
Custom Device Monitoring Programming RMSRegisterDeviceStringParamWithUnits(dvDPS, cName, cUnits, cThreshold, nThresholdCompare, nThresholdStatus, bCanReset, cResetValue, nInitialOp, cInitial) This function will need to be called in two places. Call RMSRegisterDevicexxxParam () in the RMSDevMonRegisterCallback() function to make sure it is registered when the RMS engine module connects to the RMS server. Also, call RMSRegisterDevicexxxParam () when the NetLinxconnected device reports online.
Custom Device Monitoring Programming RMS_STAT_NOT_ASSIGNED (1), RMS_STAT_HELP_REQUEST (2), RMS_STAT_ROOM_COMM_ERR (3), RMS_STAT_CONTROLSYSTEM_ERR (4), RMS_STAT_MAINTENANCE (5), RMS_STAT_EQUIPMENT_USAGE (6), RMS_STAT_NETWORK_ERR (7), RMS_STAT_SECURITY_ERR (8). One of these values classifies a fault with this parameter as a Help Request, Room Communication Error, Control System Error, Maintenance, Equipment usage, Network Error, or Security issue.
Custom Device Monitoring Programming enumeration list. For Number parameters, slMin and slMax define the range the value is expected to have. For Index and Enum, cEnumList contains the allowed values of the parameter. Setting Parameter Values You can set a parameter value any time after the RMS engine module has connected to the RMS server. Before setting the value of a parameter, the parameter must be registered. When registering parameters, you can supply the initial value.
Custom Device Monitoring Programming element in cEnum, supplied during registration, is index 0, the second element is index 1, etc... Most commonly, you will use the RMS_PARAM_SET (0) operation. However, there may be instances where you want to simply allow the database to keep track of the value and notify it of changes only. In these cases RMS_PARAM_INC (1) and RMS_PARAM_DEC (2) are useful for adding and subtracting a value from the current value in the database.
Custom Device Monitoring Programming 46 RMS NetLinx Programmer’s Guide
Custom "Scheduling Only" Programming Custom "Scheduling Only" Programming If you wish to only utilize the scheduling features of RMS, the RMS SDK can be optimized by only including the necessary RMS modules in your NetLinx program. RMS is capable of supporting multiple (up to 12) instances of Scheduling on a single NetLinx Master. If you intend to run multiple instances of Scheduling on a Master, then that Master should be dedicated solely to RMS Scheduling only.
Custom "Scheduling Only" Programming Custom "Scheduling Only" Programming RMS modules (Cont.) 48 RMSHelpUIMod No This module is not required for RMS scheduling. RMSNLDeviceMod No This module is not required for RMS scheduling. RMSProjectorMod No This module is not required for RMS scheduling. RMSTransportMod No This module is not required for RMS scheduling. RMSBasicDeviceMod No This module is not required for RMS scheduling.
NetLinx Modules NetLinx Modules RMSEngineMod Module Commands Strings Channels Levels Module Definition RMS NetLinx Programmer’s Guide 49
NetLinx Modules Commands RMSEngineMod listens for the following commands from the vdvRMSEngine device. Commands and Descriptions 'SERVER-[IP/Hostname]' Set the address of the RMS server. A port can be specified by adding a colon (:) and a port number to the end of the IP address or host name. For example, you can set the port to 10501 using this command: '192.168.1.1:10501'. '?SERVER' Request the current server settings from the module.
NetLinx Modules Commands and Descriptions (Cont.) Status can be any of the following: • NONE or 1 - Not assigned • HELP or 2 - Help Request • ROOM or 3 - Room Communication Error • CONT or 4 - Control System Error • MAIN or 5 - Maintenance Error • USAG or 6 - Equipment Usage • NETW or 7 - Network Error • SECU or 8 - Security Error Reset can be any reset value or 'NO RESET' for no reset.
NetLinx Modules Commands and Descriptions (Cont.) 'ADD NPARAM2[DPS],[Name],[Units], [Track Changes], [Threshold],[Status], [Reset],[Initial Value], [Min],[Max]' Add a Number parameter with unit of measurement and/or history tracking. Units is a text string of the units to append to the parameter value when displayed. Track Changes can be a value of '1' to enable or a value of '0' to disable historical parameter value tracking.
NetLinx Modules Commands and Descriptions (Cont.) 'SET PARAM[DPS],[Name],[Value]' Set a parameter value. DPS must be in string form (ex: '5001:1:0'). Value can be one of the following: • Value - Set Value • +=Value - Increment by Value • -=Value - Decrement by Value • *=Value - Multiply by Value • \=Value - Divide by Value • /=Value - Divide by Value • RESET - reset the value • NOCHANGE - do not change the value. 'HELP-[Help Message]' Send a help request.
NetLinx Modules Commands and Descriptions (Cont.) 'IGNORE SERVER TIME UPDATE' Normally, NetLinx receives a time update from the RMS server. This command tells the module to ignore these time updates. ‘RESERVE[StartDate],[StartTime],[Dura tion],[Subject], [] Requests the RMS server to add an ac-hoc appointment on behalf of the room. [StartDate] should be formatted as ‘mm/dd/yyyy’ [StartTime] should be formatted as ‘hh:mm’ [Duration] is the number of minutes the meeting should be scheduled.
NetLinx Modules Commands and Descriptions (Cont.) ‘ENDNOW’ End the current appointment/meeting immediately. Upon receipt, the RMS Server will process this request and return a confirmation or error ‘ENDNOW-‘ string. Please see the Strings API page for further information of the returned server response. The ‘ENDNOW’ command is supported when using the RMS internal scheduling system or when using Microsoft Exchange. Strings RMSEngineMod listens for the following string from the vdvRMSEngine device.
NetLinx Modules Strings and Descriptions (Cont.) 56 'CHANGE-[Date1,Date2, Date3,...]' A message indicating that appointments have been changed for the following dates. Dates are comma separated and in the format MM/DD/YYYY. "'APPT COUNT[Month],[Year], '[Binary Array]" The appointment count for Month and Year. Binary Array is a character array that contains the counts for each day as binary value where the first element in the array is for the first day of Month.
NetLinx Modules Strings and Descriptions (Cont.) ‘RESERVEYES,[StartDate],[Star tTime],[Duration],[Su bject] A “RESERVE’ appointment/meeting request command succeeded. [StartDate] is formatted as ‘mm/dd/yyyy’ [StartTime] is formatted as ‘hh:mm’ [Duration] is the number of minutes the meeting is scheduled for. [Subject] meeting subject text. ‘RESERVENO,[StartDate],[Start Time],[Duration],[Sub ject],[ErrorMessage] A “RESERVE’ appointment/meeting request command failed or was rejected by the server.
NetLinx Modules Channels 9 - Toggle System Power State 27 - Set system power to ON 28 - Set system power to OFF 100 - Run Preset for Current Appointment 250 - RMS Server Online 251 - Dynamic Images Enabled Levels 1 - Current Appointment Index 2 - Minutes Remaining In Appointment 3 - Next Appointment Index 4 - Minutes Until Next Appointment 5 - First Appointment Index 6 - Last Appointment Index 7 - Number of Appointment Remaining today Module Definition DEFINE_MODULE 'RMSEngineMod' mdlRMSEng(vdvRMSEngine, d
NetLinx Modules RMSUIMod Module Commands Module Definition Touch Panel Pages Constants Commands RMSUIMod listens for the following commands from the vdvRMSEngine device.
NetLinx Modules dvTP_Base: An array of main touch panel base devices addresses that correspond with the main touch panel devices defined in the dvTP device array. This base device array is used to capture keyboard string data events from the main touch panels. If the RMS pages and buttons are defined on the base device address (Port 1) then the same device array used for the dvTP parameter can also be used for this parameter.
NetLinx Modules Touch Panel Pages RMSUIMod requires the following touch panel pages for dvTP: Main - user defined room control page.
NetLinx Modules RMSUIMod requires the following touch panel pages for dvTPWelcome: rmsSplashPage - panel start-up page rmsWelcomePage - RMS outside room welcome panel (electronic signage panel) RMSUIMod requires the following touch panel pop-up pages for dvTPWelcome: Touch Panel Pop-up Pages Popup Page 62 Popup Group rmsAbout NA rmsDoNotDisturb NA rmsServerOffline NA rmsMeetingDetails rmsDialogs rmsMeetingDoesNotExist rmsDialogs rmsMeetingEndConfirmation rmsDialogs rmsMeetingInfo rmsDialogs
NetLinx Modules Constants The following constants are defined in the RMSUIMod.axs file: Constants Constant __RMS_UI_NAME__ Description RMS module name. This constant should not be modified. __RMS_UI_VERSION__ RMS module version. This constant should not be modified. RMS_BEEP_DOORBELL_REQUEST Panel Beep on Doorbell button push from outside welcome touch panel. 1 = ENABLED / 0 = DISABLED RMS_BEEP_DOORBELL_RECEIPT Panel Beep on Doorbell signal on in room touch panel.
NetLinx Modules RMSWelcomeOnlyUIMod Module Commands Module Definition Touch Panel Pages Constants Commands RMSWelcomeOnlyUIMod listens for the following commands from the vdvRMSEngine device. Commands and Descriptions 'DFORMAT-DAY/MONTH' Set Date format European format: Day/Month/Year. 'DFORMAT-MONTH/DAY' Set Date format US format: Month/Day/Year. 'TFORMAT-12 HOUR' Set Time format to 12 hour format: [01-12]:[00-59] [AM,PM]. 'TFORMAT-24 HOUR' Set Time format to 24-hour (military) format: [00-23]:[0059].
NetLinx Modules vdvRMSEngine: A virtual device for communicating to RMSEngineMod module. RMS_MEETING_DEFAULT_SUBJECT: A character array/string that defined the default subject text for meeting appointments scheduled form the touch panel. RMS_MEETING_DEFAULT_MESSAGE: A character array/string that defined the default message body text for meeting appointments scheduled form the touch panel. All channel and variable text numbers are defined inside the module.
NetLinx Modules Constants The following constants are defined in the RMSWelcomeOnlyUIMod.axs file: Constants Constant __RMS_UI_NAME__ Description RMS module name. This constant should not be modified. __RMS_UI_VERSION__ RMS module version. This constant should not be modified. RMS_BEEP_DOORBELL_REQUEST Panel Beep on Doorbell button push from outside welcome touch panel. 1 = ENABLED / 0 = DISABLED RMS_BEEP_DOORBELL_RECEIPT Panel Beep on Doorbell signal on in room touch panel.
NetLinx Modules RMSHelpUIMod Module Commands Module Definition Touch Panel Pages Commands RMSHelpUIMod listens for the following commands from the vdvRMSEngine device.
NetLinx Modules All channel and variable text numbers are defined inside the module. If you need to change them, edit the module and re-compile the module and your program. Touch Panel Pages RMSHelpUIMod requires the following touch panel pages for dvTP: Main - user defined room control page.
NetLinx Modules RMSNLDeviceMod Module Commands Module Definition Commands RMSNLDeviceMod listens for the following commands from the vdvRMSEngine device. Commands and Descriptions 'VERSION’ Send version information to master debug port (master messaging) Module Definition DEFINE_MODULE 'RMSNLDeviceMod' mdlNLD(dvMonitoredDevices, vdvRMSEngine) Where mdlNLD is a unique module name. dvMonitoredDevices An array of NetLinx-connected devices to monitor.
NetLinx Modules RMSProjectorMod Module Commands Strings Channels Module Definition Commands RMSProjectorMod listens for the following commands from the vdvRMSEngine device. Commands and Descriptions Set device information for device monitoring. 'DEV INFO[DPS],[Name],[Man],[Model]' DPS must be in string form (ex: '5001:1:0'). 70 'DEV NAME-[DPS],[Name]' Set device name for device monitoring. DPS must be in string form (ex: '5001:1:0').
NetLinx Modules Strings RMSProjectorMod listens for the following strings from the vdvProjModule device. Strings and Descriptions 'POWER=[Power State]' Set the system power state. [PowerState] should be 0 for off and 1 for on. 'LAMPTIME=[Value]' Set the projector lamp hours. 'MODEL=[Model]' Set the model number. Example: 'POWER=1' Example: 'LAMPTIME=200' 'MANUFACTURER=[Manufacturer]' Set the manufacturer name.
NetLinx Modules Module Definition DEFINE_MODULE 'RMSProjectorMod' mdlProj1(vdvProjModule, dvProj, vdvRMSEngine) Where mdlProj1is a unique module name. vdvProjModule A virtual device for communicating to RMSProjectorMod. This can be the same virtual device used to communicate with an InConcert module or a physical projector. If controlling the projector or display using an IR device, pass the physical device to this parameter.
NetLinx Modules RMSTransportMod Module Commands Strings Channels Module Definition Commands RMSTransportMod listens for the following commands from the vdvRMSEngine device. Commands and Descriptions 'DEV INFO[DPS],[Name],[Man], [Model]' Set device information for device monitoring. DPS must be in string form (ex: '5001:1:0'). 'DEV NAME-[DPS],[Name]' Set device name for device monitoring. DPS must be in string form (ex: '5001:1:0').
NetLinx Modules Strings RMSTransportMod listens for the following strings from the vdvVCRModule device. Strings and Descriptions 'POWER=[Power State]' Set the system power state. [PowerState] should be 0 for off and 1 for on. Example: 'POWER=1' 'TRANSPORT=[Transport State]' Set the system power state. Transport State can be 2 for Stop or any other value for a non-stopped condition. Any value other than 2 will enable the run-time counter. 'MODEL=[Model]' Set the model number.
NetLinx Modules Channels The module watches for these channels on the vdvVCRModule device. 9 - Toggle System Power State 27 - Set system power to ON 28 - Set system power to OFF 254 - Power failure. 255 - Power Status. The module watches for these channels on the dvVCR device. 241 - Set transport state to play. 242 - Set transport state to stop. 243 - Set transport state to pause. 244 - Set transport state to fast forward. 245 - Set transport state to rewind. 246 - Set transport state to search forward.
NetLinx Modules Touch Panel Pages This module requires no pages. RMSBasicDeviceMod Module Commands Strings Channels Module Definition Commands RMSBasicDeviceMod listens for the following commands from the vdvRMSEngine device. Commands and Descriptions Set device information for device monitoring. DPS must be 'DEV INFO[DPS],[Name],[Man] in string form (ex: '5001:1:0'). ,[Model]' 76 'DEV NAME[DPS],[Name]' Set device name for device monitoring. DPS must be in string form (ex: '5001:1:0').
NetLinx Modules Strings RMSBasicDeviceMod listens for the following strings from the vdvModule device. Strings and Descriptions 'POWER=[Power State]' Set the system power state. [PowerState] should be 0 for off and 1 for on. 'MODEL=[Model]' Set the model number. Example: 'POWER=1' 'MANUFACTURER=[Manufacturer]' Set the manufacturer name. Any string received from the physical device, dvDevice, is an indication that the device is communicating.
NetLinx Modules Module Definition DEFINE_MODULE 'RMSBasicdeviceMod' mdBasicDev1(vdvModule, dvDevice, vdvRMSEngine) Where mdlBasicDev1is a unique module name. vdvModule A virtual device for communicating to RMSBasicDeviceMod. This can be the same virtual device used to communicate with an InConcert module or a physical device. If controlling the device using an IR device, pass the physical device to this parameter. dvDevice A physical device or socket device to which the virtual device is connected.
NetLinx Modules Channels The module watches for these channels on the dvSldProj device. 5 - Slide Projector Power State Module Definition DEFINE_MODULE 'RMSSldProjMod' mdlSldProj1(dvSldProj, vdvRMSEngine) Where mdlSldProj1is a unique module name. dvSldProj A physical device to which the slide projector is connected. vdvRMSEngine A virtual device for communicating to RMSEngineMod module. Touch Panel Pages This module requires no pages.
NetLinx Modules RMSSrcUsageMod Module Commands Channels Module Definition Commands RMSSrcUsageMod listens for the following commands from the vdvRMSEngine device. Commands and Descriptions 'MULTISOURCE-[State]' Set the multi-source tracking state. State can be ON or OFF. The default is OFF. 'VERSION’ Send version information to master debug port (master messaging) Channels The module watches for these channels on the vdvConnectLinx device.
NetLinx Modules 1023 - Aux Video Select 1024 - Slide Select 1025 - Digital Media Player Select 1041 - Music Select 1042 - CD Select 1043 - Cassette Select 1044 - DAT Select 1045 - Mini Disc Select 1046 - Aux Audio Select 1047 - Digital Audio Player Select RMSSrcUsageMod will also listen for i!-ConnectLinx registration of custom actions and attempt to determine if they represent source selects. Any custom action registered with a name that starts with "Select " is assumed to be a custom source.
NetLinx Modules 82 RMS NetLinx Programmer’s Guide
i!-ConnectLinx i!-ConnectLinx i!-ConnectLinx™ is a framework that allows you to expose NetLinx™ actions that can be utilized by other user interfaces or processes outside the NetLinx Control System. For instance, i!-ConnectLinx can be programmed to expose source select functions and i!-ConnectLinx compatible technologies, such as RMS, can use this information to allow the source selects to be executed as a scheduled event.
i!-ConnectLinx Using i!-ConnectLinx Little work is required to add i!-ConnectLinx to your existing NetLinx code. i!-ConnectLinx is implemented as a NetLinx module. Adding the module definition and all its parameters to your code is all that is required. In order to use i!-ConnectLinx, you need to program and define a series of actions in the NetLinx Control System. The key to the i!-ConnectLinx engine is the virtual device, vdvCLActions. For additional information reference the Module section on page 95.
i!-ConnectLinx PULSE{VCR,2] } } When the i!-ConnectLinx engine gets a request to play the VCR, i!-ConnectLinx will "push" the button of the virtual device just like a user pushes a button on a touch panel. There is now only one thing left to do: Tell the user which actions are which. In order to expose an action for execution via i!-ConnectLinx, you need to support the programming for the action, as we have just seen, and you need to tell i!-ConnectLinx what that action is.
i!-ConnectLinx Standard Actions So far, i!-ConnectLinx has handled custom actions where each action is likely to be different from system to system. In the Using i!-ConnectLinx example on page 84, action 1 played the VCR. However, in another system, it is very unlikely that action 1 plays the VCR. i!-ConnectLinx uniquely identifies each action list.
i!-ConnectLinx { ONLINE: { (* Setup actions *) (* VCR Play *) SEND_COMMAND vdvCLActions,"'ADD STD-1131'" (* VCR Stop *) SEND_COMMAND vdvCLActions,"'ADD STD-1132'" } Additionally, change the two BUTTON_EVENTs to trigger for channels 1131 and 1132 instead of 1 and 2. There are other syntax’s of the add standard action command that allow you add multiple actions at a time. The ‘&’ character can be used to signify "AND" and the ‘-‘ character can be used to signify "through".
i!-ConnectLinx Generator page. On this page, you can enter the i!-ConnectLinx device, the Touch Panel device and the Touch Panel buttons for each standard action. The code generator will create an Include (AXI) file that contains the necessary code to register and respond to the selected actions. Optionally, the code generator can include the DEFINE_MODULE statement for i!-ConnectLinx.
i!-ConnectLinx be retrieved by using LEVEL_EVENTs and DATA_EVENTs in your program and must be saved. Then, when an action request is triggered via a BUTTON_EVENT, you can retrieve these argument values and use them (as appropriate) for the action to be executed. Each argument is provided an ID at the time it is added. The ID’s start at one and are numbered sequentially to each argument as they are added. When i!-ConnectLinx posts the argument value, it supplies the ID number as well.
i!-ConnectLinx names and URL’s of each of these files and rename it to i!-ConnectLinx. Now anyone can retrieve an action list for the company’s system by pointing to the company’s main web address and selecting a room file from the list. If desired, the action list index file can be viewed in an HTML browser by using an eXtensible Style Language file. A web developer can make any adjustments to the XSL file so the index file has the look of the company’s web site when viewed in an HTML browser.
i!-ConnectLinx 1. Open this file in NetLinx Studio™. 2. Alter the text to support the language you choose. 3. Compile and download this file to a NetLinx Master. The i!-ConnectLinxStdText.xml is written out to the doc:\user\connectlinx directory. Once this file has been created once, it can be FTP’d to the NetLinx Master and placed in the doc:\user\connectlinx directory. When i!-ConnectLinx starts up, the text is read from this file and used for all standard actions.
i!-ConnectLinx Commands i!-ConnectLinx supports the following out-bound commands (Master to device). The commands are sent in the standard Send_Command format: SEND_COMMAND dvMP, "'SET ROOM NAME-Tesla'" SEND_COMMAND dvMP, "'ADD MACRO-vcr'" i!-ConnectLinx Commands 'SET ROOM INFO-[Room Name], [Room Location], [Room Owner]' Sets the room name, room location, and room owner to be displayed in the action list file. 'SET ROOM NAME-[Room Name]' Sets the room name to be displayed in the action list file.
i!-ConnectLinx i!-ConnectLinx Commands (Cont.) 'ADD LARG-[Action],[Arg Name],[Min],[Max],[Step], [Default]' Adds a level argument to Action. The Arg Name (Argument Name) is required. The Min and Max define the limits for this argument in the range – 32767 to 32767. The Step defines the minimum step between increments/decrements. The Default value defines the initial value this argument is set to when the user edits this argument. Adds a string argument to Action.
i!-ConnectLinx Strings i!-ConnectLinx supports the following in-bound string (device to Master). i!-ConnectLinx Strings String Description "'ARG[Argument ID]-[Argument String]'" Argument String for string and enum arguments for an action executed soon. 'PARENT-[Name],[Child Count],[Parent]' Describes a parent node. Returned by GET NODE command. 94 'CHILD[Child#]-[Name], [ChildCount],[Parent]' Describes a child of a node. Returned by GET NODE command.
i!-ConnectLinx Module The i!-ConnectLinxEngineMod Module definition code is displayed below. DEFINE_MODULE 'i!-ConnectLinxEngineMod' mdlCL(vdvCLActions) Where mdlCL is a unique module name. i!-ConnectLinxEngineMod Module Parameter vdvCLActions A virtual device number for programming NetLinx actions.
i!-ConnectLinx i!-ConnectLinx Standard Function List (Cont.
i!-ConnectLinx i!-ConnectLinx Standard Function List (Cont.
i!-ConnectLinx i!-ConnectLinx Standard Function List (Cont.
i!-ConnectLinx i!-ConnectLinx Standard Function List (Cont.
i!-ConnectLinx i!-ConnectLinx Standard Function List (Cont.
i!-ConnectLinx i!-ConnectLinx Standard Function List (Cont.
i!-ConnectLinx i!-ConnectLinx Standard Function List (Cont.
i!-ConnectLinx i!-ConnectLinx Standard Function List (Cont.
i!-ConnectLinx i!-ConnectLinx Standard Function List (Cont.
i!-ConnectLinx i!-ConnectLinx Standard Function List (Cont.
i!-ConnectLinx 106 RMS NetLinx Programmer’s Guide
Multiple RMS Instances Multiple RMS Instances RMS supports multiple instances loaded on 1 NetLinx master. There can either be 4 instances controlling and monitoring as many devices that may be physically connected to one master, or 12 instances scheduling and displaying with no devices other than touch panels. There is an example of multiple instance programming included in the RMS SDK, RMS (Multi-Instance).apw.
Multiple RMS Instances vdvProjModule_2 dvProj_2 = 33012:1:0 = 5002:1:0 (* Projector Virtual Device *) (* Projector Real Device *) vdvSWTModule_2 dvSWT_2 = 33013:1:0 = 5002:2:0 (* Switcher Virtual Device *) (* Switcher Real Device *) vdvVCRModule_2 dvVCR_2 = 33014:1:0 = 5002:9:0 (* VCR Virtual Device *) (* VCR Real Device *) dvRELAY_2 = 5002:8:0 (* NI-3000 Relay *) The rest of the multi instance information is in the include file RMSMain-Multi.axi in the SDK.
Multiple RMS Instances Module Defining Each instance must define it's own modules, which directly affects how many instances can be run (memory constraint). The example uses two instances. /////////////////////////////////////////////////////////////// // 1st RMS instance...
Multiple RMS Instances // Display DEFINE_MODULE 'RMSProjectorMod' mdlProj_2(vdvProjModule_2, dvProj_2, vdvRMSEngine_2) // RMSEngineMod - The RMS engine. Requires i!ConnectLinxEngineMod. DEFINE_MODULE 'RMSEngineMod' mdlRMSEng_2(vdvRMSEngine_2, dvRMSSocket_2, vdvCLActions) // RMSUIMod - The RMS User Interface. Requires KeyboardMod.
Multiple RMS Instances Stacking Events and Handling Them Because the rest of the code (common include, and others) is single instance driven, there is a switch going on for every event. Determine who is raising the event and then switch the global RMSEngine to the engine the event is coming from. The example uses a shared function SetEngine(engine instance) to do the dirty work. Each event checks to see who raised it and sets the correct instance for the rest of the work.
Multiple RMS Instances 112 RMS NetLinx Programmer’s Guide
NetLinx Modules RMS NetLinx Programmer’s Guide 113
It’s Your World - Take Control™ 3000 Research Drive, Richardson, TX 75082 USA • 800.222.0193 • 469.624.8000 • 469-624-7153 fax • 800.932.6993 technical support • www.amx.com 93-3002-04 REV: L 9/07 ©2007 AMX. All rights reserved. AMX and the AMX logo are registered trademarks of AMX. AMX reserves the right to alter specifications without notice at any time.
