Home AMX User Forum AMX General Discussion

D:P:S message routing in M2M systems ??

If I have a system with 2 masters. Code for main system is on system 1, and let's say lighting control code is on system 2. System 1 has the URL of System 2 in it's URL list and M2M is set-up properly.
If I have a TP with the following definitions defined:
dvTP = 10001:1:1 //main TP
dvTPetc = 10001:2:1 //other TP functions
dvTPlights = 10001:3:2 //lighting functions


dvTP has the URL of M1 defined in system settings.

How do the messages get routed?
A push from dvTP would go from the panel directly to M1. Do messages from dvTPlights go to M1 first and then get routed to M2, or does the panel 'see' the second system and route messages directly to the second master?
When spreading code among multiple masters, what is the most efficient method of device communication? I can imagine that having all panels connected to one master could result in a lot of traffic on that master just routing messages to the appropriate locations for associated code.

Comments

  • ericmedleyericmedley Posts: 4,177
    PHSJason wrote: »
    If I have a system with 2 masters. Code for main system is on system 1, and let's say lighting control code is on system 2. System 1 has the URL of System 2 in it's URL list and M2M is set-up properly.
    If I have a TP with the following definitions defined:
    dvTP = 10001:1:1 //main TP
    dvTPetc = 10001:2:1 //other TP functions
    dvTPlights = 10001:3:2 //lighting functions


    dvTP has the URL of M1 defined in system settings.

    How do the messages get routed?
    A push from dvTP would go from the panel directly to M1. Do messages from dvTPlights go to M1 first and then get routed to M2, or does the panel 'see' the second system and route messages directly to the second master?
    When
    spreading code among multiple masters, what is the most efficient method of device communication? I can imagine that having all panels connected to one master could result in a lot of traffic on that master just routing messages to the appropriate locations for associated code.

    The messaging happens on both masters of they are connected M2M. If you're wanting code on the 2nd master to do something with the TP connected to master 1 you'll need to make a device declaration on the 2nd master's code and the use that in the program there.

    Same applies to other devices. You could, for example, monitor the serial port on master 1 from both master's programs. In fact the same modules could be running on each master monitoring the port on master 1. (not that you'd do this...)
  • ericmedley wrote: »
    The messaging happens on both masters of they are connected M2M. If you're wanting code on the 2nd master to do something with the TP connected to master 1 you'll need to make a device declaration on the 2nd master's code and the use that in the program there.

    Same applies to other devices. You could, for example, monitor the serial port on master 1 from both master's programs. In fact the same modules could be running on each master monitoring the port on master 1. (not that you'd do this...)

    I understand that declaring the device on both masters causes the message to 'show-up' at both masters, but how does it get there? Does the panel send one message to each master, or, does it send a message to M1 which then forwards it to M2? I am thinking that the panel sends the message to M1 which then relays it to all connected masters, but is this correct?
  • ericmedleyericmedley Posts: 4,177
    PHSJason wrote: »
    I understand that declaring the device on both masters causes the message to 'show-up' at both masters, but how does it get there? Does the panel send one message to each master, or, does it send a message to M1 which then forwards it to M2? I am thinking that the panel sends the message to M1 which then relays it to all connected masters, but is this correct?

    The touch panel sends the message to the master it's communicating with. The master then propagates the message to all other masters it's speaking to.

    It's the same thing going back. The other masters do not communicate directly back to the panel themselves.
  • ericmedley wrote: »
    The touch panel sends the message to the master it's communicating with. The master then propagates the message to all other masters it's speaking to.

    It's the same thing going back. The other masters do not communicate directly back to the panel themselves.

    So does the primary master propagate ALL incoming messages to all connected masters, or, does it route messages based on D:P:S (i.e. messages for system 2 go to M2, messages for system 3 go to M3 etc.), or does it only broadcast messages to all masters with correlating devices defined on the primary master?
    Is there a way or a need to streamline this process in large M2M systems?
  • BTW,

    Thanks for the info Eric. I am not trying to be difficult, just trying understand what is going on under the hood in some of these larger systems.
  • Spire_JeffSpire_Jeff Posts: 1,917
    PHSJason wrote: »
    dvTP = 10001:1:1 //main TP
    dvTPetc = 10001:2:1 //other TP functions
    dvTPlights = 10001:3:2 //lighting functions

    There is a flaw in the definitions here (if my assumption is correct). If all 3 definitions are supposed to refer to the same physical panel, the last definition is wrong. It should be 10001:3:1. On the second processor, you would define just dvTPlights = 10001:3:1. With this definition, the master would route all communications to processor 1 that come to that device. It would also generate all of the events locally that are passed to it by processor 1.

    I can tell you that I do a lot with M2M and I have only had problems when I have looped routes or a lot going on bootup. To fix the bootup issue, set DEVICE HOLDOFF ON. If you have a lot of M2M communication, you should also use ROUTE MODE DIRECT. There is a tech note that goes into detail about this.

    Jeff
  • Here is the general info on M2M.

    1. Device/ports send messages to the mast that they are connected to.
    2. Masters declare in their program which device/ports on other systems they desire to get notifications on.
    3. Masters share those lists, so that each master keeps a list of which device/ports they "own" and a corresponding set of masters that desire notification on those device/ports.
    4. When messages/events, etc come from a device/port, the master acts on that (if applicable by its program) AND forwards the message to the other masters that have requested notifications from that device/port.
    5. The distant masters receive those notifications, act upon then according to their program.
    6. When a remote master sends a message to a device/port on another system, the message is sent to the master that owns the device/port. The receiving master then forwards the message to the device/port.
    7. Device/port channels and commands are always shared across masters with masters that request notifications. For a String to be shared with a remote master, the remote master must have a CREATE_BUFFER or a DATA_EVENT String event handler declared for the DEV. For a level to be shared with a remote master, the remote master must have a CREATE_LEVEL or LEVEL_EVENT for any DEVLEV of the DEV.
    8. The above affect physical device/ports and virtual device/ports.


    I can answer specific questions if that is not clear.
Sign In or Register to comment.