PLK-DMS Scaling/Reliability

youstra

We're working on a design that would have about 55 PLK-DMS keypads. I haven't seen anything from AMX (except one tech note) about whether/how this will perform. We've not done anything this extensive before with so many kpds on one system.

I'd appreciate any tips, warnings, recommendations or war stories related to large scale DMS installations, or any general DMS rules of the road (aside from AMX's documentation).

Thanks,
Bill

Roman Bias

Hello,


We have used about 50 keypads (and iother panels) in a project:

http://www.amx.com/Newsletters/InsideAMX-06-03.asp

We have won the dealer contest of June 2003 with it.
We had no programming problems with the keypads !

DHawthorne

The limit of how many DMS keypads you can run on the same master will depend on how fancy your keypad design is, and how old the keypads are. New keypads without a lot of variable text addresses shouldn't be a problem.

However, you have to make an array for each keypad to pass to the virtuals that has an entry for each text address that is the lenght of the maximum string you will be sending. Variables passed to modules use non-volitile memory, and if you allocate more than then master has available (1M I think it is, off hand), your code won't even run, the processor will lock right up. That's one thing to look out for.

The other problem I have run into also relates to variable text fields, but might have something to do with the age of the keypads. Without exception, the projects I have done using DMS were retrofits of old Landmark projects, so it might be a firmware issue with the keypads that has since been corrected. What I found was that when passing a lot of variable texts, the processor message queue often filled up and started dropping messages. Responsiveness of the DMS keypads seems to vary, so it didn't always show up right away. Once that queue is full, strange things hapened, from lost commands to outright loss of master communication. I found I had to carefully ensure in code that I didn't send unecessary text changes out, and that I paced them so they didn't go too fast to the keypad buss.

My feeling is that in a NetLinx system, it's best to have fixed menus on the DMS and save the fancy stuff for your touch panels. They are simply not responsive enough to keep up with the demand.

Spire_Jeff

I'm not sure on this, so I decided to ask just in case I run across this problem in the future. Would adding an additional master or two help improve the responsiveness (is that a word???) of the keypads? Also, how involved will the programming changes be to implement the keypads across multiple masters?

Jeff

DHawthorne

Modules don't pass command or string data across masters, only channel and levels, so the module has to be defined on the same master that all your control functions happen to be coming from. In other words, You can't do a SEND_COMMAND to a virtual device whose module is loaded on another master, even if you define the virtual device interface on your local master. So the only way to split them among masters would be to have your own communications routine to have the local master pass the commands to the virtual device along to the remote master.

That would probably take care of the notification queue backing up though, and would certainly take care of hitting the 1M limit on non-volitile memory. Depending on your means of communicating between masters, the overhead shouldn't be too horrible.

Spire_Jeff

Cool, thanks for the info.

Jeff

frthomas

Originally posted by DHawthorne
Variables passed to modules use non-volitile memory, and if you allocate more than then master has available (1M I think it is, off hand), your code won't even run, the processor will lock right up.

What do you mean by non-volatile? I use VOLATILE variables and it seems to work. It does not seem to be a change to PERSISTENT behind your back as these variables are not refreshed at startup in the system log.

These variables must be GLOBAL however (i.e. defined in DEFINE_VARIABLE), they can't be allocated on the stack (i.e. STACK_VAR).

Fred

kennyann

Dear Bill:

I too have used many DMS keypads, the old AMX high volatage switches,and the two button pads. I think I had a total of about 70 Landmark devices on a Netlinx system. It all worked fine. My DMS keypads did do alot of functions but it seems to be working fine.

Kenny A

DHawthorne

Originally posted by frthomas
What do you mean by non-volatile? I use VOLATILE variables and it seems to work. It does not seem to be a change to PERSISTENT behind your back as these variables are not refreshed at startup in the system log.

These variables must be GLOBAL however (i.e. defined in DEFINE_VARIABLE), they can't be allocated on the stack (i.e. STACK_VAR).

Fred

Telnet into your master and type in "show mem." It gives you three memory values, volatile, non-volatile, and disk space. PERSISTENT variables go into non-volatile, adn I presume the low-level code that runs the master. Every variable that you do not flag as STACK also goes into non-volatile, whether it's PERSISTENT or not, unless it's declared inline in code (like a function call). Variables passed to modules also seem to get stored there - I never found any docs to back it up, I just commented out a DEFINE_MODULE line, and whated the value go down as shown in "show mem." It was my own module, I knew what kind of variable space it needed internally, and what it actually used was higher. Try watching that memory space when you load i!-Schedule, or something like that. Most of the time, you have lots of this, but with a big project and a lot of modules, it does get eaten up.

DHawthorne

Originally posted by kennyann
Dear Bill:

I too have used many DMS keypads, the old AMX high volatage switches,and the two button pads. I think I had a total of about 70 Landmark devices on a Netlinx system. It all worked fine. My DMS keypads did do alot of functions but it seems to be working fine.

Kenny A

It's not so much what they do, but how you need to update them. The project I had trouble with only had a dozen, but it was controlling an Escient Fireball. All the variable text fields I needed for that ate a huge chunk of memory, and when the Fireball is playing, it updates every second. I had to settle for far less on keypad updates, they just bogged everything down.

cwpartridge

NetLinx Memory

