Home› AMX User Forum› NetLinx Studio

Why Must Multiple Modules Be Defined Together?

nicholasjamesnicholasjames Posts: 154
in NetLinx Studio
I pointed out to someone today that multiple instances of a module must be defined together. But when asked, "Why?", I was stymied for a good explanation. The best answer I could offer was "Because it causes problems." Can anyone elucidate on the reason?

Thanks.

Comments

  • viningvining Posts: 4,368
    nicholasjames wrote: »
    I pointed out to someone today that multiple instances of a module must be defined together. But when asked, "Why?", I was stymied for a good explanation. The best answer I could offer was "Because it causes problems." Can anyone elucidate on the reason?

    Thanks.
    The only reason I could imagine is so you can easily verify the different instance names but I would think if each instance had a unique name you could put them anywhere. If you can't I'd also like to know why even though I can't imagine when or why I would ever want to do this.
  • nicholasjamesnicholasjames Posts: 154
    Sorry... did you see the link on "must be defined together". I probably should've pointed it out. It's to TechNote 527 that explains that you can't do it. The NetLinx help/Language Reference says the same thing:
    "Technically, modules can contain declarations to other modules, provided that no circular references are involved. However, because different instances of the same module must not be separated by instances of a different module, it is highly recommended that you do not declare modules from within other modules if you have multiple declarations of the parent module they will then be separated by the declarations of the child module."

    Now I don't necessarily want to declare a module inside another module but, like most people that come up against this problem, it'd make thinks a bit easier and neater to group related code together. For example, in the past I've used modules that allowed users to edit the text displayed when certain options were changed. So the user chooses "Input 1" for the display, but they can decide it should say "Laptop", and the lighting "Scene 1" now says "Meeting". This code was modularized, and if you wanted to add labeling functionality to a device, you just passed in the parameters for the touchpanel and button array for that particular device, and viola.

    What would save some time is if this code could be grouped into an Include to keep everything nice and neat. However, if you have a Display Include, and a Lighting Include, and there's a Labeling module in each one, then you have the same problem TN 527 talks about.
  • viningvining Posts: 4,368
    That TN was from 2003 I wonder if it still holds true with the current firmware?
  • nicholasjamesnicholasjames Posts: 154
    I wondered the same thing, though it's still in the NetLinx Keywords help for DEFINE_MODULE, and on page 133 of the NetLinx Language Reference Guide ("Using A Module In a Program").

    Though I've never seen this issue myself, this thread discusses it.
  • viningvining Posts: 4,368
    nicholasjames wrote: »
    I wondered the same thing, though it's still in the NetLinx Keywords help for DEFINE_MODULE, and on page 133 of the NetLinx Language Reference Guide ("Using A Module In a Program").

    Though I've never seen this issue myself, this thread discusses it.

    Reading that link Alexanbo confirmed the problem in 2006 post #16 but in 2007 nMarkRoberts wrote:
    Tech note 527 refers
    I just found tech note 527 from 2002 that says that you must declare modules in bunches. It seems this advice is now out of date.
    I think we need someone to intentionally try and break a system to see if this TN is still valid.
  • nicholasjamesnicholasjames Posts: 154
    vining wrote: »
    I think we need someone to intentionally try and break a system to see if this TN is still valid.
    You know, I'm just gonna contact AMX Tech Support to see what they say. I'll lay money they left it in there for backwards-compatibility. But, I must admit, I'm rarely backwards compatible. Welcome to the future. Now upgrade. ;-)

    Edit: That reminds me, is there an email address I can hit tech support at instead of using the "Contact AMX" form? Sometimes I have a question that would be best answered by someone at AMX with technical expertise, but it certainly doesn't necessitate filling out the official form. I don't have a "problem" that needs to go in the official duty list. I'm just curious.
  • jjamesjjames Posts: 2,908
    vining wrote: »
    I think we need someone to intentionally try and break a system to see if this TN is still valid.
    Done. Here's my test.
    NI-4000
    Master Firmware - v3.60.453
    Device Firmware - v1.30.8

    Main Program: 
    PROGRAM_NAME='Misorder Test'

define_variable
char prog_1 = '1';
char prog_2 = '2';
char prog_3 = '3';
char prog_4 = '4';

