Why Must Multiple Modules Be Defined Together?
nicholasjames
Junior Member
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.
Thanks.
Comments
-
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.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. -
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. -
That TN was from 2003 I wonder if it still holds true with the current firmware?
-
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. -
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:
I think we need someone to intentionally try and break a system to see if this TN is still valid.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. -
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. ;-)I think we need someone to intentionally try and break a system to see if this TN is still valid.
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. -
Done. Here's my test.I think we need someone to intentionally try and break a system to see if this TN is still valid.
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.axsMODULE_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.axsMODULE_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
-
Well I guess that proves nMarkRobert was correct in 07' and we can't believe every TN we read. Nice test JJ.
-
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.
-
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.
Categories
- All Categories
- 2.5K AMX General Discussion
- 922 AMX Technical Discussion
- 514 AMX Hardware
- 502 AMX Control Products
- 3 AMX Video Distribution Products
- 9 AMX Networked AV (SVSI) Products
- AMX Workspace & Collaboration Products
- 3.4K AMX Software
- 151 AMX Resource Management Suite Software
- 386 AMX Design Tools
- 2.4K NetLinx Studio
- 135 Duet/Cafe Duet
- 248 NetLinx Modules & Duet Modules
- 57 AMX RPM Forum
- 228 MODPEDIA - The Public Repository of Modules for Everyone
- 943 AMX Specialty Forums
- 2.6K AMXForums Archive
- 2.6K AMXForums Archive Threads
- 1.5K AMX Hardware
- 432 AMX Applications and Solutions
- 249 Residential Forum
- 182 Tips and Tricks
- 146 AMX Website/Forums
