Home AMX User Forum AMXForums Archive Threads AMX Hardware

Phast/NetLinx DMS Keypad Programming

I have a client w/ a Phast Landmark system with lots of keypads (DMS). The system was programmed using the Landmark software. Part of the menu structures in the DMS keypads have the normal "Lights", "Music", etc. menus. There is also a "Navigation" menu that allows any keypad to navigate to the "Room" menu of another keypad. So, if you're in the Kitchen, you can navigate to the Den and turn on/off lights in the Den, etc.

The Landmark software made it very easy and obvious to program a keypad and it's associated room menu. Then you could navigate from other keypads to access that menu.

The system is being upgraded to use the new NetLinx controller hardware.

With NetLinx, I don't see how keypad room navigation can be done. DMS keypads can be used with the NetLinx system. I've seen how the DMS-IMS module works w/ NetLinx. There is a separate KPDesign program to design the menus for the DMS keypad and load that information into the NetLinx Studio program and thus program the master controller.

However, each DMS keypad definition in the NetLinx code is "bound" to a single *.KPD file. I don't see how to program a room navigation menu item so that it can load up a different room menu which would really have to load the code in a different *.KPD file. I can't believe that I need to replicate N x N rooms of information in every single DMS keypad definition file.

So, how do I program the same "Navigation to other room" menus that was simple to do in Phast Landmark?

Thx for any help.

Comments

  • Phast/Netlinx DMS Keypad Programming

    There are a couple of ways at least to do multi-room control from a DMS. First, you could develop a set of menu pages for functions like lights, temprature, etc. that could be shared across all rooms. Using variable text fields on the DMS, the buttons could be labeled based on the specific room you are controlling. You could then provide a menu page for selecting a Room to control and then have your Netlinx program perform the function requested on the DMS based on the room selected by the user. This requires that you code your Netlinx program to understand actions based on a current room which can be selected from the DMS. You would also need to update DMS pages with appropriate text once a new room is selected. This would however allow you to share the same basic menu structure across all rooms. For rooms with more or less functions on a page, you can always do SHOW or HIDE actions on the buttons.

    Second, you can dynamically flip pages on the DMS based on button actions such as the selection of a specific Room. For instance, a LIGHTS menu selection could generate a button event which causes a DMS page flip to a lighting control page for the currently selected room. This requires that you build and manage multiple DMS pages and that you manage them according to the room selected. You could however still get by with a single KPDesign file for the project that handles all keypads.

    There is yet a third method in which you can dynamically generate menu pages. I have never used this technique but it is documented in the DMS module documentation. I generally use one of the first two methods if and when I provide room navigation capabilities. In general, I find it confusing to let customers control rooms they are not in but an exception is lighting control in adjacent rooms where this makes some sense. In this case, I generally handle it by providing lighting or other control functions for adjacent rooms on a room's DMS to support actions that make sense when customers are moving from one room to the next.

    In general, you will find that although KPDesign is a decent but basic tool and that Netlinx support for the DMS is available, the keypad is not nearly as effective in Netlinx as it was in Landmark. You will find that levels on the DMS can not be tied to other Netlinx devices (combined) such as volume controls or touchpanels. The DMS under Netlinx can be slow in responding due to the fact that they have no memory and a chatty protocol although DMS keypads could be stubborn in Landmark as well. You can however provide capabilities for your customer in Netlinx similar to those you provided in Landmark but a good bit of effort will be required on your part.

    As you have discovered, there is no automatic menu generation in Netlinx for DMS keypads as there was in Landmark. One other limitation to keep in mind as you design your KPD file and your Netlinx program support for it, the DMS is limited to 1024 channels. It does not have the port and channel flexibility of a Modero panel although 1024 channels should be enough for most applications.

    Those are some basic ideas and thoughts - I am sure you will get some other suggestions from Netlinx veterans that have used DMS keypads on their projects.
  • DHawthorneDHawthorne Posts: 4,584
    You can use variable text addresses and a menu array to dynamically populate your menus. Then the DMS definition file can be the same for each keypad, and starts out blank. First, make an array to hold all your menu values:
    CHAR sRoomMenu[][][20] = {
    {{'Room 1 Label 1}, {'Room 1 Label 2}, {'Room 1 Label 3'}},
    {{'Room 2 Label  1'}, {'Room 2 Label 2'}, {'Room 2 Label 3'}}
    }
    
    Expand as necessary. The number value in the third brace is necessary for strings, even when initialized, just make it big enough for your largest option name.

    Then make an array for the keypad virtuals that is in Room order:
    DEV vdvDMS[] = {vdvRoom1_DMS, vdvRoom2_DMS}
    
    When your menu button on the DMS is pressed, use a BUTTON_EVENT on the virtuals array to look up the room in the first array, and FOR loop to populate the menu:
    BUTTON_EVENT[vdvDMS, nMenuButton] {
    PUSH: {
    CHAR cIndex
    CHAR cCount
    cIndex = GET_LAST(vdvDMS)
    FOR(cCount = 1; cCount <= LENGTH_ARRAY(vdvDMS); cCount ++) {
         SEND_COMMAND vdvDMS[cIndex], "'@BMF', cCount, '%T', sRoomMenu[cIndex][cCount]" }
    SEND_COMMAND vdvDMS[cIndex], "'@PAGE-<CURRENT>"
    }}
    
    This example assumes the variable text address are 1-<number of rooms> ; you can use a calculation in the SEND_COMMAND if they are different, as long as they are continuous. Notice also the page command after the FOR loop - this is necessary on DMS keypads to display your new variable text addresses, or they will show the old value until the page is flipped. Just double check my syntax on that command to flip to the curent page, it's been a while since I used it :).

    You need to make sure your DMS module has a text field aray passed to it in definition big enough to hold your menu labels (see the module text file, it's pretty self-explanitory). You will also need a routine when one of the menu buttons is pressed to do the appropriate actions on a room-to-room basis.

    Hope this is helpful...
  • just a quick question about text labels if anyone can answer it.

    i do use variable text fields in the DMS to display room names etc..

    one annoying feature is this..

    no matter what text size and justification i give the field in the editor (i.e. Left Justified and Large Font) the formatting gets lost when i send the text. it defaults back to small (or was it medium) font with Right Justification.

    yes, i know i could send formatting commands with the new text, but like damn, it's just more work that needs to be done, after doing a nice layout in the editor.

    has anyone else noticed this.. is there a way to keep edited formatting, or do i have to do it in code ?
  • DHawthorneDHawthorne Posts: 4,584
    I'm not 100% certain, but I get the impression that formatting is always done on the fly with DMS keypads. When you specify a format in the design tool, it's stored with the text in the keypad memory and gets sent out with the string every time. It would almost have to be this way, since each menu page uses the same display lines. So sending a format command with each variable text is replicating wht the keypad does internally with a "static" menu.
  • dbradydbrady Posts: 30
    If most of your variable text are justified the same way you can set the default justification for variable texts in :

    Panel->Properties->DMS->List Items

    to this justification. Any variable text items with any other justification/Font has to use embedded text codes. At least this is my understanding.


    Sl
  • I'm installing a system like this in my new house (money's tight!) with a NetLinx mater and DMS keypads in every room. This may be an old topic, but if anyone has any further questions i'd be happy to share my experiences.
Sign In or Register to comment.