Home AMX User Forum AMX General Discussion

Master to Master question

I'm building what is basically a super-"light" version of RMS for CGHQ, because RMS is unfortunately not within our budget. Basically I have a bunch of conference rooms with AMX masters in them, and I have a master on my desk with a touchpanel. The master on my desk has all the conference rooms in its URL list, and each conference room's code has dvMasterTP in it assigned to my base system, then some basic button presses and feedback for it. This way, from my desk, I can choose a room on my panel and control all the basic functions without needing to use G4 webcontrol or anything like that. My master also polls all of the rooms each night, gets a few variables from them (like current projector bulb life) and sends it to me in an email, so I get regular status updates on bulb life and whether or not devices in each room are giving off errors.

Right now, I've only got this set up for 12 systems. I'm about to put in 6 more that I know about and I'm hoping for another 5 soon after. This leads me to question how many connections my master can have the way its set up.

I don't need for any of my systems in the field to talk to each other, they all just need to talk to my master system. Will my master be unable to talk to more than 20 if I just keep adding them to my URL list on it? If I go to each individual master in the field and add the Master on my desk to it, will that let me talk to all of them even up to 40, 50 or more?

Or do I need to do something like what is found on page 211 of the current (2005) programmer handbook, which is termed "radical connection topology" . . .

I'm trying to avoid having to keep a written record somewhere of all of the connections, and go with something that will be easy to make sense of if I leave this position and somebody comes along behind me.

J

