Master to Master question

Jeff · August 2007

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

Marc Scheibein · August 2007

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.

Jeff · September 2007

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

NMarkRoberts · September 2007

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.

Jeff · September 2007

So how do I figure out whats doing it? I'm sort of at a loss here . . .

DHawthorne · September 2007

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.

Jeff · September 2007

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

Jeff · September 2007

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

Danny Campbell · September 2007

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_Jeff · September 2007

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

Chip Moody · September 2007

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

DHawthorne · September 2007

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.

AlexArtist · May 2009

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?)

AlexArtist · May 2009

Marc Scheibein wrote: »

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?

DHawthorne · May 2009

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.

kbeattyAMX · May 2009

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.

AlexArtist · May 2009

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.

Master to Master question

Comments