Originally posted by DHawthorne
Telnet into your master and type in "show mem." It gives you three memory values, volatile, non-volatile, and disk space. PERSISTENT variables go into non-volatile, adn I presume the low-level code that runs the master. Every variable that you do not flag as STACK also goes into non-volatile, whether it's PERSISTENT or not, unless it's declared inline in code (like a function call). Variables passed to modules also seem to get stored there - I never found any docs to back it up, I just commented out a DEFINE_MODULE line, and whated the value go down as shown in "show mem." It was my own module, I knew what kind of variable space it needed internally, and what it actually used was higher. Try watching that memory space when you load i!-Schedule, or something like that. Most of the time, you have lots of this, but with a big project and a lot of modules, it does get eaten up.

Unless you _EXPLICITLY_ define a variable as VOLATILE, it will be placed in the non-volatile memory by default. This was done to maintain backwards compatability with Axcess behavior.

Things like buffers and any variable or structures that are initialized every time probably should be declared as VOLATILE to help reduce the unnecessary use of non-volatile memory (since it is limited compared to volatile).

FYI Firmware and compiled NetLinx code are loaded into volatile memory at start time, so the size of your program can affect the amount of free volatile memory. In all but extreme cases, there is usually plenty of volatile memory, so if you run out of non-volatile memory, look at what probably should be volatile and explicitly declare it to be volatile.

It may be overstating the obvious, but anything PERSISTENT cannot be VOLATILE.

HTH,
Chuck

LegacyUser

on the memory thing, i declare all variables with the VOLATILE prefix, cos i have experienced running out of non-volatile ram.

as for the DMS arrays, i have read in AMX tech docs that only 10 devices per HUB are supported. (there are 8 ports, but you can chain devices).

considering power supply issues like i have been lately, i'd be sticking close to that spec, ensuring each hub had it's own sufficiently rated power supply.

and i have noted in other DMS threads that sending variable text appears to remove any formatting supplied with the editor (Left Justify, Large Font for example) so you may have to program in formatting as well as variable text. still trying to confirm this problem with someone else, but it has been the case in my experience.

i hope it helps. have fun managing that number of devices

youstra

How Best to Manage Lots of DMS?

I've never built something with so many DMSs. Let me know what you think of this approach:

This is a large residence where the owner wants only DMSs and a few TPs. No Lutron switches or anything else, so the DMS menus are pretty full: Lights, Security, Audio, Video, Heating, Cooling, Windows, Drapes, Scenes, Playlists, etc.

The approach is to use a single huge KPD file for all areas (so we don't have to tweak playlists, FM stations, lighting scenes).

We'd just use a different start page for the 50-odd different kpds.

Does that make sense? How have others approached this?

And a second question: Does BTON & BTOF work on DMS? I haven't gotten it to work. Does BTOF blank out the line item, or delete it (causing everything below it to move up)?

Thanks,
Bill

Reese Jacobs

PLK-DMS Scaling/Reliability

Bill,

I did a residential job with 23 DMS keypads and 5 MSP keypads but the residence also had a significant number of MVP-8400s and TPI/4 touchpanels. We had a full selection of capabilities on the DMS keypads including lights, source selection, volume control, channel selection, HVAC, security, etc. We found that the owner primarily used the DMS for volume control and muting and not much else mostly because the 2-way interface of the touchpanels (with the rich graphics) made using the DMS a chore. I am not sure about a home with only DMS keypads and no touchpanels - I am not sure that the homeowner will be happy in the long run controlling everything from the DMS but that is my own personal opinion.

That said, the DMS can do the job. Your KPD files need to be intelligently laid out so as to facilitate navigation by the customer. They should not have to hit too many buttons or scroll down the page too many times to get to key functions. On your specific questions:

1. You can support a large number of keypads - AMX has a TechNote in which they describe testing 32 DMS on a system. There are however Queue and Threshold modifications for the Master that you will want to implement to ensure message handling is optimized. The file is available from Design Express as an axi include file. It might have been posted to the forums at some point and it might also be available from AMX through a TechNote. If you have trouble locating it, post to the forum and we can direct you to it or post it directly.

2. BTON and BTOF do work on the DMS keypads. I used them frequently and can verify that they work correctly. Simpy specify BTON or BTOF in the SEND_COMMAND followed immediately by the Ascii equivalent of the button/channel number. This may be redundant, but all SEND_COMMANDs to the DMS keyapds go to the virtual device declared in the module definition and not the real (physical) device. Sending commands to the real device will not work.

3. Automatic packing of menu entries that are deleted (turned off) does not occur but you can specify PACKON using SEND_COMMAND in your ONLINE event for each DMS and this will cause packing of deleted menu entries to occur.

Hope the information is useful,

Reese

Reese Jacobs

PLK-DMS Scaling/Reliability

Bill,

I just your original post from some time back regarding 55 DMS keypads on the job. I don't have any experience with installations using this many DMS. When a DMS keypad comes online, there seems to be a lot of startup message traffic and this is particularly true if you are using variable text, BTON/BTOF, and other commands to initialize the DMS in an ONLINE event. With queue and threshold settings established correctly, that will help. However, even in my 23 DMS installation, I see a number of latency messages during startup but we do a lot of variable text and button/on/off commands during ONLINE.

Regarding BTON/BTOF, I neglected to mention in my earlier post that these work on a variable text channel. If you want to be able to enable and disable buttons on the DMS using these commands or the variants that do the same thing, you must allocate them a variable text channel in the KPD file and this is what you specify in the SEND_COMMAND. Menu entries that you want to turn on/off must therefore have both standard channel and variable text channel assignments.

Reese

youstra

Whoops - never mind on that second question -- I figured out the BTON/BTOF thing. Looks like it simply blanks out the slot, which makes sense.

Still...any thoughts on the first question re how to structure this for max flexibility and manageable maintenance?

Thanks again,
Bill