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...............................................................
RMSCommon.axi .................................................................. 30 RMSDevMonRegisterCallback() ............................................... 30 RMSDevMonSetParamCallback()............................................. 31 RMS Engine module ............................................................. 31 RMS Device Monitoring Support Modules ............................ 34 RMSBasicDeviceMod ............................................................... 34 RMSProjectorMod...................
RMSUIMod Module............................................................... 63 Commands ............................................................................... 63 Module Definition ...................................................................... 64 Touch Panel Pages .................................................................. 65 RMSWelcomeOnlyUIMod Module ........................................ 66 Commands .............................................................................
Channels ................................................................................... 78 Module Definition ...................................................................... 79 Touch Panel Pages................................................................... 79 RMSSldProjMod Module....................................................... 79 Commands................................................................................ 79 Channels .......................................................
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.6 (or later) for G4 panels TPDesign 3 v3.
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
Upgrading from MeetingManager 1.0 Upgrading from MeetingManager 1.0 Basic Changes If you are currently running MeetingManager 1.0 NetLinx code, you should plan to migrate to the new RMS 2.0 SDK. The RMS 2.0 SDK offers a more flexible and complete API and improved reporting capabilities for the RMS Server administrator. In general, migrating from MeetingManager 1.0 SDK to RMS 2.0 SDK is a simple process. The RMS 2.
Upgrading from MeetingManager 1.0 files from the RMS 2.0 SDK directory to your project directory in order to compile. In addition, all "MM…" API functions and constants should be changed to use the "RMS…" function or constant, which is as simple as changing "MM" to "RMS". To avoid making these tedious changes, you could overwrite your existing MeetingManagerDeviceMonitor.axi from the MeetingManager 1.0 SDK with the MeetingManagerDeviceMonitor.axi from the RMS 2.0 SDK.
Upgrading from MeetingManager 1.0 If you did not use the worksheet, your code probably calls MMChangeParam() to notify MeetingManager of the Lamp Hours change. You will want to change your code from: MMChangeParam (dvProj,MM_PARAM_SET,Value) To RMSSetLampHours(dvProj,Value) Communication Timeout In MeetingManager 1.0, communication timeout for a source other than a Projector or a VCR was handled by creating a named device and a parameter for that device called "Device Communicating".
Upgrading from MeetingManager 1.0 30 seconds, or any value you set using RMSSetCommunicationTimeout (). If a string is not received within the timeout period, a loss of device communication is reported to the RMS server. If you are using RMS CodeCrafter output that imported the custom "Device communicating" parameter from a MeetingManager 1.0 worksheet, simply change the Module type for the device from "Custom (No Module)" to "Basic Device", and delete the "Device Communicating" parameter.
Upgrading from MeetingManager 1.0 RMSSrcUsageMod will extract the text after "Select " and register the remaining text as a custom source, Reel to Reel in this case. RMSSrcUsageMod will then monitor the channel specified in the ADD ACTION command, channel 1 in this case, and when the channel turns on, RMSSrcUsageMod will start a timer and time the usage of Reel to Reel. For more information i!-ConnectLinx programming, see the i!-ConnectLinx help file installed with the RMS SDK.
Upgrading from MeetingManager 1.0 When using RMSSrcUsageMod in Multisource mode, RMSSrcUsageMod does not assume sources are mutually exclusive, the OFF states are used to stop source usage timing and system off is ignored.
Upgrading from MeetingManager 1.0 Time Synchronization In MeetingManager 1.0, time synchronization for the master was accomplished by using i!-TimeManager. Starting with RMS 2.0, time synchronization is built into the RMS Suite. Each NetLinx system's time is automatically updated based on the RMS server's time while accounting for the time zone and Daylight Saving settings of the server and each room. If you are running RMS SDK 2.0, you no longer need to include i!-TimeManager in your program.
Upgrading from MeetingManager 1.0 Migrating from The Device Monitoring Worksheet to RMS CodeCrafter If you installed MeetingManager prior to version 2.1 you may have used the Device Monitoring Worksheet to generate your device monitoring code. All changes mentioned in Upgrading from MeetingManager 1.0 section on page 15 are still necessary but it is easier to do with the assistance of RMS CodeCrafter. To bring your worksheet into CodeCrafter for editing: 1. Dowload RMS CodeCrafter from AMX.
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 54 RMS NetLinx Programmer’s Guide
NetLinx Modules NetLinx Modules Non-RMS Modules KeyboardMod This is the keyboard module. This module is required by any module requiring on-screen text entry of data. RMSUIMod and RMSHelpUIMod require this module. For more information, see KeyboardMod (Readme).txt in the RMS SDK directory.
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 a String parameter. See above for 'ADD SPARAM-[DPS],[Name], [Units],[Threshold],[Status] description of all arguments. Units is a text string of the units to append to the ,[Reset],[Initial Value]' parameter value when displayed. 'ADD IPARAM-[DPS],[Name], [Units],[Threshold],[Status] ,[Reset], [Initial Value],[Enum List]' Add an Index parameter. See above for description of all arguments.
NetLinx Modules Commands and Descriptions (Cont.) 'DEBUG-CONNECT' Turn on debug. (including messages related to connection to RMS server) 'DEBUG-ON’ Turn on general debug. (no connection messages) 'DEBUG-OFF’ Turn off debug. (Default) 'VERSION’ Send version information to master debug port (master messaging) 'SERVICE-ON’ Turn on service mode. While in service mode, no errors will be reported. 'SERVICE-OFF’ Turn off service mode.
NetLinx Modules Strings RMSEngineMod listens for the following string from the vdvRMSEngine 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' RMSEngineMod sends the following strings to the vdvRMSEngine device. Strings and Descriptions 60 'REGISTER' Signifies that the RMS Engine module has connected to the RMS server. Upon receiving this string, it is safe to register devices and parameters.
NetLinx Modules Strings and Descriptions (Cont.) "'APPT LIST-[Date], [Total Appt], '[Binary Appt List]" The appointment list summary for Date. Total Appt provides the total number of appointments for Date. Binary Appt list is a character array with 48 entries, 1 for each ½ hour time slot for Date. The value in index 1 is the appointment index of the appointment that occupies the first ½ hour time slot (12:00am - 12:30 am). "'APPT-Index, '[Binary Data]" The appointment data for an individual appointment.
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 Commands RMSUIMod 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]:[00-59] 'DEBUG-ON' Turn on debug.
NetLinx Modules Module Definition DEFINE_MODULE 'RMSUIMod' mdlRMSUI(dvRMSEngine, vdvKB, dvKB, dvTp, dvTPWelcome) vdvRMSEngine: A virtual device for communicating to RMSEngineMod RMSEngineMod module vdvKB: The virtual device of the KeyboardMod module for editing text. dvKB: An array of touch panel base devices implementing RMSUIMod. dvTP: An array of main touch panel devices implementing RMSUIMod. If any of these panels are G3 panels, make sure the first panel in this array is a G3 panel.
NetLinx Modules Touch Panel Pages RMSUIMod requires the following touch panel pages for dvTP: mtgmMain mtmgMtgControl mtmgViewSchedule KBKeyboard RMSUIMod requires the following touch panel pop-up pages for dvTp: Touch Panel Pop-up Pages Popup Page Popup Group mtgmMeetingEndWarning N/A mtgmMeetingExtendWarning N/A mtgmHelpResponse N/A mtgmAppointmentDetails N/A mtgmViewSchedule1 mtgmViewSchedule mtgmViewSchedule3 mtgmViewSchedule mtgmMonthSelect mtgmMonthYear mtgmYearSelect mtgmMonthYear
NetLinx Modules RMSUIMod requires the following touch panel pages for dvTPWelcome: mtgmWelcomePage RMSUIMod requires the following touch panel pop-up pages for dvTp: Touch Panel Pop-up Pages Popup Page Popup Group mtgmAppointmentDetails N/A mtgmViewSchedule1 mtgmViewSchedule mtgmViewSchedule3 mtgmViewSchedule The RMS Welcome Screen (320x240).tpd file implements the welcome functionality in multiple pages without popups. See this file for more details.
NetLinx Modules Module Definition DEFINE_MODULE ' RMSWelcomeOnlyUIMod' mdlRMSUI(vdvRMSEngine, dvTPWelcome) vdvRMSEngine A virtual device for communicating to RMSEngineMod module. dvTPWelcome: An array of welcome touch panel devices implementing RMSUIMod. If any of these panels are G3 panels, make sure the first panel in this array is a G3 panel. This will instruct the module to use G3 compatible SEND_COMMAND's. All channel and variable text numbers are defined inside the module.
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.
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'). '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]' '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.
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.
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: J 10/06 ©2006 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.
