Home AMX User Forum AMX Control Products

Levels on a shared Modero Viewpoint

I have a large and complex system in which I have a central processor handling a lot of global operations, and a half dozen other processors handling local operations. Originally, the local systems were controlled by Wave Viewpoints, but the customer had us upgrade them to Modero Viewpoints so he could also access more of those global operations from the local system areas. My Modero Viewpoints connect to the local system that they primarily control, and I defined them on the central processor using a port the local system didn't need (for example, in the local system device section, it is defined as dvTP = 10001:1:0, and on the central as dvSystem2_TP = 10001:2:2). Almost everything works as expected. Almost.

The problem I am having is with levels. One of the global operations uses a control page with a lot (dozen or so) of multi-state bargraph buttons. On panels connected directly to the central processor, send_level commands to set them proerly work fine. However, the buttons on the Modero Viewpoints, which connect to another master, never get the level commands. It's all done in the exact same code block; the panels are in an array and the Modero Viewpoints are just another element in the array. Oddly enough, variable text commands using the @BMF send_command work just fine. the button presses work just fine - I can press a button on the Viewpoint and watch the level change on a nearby CV-12; but the Viewpoint simply will not reflect the level change.

I've noticed in the past that I cannot send a string to a virtual device defined on another master than the one I am sending the string from. Is this a similar issue? Are devices that connect to one master, but defined on another treated something like virtual devices? Or is the problem just the send_level command? Or is it somethoing like the limit mentioned in Tech Note 578 - do I need a SET_VIRTUAL_LEVEL_COUNT statement ro cover all those bargraph buttons?

Any ideas? I am loath to set these up with varables and CREATE_LEVEL statments - 22 panels and 30 or so levels each will make a lot of overhead.