define_start  
define_module 'Blank_A' MOD_1 (prog_1) 
define_module 'Blank_B' MOD_2 (prog_2) 

define_module 'Blank_A' MOD_3 (prog_3) 
define_module 'Blank_B' MOD_4 (prog_4)

    Blank_A.axs 
    MODULE_NAME='Blank_A'(char number)

define_start
send_string 0,"'Module #',number,' has started'";

define_program
wait 100
{
	send_string 0,"'Module #',number,' is running'";
}

    Blank_B.axs 
    MODULE_NAME='Blank_B'(char number)

define_start
send_string 0,"'Module #',number,' has started'";

define_program
wait 100
{
	send_string 0,"'Module #',number,' is running'";
}

    Results: 
    Line      6 (10:55:21.561)::  CIpInterpreter::Run - Execute Startup Code
Line      7 (10:55:22.060)::  Module #1 has started
Line      8 (10:55:22.062)::  Module #2 has started
Line      9 (10:55:22.063)::  Module #3 has started
Line     10 (10:55:22.064)::  Module #4 has started
Line     11 (10:55:22.067)::  CIpEvent::OnLine 0:1:1
Line     12 (10:55:22.069)::  CIpEvent::OnLine 5001:1:1
Line     13 (10:55:22.071)::  CIpEvent::OnLine 5001:2:1
Line     14 (10:55:22.073)::  CIpEvent::OnLine 5001:3:1
Line     15 (10:55:22.075)::  CIpEvent::OnLine 5001:4:1
Line     16 (10:55:22.077)::  CIpEvent::OnLine 5001:5:1
Line     17 (10:55:22.079)::  CIpEvent::OnLine 5001:6:1
Line     18 (10:55:22.081)::  CIpEvent::OnLine 5001:7:1
Line     19 (10:55:22.083)::  CIpEvent::OnLine 5001:8:1
Line     20 (10:55:22.085)::  CIpEvent::OnLine 5001:9:1
Line     21 (10:55:22.087)::  CIpEvent::OnLine 5001:10:1
Line     22 (10:55:22.089)::  CIpEvent::OnLine 5001:11:1
Line     23 (10:55:22.092)::  CIpEvent::OnLine 5001:12:1
Line     24 (10:55:22.094)::  CIpEvent::OnLine 5001:13:1
Line     25 (10:55:22.096)::  CIpEvent::OnLine 5001:14:1
Line     26 (10:55:22.098)::  CIpEvent::OnLine 5001:15:1
Line     27 (10:55:22.100)::  CIpEvent::OnLine 5001:16:1
Line     28 (10:55:22.102)::  CIpEvent::OnLine 5001:17:1
Line     29 (10:55:22.104)::  CIpEvent::OnLine 32001:1:1
Line     30 (10:55:25.265)::  IPDeviceDetector.run(): joined multicast group
Line     31 (10:55:32.074)::  Module #1 is running
Line     32 (10:55:32.076)::  Module #2 is running
Line     33 (10:55:32.078)::  Module #3 is running
Line     34 (10:55:32.079)::  Module #4 is running
Line     35 (10:55:42.091)::  Module #1 is running
Line     36 (10:55:42.093)::  Module #2 is running
Line     37 (10:55:42.095)::  Module #3 is running
Line     38 (10:55:42.096)::  Module #4 is running
  • viningvining Posts: 4,368
    Well I guess that proves nMarkRobert was correct in 07' and we can't believe every TN we read. Nice test JJ. :)
  • DHawthorneDHawthorne Posts: 4,584
    I'm not so certain such a simple module is a definitive test of this. I was told, once upon a time, that part of the module instancing process is that all the internal entities are copied to their own memory space and prefixed internally with the instance name to prevent data collisions. But the real question is how is all that indexed and stored. If all they do to access a variable from module 2 is increment the pointers from module 1 the memory size of the module, then different modules allocated sequentially are going to screw it up.
  • champchamp Posts: 261
    I have created room modules in the past when a single processor controls multiple separate rooms. This almost makes the code processor independant, ie almost no code change required if there is 1 processor per room or 1 processor for all rooms.
    Each module has had modules within and often multiple rooms will have the same devices hence the same modules.
    This would have meant multiple identical projector modules (and others) were defined in different sections of the code.
    I don't recall having any issues which weren't standard programming issues when doing this.
Sign In or Register to comment.