Comments

  • We are running an installation where about 100 rooms, each one with a master, are talking with 1 headmaster (access to building control for blinds, etc, but also to a server in the customer's network), where the AMX components are installed in the same network like the PCs of the customer, just in another subnet. This works pretty fine for about 3 years now.

    What we did to reduce ICSP traffic was to set on the headmaster (in terminal) the ROUTE MODE DIRECT. This will break down the communication of the subsystems to just the route to the headmaster. The subsystems have the URL list entry to the headmaster.
  • JeffJeff Posts: 374
    OK, So now i've got this going on with the master to master working pretty good, and I haev a new problem. I think.

    The Input/Output buttons on my master NI700 are pretty much solidly locked on. The master isn't doing anything, but the other rooms are sending updates to the master touchpanel pretty regularly. Is this a bad thing that these lights are locked on?

    J
  • Jeff wrote:
    The Input/Output buttons on my master NI700 are pretty much solidly locked on. The master isn't doing anything, but the other rooms are sending updates to the master touchpanel pretty regularly. Is this a bad thing that these lights are locked on?

    I'd say yes it is a bad thing - it may not be causing you any obvious problems right now, but until you find out what's causing it you are leaving yourself a problem for the future.
  • JeffJeff Posts: 374
    So how do I figure out whats doing it? I'm sort of at a loss here . . .
  • DHawthorneDHawthorne Posts: 4,584
    First thing, make sure you don't have any circular routes. If Master 1 has master 2 in it's URL list, make good and sure master 2 doesn't have master 1 in it's URL list.

    If that's clear, turn on notifications for that master, and see what traffic is going on. If those two lights are constantly lit, you are only a step away from a lockup.
  • JeffJeff Posts: 374
    Weird. . . ..

    found the problem, but not yet the solution

    We recently changed the entire network here, switching from all AMX on the same subnet to the each building (we have 2) having its own subnet. There is a gateway connecting them, so I can talk between buildings with no problem, but this basically means I completely changed all of my IP addresses and system numbers.

    I used to have a system in Building 2 (room 09-0830) that had the IP address of 10.198.9.6, and was system number 6. Now that system holds the IP address of 10.98.148.8, and is system number 58. There was a system in Building 1 (Room 4105) that had the IP address of 10.198.9.19 and was system number 19. It is now 10.198.9.6, and is system number 6.

    If I disconnect the AMX system in room 4105, the master lights stop flaring up and act normally again. Whenever it is hooked up, it goes crazy. I have double and triple checked, and as far as I can tell the system numbers did actually change, the IP addresses did actually change, and the appropriate code for each room is definitely loaded to the appropriate NI-700. I did get out another NI-700 and replace the one in room 4105 with a completely new one, same code and numbers, and had the same problem.

    Clearly I'm missing something. . . . .weird

    J
  • JeffJeff Posts: 374
    Aaaaaand I am a MORON!!!!!!!!!!!!!

    Seriously

    All that crap about IP addresses and system numbers and subnets

    NOPE!

    Check this bit of my code
    define device
    
    dvMasterTP = 10001:6:1
    
    define program
    
    [dvMasterTP,1]=nPlasmaPower
    [dvMasterTP,1]=!nPlasmaPower
    

    I don't think you can do that

    The second line should've been [dvMasterTP,2], but I guess when I typed it I hit the wrong number. That made the Master system very angry, trying to reconcile that kind of problem, and so I got locked on input/output leds.

    Go figure

    J
  • I was told by tech support that placing anything in the Define Program section causes it to be executed a ba-jillion times a second. (OK, I can't remember the exact number but it was a lot). Anyway, that would explain the solid light.

    Apparently, timelines are the recommended way to go now.

    Will this start another discussion like the page-flip discussion in another thread?
  • Spire_JeffSpire_Jeff Posts: 1,917
    As far as I understand it, I have been told that feedback (channel and level types) in the DEFINE_PROGRAM section is ok because the processor will not send the feedback if it has not changed.

    Jeff
  • Yes, but a great example of how it can be broken with the above code. The processor will flip the state on that channel a gazillion (j/k) times a second like that. In a 1/10 second timeline, only 10 times a second...

    - Chip

    Spire_Jeff wrote:
    As far as I understand it, I have been told that feedback (channel and level types) in the DEFINE_PROGRAM section is ok because the processor will not send the feedback if it has not changed.

    Jeff
  • DHawthorneDHawthorne Posts: 4,584
    Spire_Jeff wrote:
    As far as I understand it, I have been told that feedback (channel and level types) in the DEFINE_PROGRAM section is ok because the processor will not send the feedback if it has not changed.

    Jeff

    This is true if conditions are ideal, but it only works on real devices (not virtual) channels and levels. Any SEND_COMMANDs are going to fire regardless, and will blow up your system. Channel and level events to a virtual will also get sent every time. Only something very basic like [dvPanel, 1] = (bSystem == FALSE) won't overload in DEFINE_PROGRAM.
  • AlexArtistAlexArtist Posts: 51
    DHawthorne wrote: »
    This is true if conditions are ideal, but it only works on real devices (not virtual) channels and levels. Any SEND_COMMANDs are going to fire regardless, and will blow up your system. Channel and level events to a virtual will also get sent every time. Only something very basic like [dvPanel, 1] = (bSystem == FALSE) won't overload in DEFINE_PROGRAM.

    DHawthorne...
    Is this really true, that if you send an channel event to a virtual it will cause an event even if that channel is already on? I don't have a master nearby to test with but this is news to me.

    For example

    [vDev,5] = 1
    wait 5 [vDev,5] = 1

    will both these statements cause a channel event ON: to occur?

    (Is this also true for Level Events?)
  • AlexArtistAlexArtist Posts: 51
    What we did to reduce ICSP traffic was to set on the headmaster (in terminal) the ROUTE MODE DIRECT. This will break down the communication of the subsystems to just the route to the headmaster. The subsystems have the URL list entry to the headmaster.

    DHawthorne... Regarding this.
    Could you just send the ROUTE MODE DIRECT to the Main Master and put all the satellite master IPs in the Main Masters URL list. And will all masters at that point be DIRECT MODE ONLY, or will you have to go to each master and tell each to be Direct Mode?
  • DHawthorneDHawthorne Posts: 4,584
    AlexArtist wrote: »
    DHawthorne...
    Is this really true, that if you send an channel event to a virtual it will cause an event even if that channel is already on? I don't have a master nearby to test with but this is news to me.

    For example

    [vDev,5] = 1
    wait 5 [vDev,5] = 1

    will both these statements cause a channel event ON: to occur?

    (Is this also true for Level Events?)

    Yes; I tested it once in Diagnostics (with the caveat that it was a long time ago, and it's possible a firmware change has made it different since). I think level events behave the same way, but again, it's been a while since I actually tried it.
  • kbeattyAMXkbeattyAMX Posts: 358
    DHawthorne wrote: »
    Yes; I tested it once in Diagnostics (with the caveat that it was a long time ago, and it's possible a firmware change has made it different since). I think level events behave the same way, but again, it's been a while since I actually tried it.

    DEFINE_PROGRAM
    wait 20
    {
    [vDevice,1] = 1
    wait 5 [vDevice,1] = 1
    }

    Line 22 (09:11:20):: Feedback:On [33001:1:6177] - Channel 1
    Line 23 (09:11:20):: Output Channel:On - From [33001:1:6177] - Channel 1

    This is all that appeared in notifications. It appears to turn on just once.
  • AlexArtistAlexArtist Posts: 51
    DHawthorne wrote: »
    Yes; I tested it once in Diagnostics (with the caveat that it was a long time ago, and it's possible a firmware change has made it different since). I think level events behave the same way, but again, it's been a while since I actually tried it.

    Ok, probably was a firmware thing. Someone tested this and said the event only gets triggered once. I was acutally hoping this may be a way to re-trigger a level event. I don't like making the level jump from where it's at to 0 and then back again to re-trigger a level event. But it's not that bad i guess.
Sign In or Register to comment.