Issues With Modules

I have been working on this program for a client and everything seems to be ok but when I add more instances of the module none of the DMS keypads, or touchpanels will work.
Anyone have any ideas?
I have attached the full workspace.
Thanks Again
Anyone have any ideas?
I have attached the full workspace.
Thanks Again
0
Comments
Are you encountering problems when you define multiple DMS Keypads? Or when you define multiple Z_Tuner modules?
On a quick look at what you have, it seems that you are defining multiple instances for a single tuner device. There should only be one comm module defined per physical device. I think you may need to split your modules into COMM and UI modules. I think the fact that multiple modules are trying to talk to one device independant of each other is causing your problem.
There are a couple ways in which you could handle the task. You could use a virtual device for UI interface and combine other interface devices on the fly. You could use device arrays and different ports. I'm sure someone can come up with another way or ways as well.
If this is the module definition you are refering to, I will try to give you a few more details to try and help.
Jeff
Music Module :
ReQuest Module :
Z-Tuner Module :
These are the only other instances that I need to add because its the only 2-way touchpanel that I have.
Hope this helps to clear things up
Thanks again
The others seem to be working fine.
Spire_Jeff -- I will try what you suggested about splitting them up into a COMM / TP files to see if that helps. Thanks for the input. If anyone else has any ideas please let me know.
Thanks
Are there just three touch panels or six? The above would indicate six but I'm thinking you only have three and the arq's should be ports on the TP's not there own TP.
You are correct there are only 3 panels. I will try the above and see if that fixes the issues. But I could have sworn that the way I have it posted is what I have done on a number of jobs without any ill side effects. Thanks for the input I will let you know the results tommorrow.
Thanks again
You are doing it correctly. Based on the addresses, you are using the older G3 panels which don't have the options of different ports. Each touchpanel has the ability to be 1-4 different devices with I think it was 256 channels per device.
The new G4 touchpanels are much nicer and allow you much more flexibility. The graphics options are also a LOT better
Jeff
Guess its time to rewrite these modules for use in seperate files. Thanks again guys for the help and input. I will keep you posted
Should I do it as include files?
Thanks for the guidance
To conform to the model AMX endorses, you should write two different modules. You should pass your Comm module the port the device is on, and a virtual device you define in your main program.
You should pass your UI module a touchpanel, and the same virtual device you used for the Comm module, in addition to the channel sets and address sets and whatever else you feel like sending it. That way, if you need to add a touchpanel, you just define another instance of the UI module with another touchpanel.
example
For instance this is good
Define_module 'X' mdl1(vdvDEV,dvDEV)
Define_module 'X' mdl2(vdvDEV,dvDEV)
Define_module 'Y' mdl3(vdvDEV,dvDEV)
This is bad
Define_module 'X' mdl1(vdvDEV,dvDEV)
Define_module 'Y' mdl2(vdvDEV,dvDEV)
Define_module 'X' mdl3(vdvDEV,dvDEV)
And of course each instance of the same module needs an unique identifier.
When I read this I thought "good thing I always do that" but I've just realised that my current project groups modules by room not by name, so it breaks this rule, and it works fine.
Alexanbo, what problems have you observed?
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.
Sorry I don't mean to hijack an old thread - but I don't get to read very often!
I have been creating modules for mixers to control volume/mute status. Usually I'll add one instance for each volume bar I have. This is because I want to reference a particular volume input/output/processing bus/block of the device.
For Clearone I want the UnitID, Channel number, & Channel Type
For Biamp I want the UnitID,InstanceID of Block, Type of Block, Index1, Index2
I'm not really sure how I can get around this as I want to always compare the incoming string to some particular data. Each instance takes a look at the incoming data and asks "are you for me?" Nine may say no - but one may say yes and continue processing the data. Is this bad? Is there some way to pass this information through a UI module and execute only the module I'm concerned with? I don't really have the problem that I'm adding more and more touch panels. I'm adding more and more volume bars.
Thus far I have not had any issues. My touch panel voluem bars respond just fine with many instances included. I just saw this thread and got concerned that this might cause problems in the future.
Here's how I do this, and never ever let it be said that controlling volume is easy. It seems to me that every installation does it completely differently. I always do volume control last cos it's hard work and every job I do seems to be very different from the last one.
For every physical device that has volume control write a driver module which, among other things, translates a standard volume control command into whatever that device requires. It can accept this command from anywhere. It knows nothing about the system, just this one device. You can reuse this module in every installation that uses this equipment.
For each room write a control module which runs the UI and does everything except volume control, apart from passing on volume button pushes and sending system start / stop commands.
Enumerate the different volume controls somehow, one for each slider / up / down seen on the UI. That could be one per room, or one per zone, or 1 = Master volume and 2 = Mic vol and 3 = "Whichever AV device is currently selected". It totally depends on the nature of the system.
Write a generic volume control module that controls an array of volumes and knows all about the nuances of volume control for each controlled volume:
Minimum permitted volume
Maximum permitted volume
Default volume
Current volume
Number of steps from min to max
Number of increments per second
Maximum ramping time to prevent runaway
Automated unmuting on volume change
...and so it goes on
This module knows nothing about the system, and calls an included volume-setting routine for all system-specific knowledge. You can reuse this module in every installation, and you can make it as clever as you like. You could use multiple instantiation of a module which controls just one volume channel, but I haven't, not sure why!
Finally, write an include file that knows all about volume control in this system, and when asked by the generic volume control module to set the volume for particular enumerated volume channel, sends the right generic command to the right device module. This code turns out to be very easy to write after you have made all of the investments listed above!