Brand:

• AMX

Models:

• NetLinx NX Controllers
• MUSE Controllers

Overview:

This document discusses how to utilize an NX controller as a proxy for an MU controller to connect and communicate to RMS.  The biggest hurdle in this configuration is the need to monitor the amount of traffic that is put through the NX at any given time.  The biggest influx of information is when the NX has been registered to an RMS location and the asset registration process begins.  At that point it becomes an exponential problem depending on the number of assets, parameters, metadata, etc.

In this implementation, the NX is utilized as a traffic cop to tell MU controllers when it is safe to proceed with their registration.  The proof of concept for this implementation utilized 20 MU controllers connected to a single NX controller.  Each MU registered 10 assets and each asset had 2 parameters assigned to it.  From that point, each MU would update 5 parameters every 10 seconds.

This communication with RMS was purposefully made far 'busier' than any normal system would be to stress test the NX.  Even at the busiest times, CPU usage on the NX never rose above 50%.  Once registration is completed, NX CPU usage averages around .8% per MU connected to the NX.  Even though testing was done with 20 controllers, you may be able to increase or may need to decrease the number of MUs per NX depending upon the number of assets, devices, metadata, etc.

Considerations

Before programming these systems, there are a couple of things to consider:

1. All assets, parameters, metadata, and other keys must be unique across the entire system.  This includes each MU being unique to the other.  Even though they are all physically unique controllers, since they all go through the same NX, they are all the same system.Because of this, all the keys must be unique.
2. Scheduling should not be implemented in this scenario.  The overhead of the additional communication for multiple locations is far too high to implement both these scenarios at one time.
3. An NX processor should be used for this implementation, not a DVX or DGX.
4. Many of the “built-in" functions of RMS were designed to work as one controller per location, because of that, some of those functions/commands may not work correctly.
5. Related to consideration number 3, many of the built-in reports may not work properly.  You can work around this by creating and running the reports via SQL and not RMS.
6. Transporter will not be able to update firmware on devices in this configuration.​

​​NX Pr​ogramming: 

Example code has been provided as part of this implementation guide (RMS MUSE Test.axs).  Please see code comments for additional details.

The NX program handles two major things, distributing commands and telling the MUs when to register.

Command distribution is handled in the COMMAND sections of the DATA_EVENTS.  Any message that is received from an MU is forwarded on to the vdvRMS device.  This allows the MU to essentially talk to RMS directly.

All commands received from RMS are first evaluated to see if the message is for a specific MU prefix name.  If that name is found that command is forwarded only to that MU.  If the message does not contain a specific prefix, the message is forwarded on to all MUs.  These would be things like location state changes and Hotlist messages.

Registration control is handled via timeline.  The timeline evaluates the state of channel 252 on the MU, if that channel is on, it skips the device.  If it is off, the NX pulses channel 251 on the MU to trigger the registration process.  In testing, this timeline ran every 5 seconds.  Depending on the number of things being registered, this number can be changed based on the CPU usage of the NX.  The important thing is that each MU is given enough time to finish its entire registration process before the next MU begins, this is the key to this whole process.

​MU Progr​​amming: 

Example code has been provided in Python (index.py) and Automator, but any language can be used.  Please see code comments for additional details.

Programming for the MU is relatively straight forward.  There are only a few points that must be observed:

• All commands utilize the RMS API command structure that can be referenced in the RMS Enterprise Netlinx Programmer's Manual (Netlinx monitoring modules do not work here).
• The most important thing, mentioned previously, is that all keys must be unique.  This is why the “platform" service has been utilized to provide information unique to each controller.
• The MU must keep track of when the NX and RMS are available to receive updates and know when to disable those updates.​​