Tracking a variable from a module through RMS

ondrovic

Went to RMS class months ago and haven't really used it until now and I can't remember how to track a variable from a module in RMS. Can anyone point me in the right direction?


Thanks

Chris

[Deleted User]

Hi Chris,

The first place to start is in the RMS NetLinx Programmer's Guide. It includes all the SEND_COMMAND API for registering a device, registering device parameters and updating device parameters.

In addition, all of the RMS SDK modules (except the RMS Engine) are distributed as open source so you can wander through these to gain a better insight on how to manage a device and send along updates to the RMS server.

Both the RMS NetLinx Programmer's Guide and the source code I mentioned are included in the RMS SDK installation package available on AMX.com.

Thanks, Robert

d-alonso

Hey Chris

It haven't been to RMS As of yet but I have installed it and used the Codecrafter to get it connected to my demo system.
Can you help me get started I want to track my thermostat setpoint and Current Temp variables, The Manual and help files are hard to find what is needed.

Thanks


David

chill

As near as I can determine, RMS isn't really equipped to do that, but I've found a workaround. They key concept is that if you want to track something in RMS, it needs to have a device to cling to. So you'd create a device (which can be a virtual if there isn't any actual product there), then set up your variable as a parameter for that device.

Let us know how it goes.

[Deleted User]

Hi David,

Chris is right, you must have a device (D:P:S) and register your "Thermostat" as a device with RMS. The DPS can be virtual if needed, but typically this would be the IO device you are using to communicate with your physical thermostat. For example if you are using a serial port on a NI master, the DPS could be that of the 5001:Port:System you are using to communicate with.

After registering the device, next you will need to register your two parameters: (1) Setpoint, (2) Current Temp. After this, you simply just feed RMS changes if these values change.

Dig into one of the RMS device monitoring modules like the Projector module, these are all provided as open source. There are callback methods that notify the module when to perform the device and parameter registration.

Thanks, Robert

chill

Robert Savage wrote: »

Hi David,

Chris is right, you must have a device (D:P:S) and register your "Thermostat" as a device with RMS. The DPS can be virtual if needed, but typically this would be the IO device you are using to communicate with your physical thermostat. For example if you are using a serial port on a NI master, the DPS could be that of the 5001:Port:System you are using to communicate with.

Thanks, Robert

In this type of case, I prefer a virtual. Here's why: In a room I'm wrapping up now, for example, I have an Alcorn McBride audio player telling me whether it's playing on IO channel 1 of an NI-4100. I also have five motion sensors on channels 2 through 6. There might also be a Lutron room partition sensor on channel 7. In short, you can have multiple things that are logically unrelated, but reside on the same physical D:P:S. Using a separate virtual for each logical thing makes it easier for the user when he's looking at his RMS web pages, and it's approximately zero extra work for me, the programmer.

PhreaK

chill wrote: »

In this type of case, I prefer a virtual. Here's why: In a room I'm wrapping up now, for example, I have an Alcorn McBride audio player telling me whether it's playing on IO channel 1 of an NI-4100. I also have five motion sensors on channels 2 through 6. There might also be a Lutron room partition sensor on channel 7. In short, you can have multiple things that are logically unrelated, but reside on the same physical D:P:S. Using a separate virtual for each logical thing makes it easier for the user when he's looking at his RMS web pages, and it's approximately zero extra work for me, the programmer.

I think robert was referring to an IO device in the non NI context (i.e. any form of input/output, rather than NI IO ports). I do a similar thing though and seperate out physical devices that perform multiple tasks into their logical components. However, if there's already a real device to bind the parameter to it'll get used first. It'll be interesting to see if RMS 2020 maintains this requirement to map parameters to actual devices or if there might be some form of more hierarchical parameter system.