Inter-AMX Communication

winstonma

I have 2 AMX NIs on two difference physical locations, connecting through Ethernet. I wonder how to send command from one NI to another NI device? Thanks a lot

adys

Look here

http://www.amxforums.com/showthread.php?t=2381
http://www.amxforums.com/showthread.php?t=2456
http://www.amxforums.com/showthread.php?t=2674


There are all links that I asked about how to share messages and data

winstonma

Thanks for the message. But now I still have several questions on my head

1. I have 1 touchpanel controlling 2 NIs... how do the panel know which one is the master? (On the other hand, how do I define that one NI as slave)
2. Somehow I have 3 NIs and 2 panels totally
i) 1 panel and 1 NI for a small room
ii) 1 panel and 2 NI for the main room
and they are connected via the ethernet because there are only 1 amplifier on the system, so the small room need to forward the amplifier request to the master NI on the main room. Now I'm so confused how to make all the NIs connected together. And the touchpanel can find their own master accordingly

Hedberg

First, you have to set yourself up a network. On your network are all your masters, all your touch panels, a router (if you have one), your WAPs, and maybe your own computer. Every device on your network must have a unique IP address and all devices must be on the same subnetwork. Assign your IP addresses manually, trying to use DHCP will probably cause you trouble

winstonma wrote:

1. I have 1 touchpanel controlling 2 NIs... how do the panel know which one is the master? (On the other hand, how do I define that one NI as slave)

When you set up your touch panels, you tell the touch panel the IP address of the master it is to communicate with. You also assign your touch panels device numbers (default = 10001). Every touch panel that communicates to a single master must have a unique device number with respect to that master. So, the touch panel initiates communications and tells the master that you have assigned to that touch panel (with the master's IP address) what it's device number is. In the program, you define your devices so that the master can properly respond to transmissions from the touch panel.

All NI are masters -- AMX appears to be very anti-slavery.

winstonma wrote:

2. Somehow I have 3 NIs and 2 panels totally
i) 1 panel and 1 NI for a small room
ii) 1 panel and 2 NI for the main room
and they are connected via the ethernet because there are only 1 amplifier on the system, so the small room need to forward the amplifier request to the master NI on the main room. Now I'm so confused how to make all the NIs connected together. And the touchpanel can find their own master accordingly

Every NI master on your network must have a unique system number. You assign the system number with Netlinx Studio diagnostics "Device Addressing." The masters will default all being system #1 -- this is not good. Change them to a different integer.

All your masters need to be able to find each other on the network. You do this by setting the URLs in the diagnostic "URL Listing". The easiest way to do this is to edit the URL list of just one master and enter the IP address of all the other masters in that one. Every master will then be able to communicate with every other master on the network. I've read here that if you have a possible redundant path in the master-to-master routing that it can cause problems. I can't speak with authority on that.

SO:

a. set up your network with unique IP addresses. Put everything on the same subnet.

b. assign the masters unique system numbers

c. set up master-to-master communications by establishing linkage through the URL listings. Redundant paths should probably be avoided. If you have three masters, two URL entries in the URL listing of just one master (and nothing else) should do this.

d. link each touch panel to a single master by setting the system IP address when you set up the touch panel. Make sure no master has duplicate device numbers assigned to it.

e. in the define_device section of the program, you identify the tps that will communicate with that master. Also, identify every device that you want to control from that master by D:P:S (Device# : Port# : System#)

Now, every touch panel can be used to control every device on every master. The program in each master can be used to control any device on any master. Use the D:P:S paradigm with the 'S' set to the system number that owns the device you want to control.

For example, if you have tp # 10001 connected to system #1 and you want to send a serial string out device 5001 port #1 on system #2. You can do this a number of ways, here are two.

WAY # 1--receive the button press on system #1 and in the system #1 program, send the string to the device on system #2.

//on system # 1
define_device

dvTP = 10001:1:0
dvSys_2_Ser_Port_1 = 5001:1:2          //notice the system number of this device.

define_event

button_event[dvTP,nSomeButtonNumber]
{
  push:
  {
    send_string dvSys_2_Ser_Port_1,'SomeString'
  }
}

WAY # 2--receive the button press on system #2 and in the system # 2 program, send the string to the device on system #2. Everything on system #2.

//on system # 2
define_device

dvTP = 10001:1:1  //this is the touch panel that is associated with system # 1

dvSys_2_Ser_Port_1 = 5001:1:0          //notice the system number of this device.

define_event

button_event[dvTP,nSomeButtonNumber]
{
  push:
  {
    send_string dvSys_2_Ser_Port_1,'SomeString'
  }
}

See, you do it all with the D:P:S and by using the system #.

Note that if you want to receive button presses on one master from a TP on another master that you have to define the device on the master that you want to receive the button press from. Also, if you want to control a device on another master, you have to define_device of that device including the other master system #. Just like in the examples above.

If you are controlling a device that doesn't communicate much, the above examples would work fine. For example, if you have a Lutron lighting system connected to one master and the lighting system controls lights in numerous rooms, it would be pretty safe. But, if the device receives a bunch and responds a bunch (a complex audio setup with a bunch of XAPs and TH2s, for example) you probably want to set up a virtual device on the master that owns the device and send all your stuff from all your masters through that virtual device. Then you can set up command/string queues to make sure your communications are orderly and efficient. Also, you can control devices on all the masters, but you can't directly access parameters from one master to another. So, if you want to send some status information (as a result of a string returned from a serial device, for example) to another master, you can do it through virtual devices.

Another approach is to put _all_ the programming on just one master and use the other masters just as boxes of ports.

I know that this may sound complicated and arcane, but once you experiment with it a bit, it should become clear. There are some good tech notes on this stuff, and there are a lot of threads in these forums about all the stuff I've outlined.

AMXJeff

Master to Master

The best thing to do is link the masters into a master to master system. You do this by adding one of the masters in the others masters URL List. Please make sure that each master has a unique system id. This only needs to be done with one of the masters not both. If you do it on both it will be like ghost busters and crossing the streams.

You can create a virtual device in one of the masters and then reference that virutal device in the other master. Then you can send messages to the virutal device on either master. A data_event in each master will capture all the messaging sent to that virtual device.

// Master 1, System 1
DEFINE_DEVICE

vdvMasterComm = 33001:1:1

DEFINE_EVENT

DATA_EVENT[vdvMasterComm]
{
STRING:
{
 // MESSAGES FROM THE VIRTUAL
}
}


// Master 2, System 2
DEFINE_DEVICE

vdvMasterComm = 33001:1:1 // <----- notice system number is 1


DEFINE_EVENT

DATA_EVENT[vdvMasterComm]
{
STRING:
{
 // MESSAGES FROM THE VIRTUAL
}
}