Comments

  • kkettreykkettrey Posts: 13
    I tested this scenario and came up with the exact results. Only the first 8 levels are making it across the "network".

    This is what I hacked out to fix the issue:

    Create a virtual device on the "central processor" for every remote MVP.

    Now, in add a DEFEIN_COMBINE section, and combine each Virtual Device with it's associated MVP.

    Next, replace your MVP devices with the Vritual devices in your DEV array that references all panels.

    Next, in your DEFINE_START section (or ONLINE event for 0:1:0), use the SET_VIRTUAL_LEVEL_COUNT with each virtual device.

    It should work fine.

    (HERE IS MY CONDENSED TEST CODE FOR REFERENCE)


    DEFINE_DEVICE
    dvMaster = 0:1:0 // This system is 2001
    dvMVP1 = 10001:2:2002 // MVP#1 on remote system
    dvMVP2 = 10002:2:2002 // MVP#2 on remote system
    vdvVirtual1= 33001:1:0 // Virtual Device 1
    vdvVirtual2= 33002:1:0 // Virtual Device 2

    DEFINE_COMBINE
    (vdvVirtual1,dvMVP1)
    (vdvVirtual2,dvMVP2)

    DEFINE_VARIABLE
    DEV vdvAllTP[]={vdvVirtual1,vdvVirtual2}

    DEFINE_START
    SET_VIRTUAL_LEVEL_COUNT (vdvVirtual1,20)
    SET_VIRTUAL_LEVEL_COUNT (vdvVirtual2,20)

    DEFINE_PROGRAM
    WAIT 20
    {
    SEND_LEVEL vdvAllTP,1,RANDOM_NUMBER (255)
    SEND_LEVEL vdvAllTP,2,RANDOM_NUMBER (255)
    SEND_LEVEL vdvAllTP,3,RANDOM_NUMBER (255)
    SEND_LEVEL vdvAllTP,4,RANDOM_NUMBER (255)
    SEND_LEVEL vdvAllTP,5,RANDOM_NUMBER (255)
    SEND_LEVEL vdvAllTP,6,RANDOM_NUMBER (255)
    SEND_LEVEL vdvAllTP,7,RANDOM_NUMBER (255)
    SEND_LEVEL vdvAllTP,8,RANDOM_NUMBER (255)
    SEND_LEVEL vdvAllTP,9,RANDOM_NUMBER (255)
    SEND_LEVEL vdvAllTP,10,RANDOM_NUMBER (255)
    SEND_LEVEL vdvAllTP,11,RANDOM_NUMBER (255)
    SEND_LEVEL vdvAllTP,12,RANDOM_NUMBER (255)
    SEND_LEVEL vdvAllTP,13,RANDOM_NUMBER (255)
    SEND_LEVEL vdvAllTP,14,RANDOM_NUMBER (255)
    SEND_LEVEL vdvAllTP,15,RANDOM_NUMBER (255)
    SEND_LEVEL vdvAllTP,16,RANDOM_NUMBER (255)
    SEND_LEVEL vdvAllTP,17,RANDOM_NUMBER (255)
    SEND_LEVEL vdvAllTP,18,RANDOM_NUMBER (255)
    SEND_LEVEL vdvAllTP,19,RANDOM_NUMBER (255)
    SEND_LEVEL vdvAllTP,20,RANDOM_NUMBER (255)
    }
  • kkettreykkettrey Posts: 13
    Oh, and trying SET_VIRTUAL_LEVEL_COUNT directly on the remote device did not work. I'm sure you have already found that out.
  • DHawthorneDHawthorne Posts: 4,584
    Thanks - actually, I had to move on to some more functional issues and told my client I'd go back to fix that issue. I also had a bad WAP sucking down major blocks of time, so I haven't got back to this one yet. Heh, setting SET_VIRTUAL_LEVEL_COUNT directly on the device was exactly the first thing I was going to try. I appreciate not having to waste time on that now :). I really appreciate the input.

    So it looks like my guess was correct - panels that connect to another master must be treated internally like a virtual device, since virtuals also have that 8 level limit. Someone in AMX needs to put up a tech note on this <hint>...or, better, change it so the issue goes away altogether/
  • Explanation

    Good catch guys. Here's the explanation for what is happening.

    When the central master is notified by the local master about the touch panel, there is a qualification placed by the central master about whether it feels it needs to be notified of level inputs from the panel. If there is no CREATE_LEVEL or LEVEL_EVENT for that panel in the central master, it did not ask the local master for level info for the panel. Since part of the level info is the level count, the central master was never sent the level count and it defaulted to 8 level for that panel.

    The next release of firmware for the NetLinx masters should have this fixed.

    Chuck
  • Therefore, a valid work-around in the mean time is to put CREATE_LEVELs or level events in the central master's code for each level you want to control.

    Note you do not need to put in create_levels for the 1st eight channels.
  • frthomasfrthomas Posts: 176
    I know this is slightly OT, but while we are on the subject of levels in NetLinx, would it be possible to have levels we can read the value from (like you can read the state of a channel), outside of change notification?

    Just a wish...

    Thanks

    Fred
  • Originally posted by frthomas
    I know this is slightly OT, but while we are on the subject of levels in NetLinx, would it be possible to have levels we can read the value from (like you can read the state of a channel), outside of change notification?

    Just a wish...

    Thanks

    Fred

    If I understand what you what, it's already there. Use the CREATE_LEVEL and SEND_LEVEL commands to associate a level to a variable.

    If that's not what you want, please explain.

    Chuck
  • Originally posted by kkettrey
    Oh, and trying SET_VIRTUAL_LEVEL_COUNT directly on the remote device did not work. I'm sure you have already found that out.

    I tried it with SET_VIRTUAL_LEVEL_COUNT, seemed to work fine for me.
    The difference is probably because I used it in a DATA_EVENT/ONLINE handler, which runs when device actually comes online.

    A device may or may not be online when DEFINE_START runs, so device initialization should be done in an ONLINE event.

    DEFINE_DEVICE

    dvTPI = 10000:1:2
    dvMVP = 10001:1:2

    DEFINE_VARIABLE

    INTEGER CURRENT_LEVEL

    DEV dvTP[] = {dvMVP,dvTPI}

    DEFINE_EVENT

    DATA_EVENT[dvTP]
    {
    ONLINE:
    {
    SET_VIRTUAL_LEVEL_COUNT (DATA.DEVICE,24)
    }
    }

    DEFINE_PROGRAM

    WAIT 20 'SEND LEVEL TEST'
    {
    CURRENT_LEVEL = RANDOM_NUMBER(256)

    SEND_LEVEL dvTP, 1,CURRENT_LEVEL
    SEND_LEVEL dvTP, 2,CURRENT_LEVEL
    SEND_LEVEL dvTP, 3,CURRENT_LEVEL
    SEND_LEVEL dvTP, 4,CURRENT_LEVEL
    SEND_LEVEL dvTP, 5,CURRENT_LEVEL
    SEND_LEVEL dvTP, 6,CURRENT_LEVEL
    SEND_LEVEL dvTP, 7,CURRENT_LEVEL
    SEND_LEVEL dvTP, 8,CURRENT_LEVEL
    SEND_LEVEL dvTP, 9,CURRENT_LEVEL
    SEND_LEVEL dvTP,10,CURRENT_LEVEL
    SEND_LEVEL dvTP,11,CURRENT_LEVEL
    SEND_LEVEL dvTP,12,CURRENT_LEVEL
    SEND_LEVEL dvTP,13,CURRENT_LEVEL
    SEND_LEVEL dvTP,14,CURRENT_LEVEL
    SEND_LEVEL dvTP,15,CURRENT_LEVEL
    SEND_LEVEL dvTP,16,CURRENT_LEVEL
    SEND_LEVEL dvTP,17,CURRENT_LEVEL
    SEND_LEVEL dvTP,18,CURRENT_LEVEL
    SEND_LEVEL dvTP,19,CURRENT_LEVEL
    SEND_LEVEL dvTP,20,CURRENT_LEVEL
    SEND_LEVEL dvTP,21,CURRENT_LEVEL
    SEND_LEVEL dvTP,22,CURRENT_LEVEL
    SEND_LEVEL dvTP,23,CURRENT_LEVEL
    SEND_LEVEL dvTP,24,CURRENT_LEVEL
    }

    // end
  • DHawthorneDHawthorne Posts: 4,584
    Originally posted by frthomas
    I know this is slightly OT, but while we are on the subject of levels in NetLinx, would it be possible to have levels we can read the value from (like you can read the state of a channel), outside of change notification?

    Just a wish...

    Thanks

    Fred
    Within a LEVEL_EVENT, LEVEL.VALUE reads the level.
  • DHawthorneDHawthorne Posts: 4,584
    An update on my original problem...

    I added a simple LEVEL_EVENT with my remote devices and the level numbers, and it appeared to solve my problem. Since arrays already existed for both, I thought it an elegant solution and extremely simple to implement. Sigh, it didn't last though - while working on the system, I once again noticed the levels weren't getting through. I telnet in and did a device status, and sure enough, it only showed 8 levels on the remote devices. I rebooted the remote system, and it worked again! So, simply adding a level event is not sufficient, becasue if the master gets rebooted after the remote system reboots, the extra levels don't take.

    So it looks I'll need to make on online event and set the levels with SET_VIRTUAL_LEVEL_COUNT.
  • DHawthorneDHawthorne Posts: 4,584
    Bleah...that was a great theory, but it didn't pan out very well in practice and needed some modification. By the way, a CREATE_LEVEL statement did not work at all.

    Setting the virtual level count in an online event works fine. But...the flaw in it is when the local system reboots, devices connected to a remote system do not generate an online event, or if they do, they are not processed while the local system is starting (I should say, they don't in the system I am doing this on - the local system generates pages upon pages of events on bootup...mostly memory statements, but quite a few others as well). So I was forced to send a reboot command to my remote devices on a 30 second delay in the module that uses these extra levels. It's kludgy as all get-out as far as I'm concerned, but it did the job.
Sign In or Register to comment.