Options
When I need to write a module !!
vidiasoftbv
Posts: 8
Dear AMX experts,
I would like to ask you something about writing a module. When is it necessary to write a module ?
Only when you want by example to re-implement an already existing AMX module or any time when you want to encapsulate together all the related functions and variables which implements the functionality of a specific hardware /software interface ?
In my application I have two Tv sets, one projector, one screen, a MET_ECOM...etc.
Is it wise to write a module which deal with all the functionality of the Tv sets ? A module which deal with the functionality of the Projector,..etc ? In general a define a different port for each hardware component witch has GUI.
If I implement all the functionality in one main file, it seems to me that it is very difficult to keep all the handling of the hardware interfaces in one file.
I don't give some data back to the main program, thus I only pass the GUI info to the modules and eventual the channels numbers. Also, I keep the constants in a axi file. If I have to change something I have to change it only in one file.
By background is software engineering and I was wandering if we can apply, the same techniques we use for developing OO applications, also for A/V applications.
I have been using AMX and ******** controllers for a few years and I am now trying to use the OO approach based on use cases and UML to develop the A/V applications.
On this forum has someone experience with OO approach for A/V applications ?
Thank you,
Ion
I would like to ask you something about writing a module. When is it necessary to write a module ?
Only when you want by example to re-implement an already existing AMX module or any time when you want to encapsulate together all the related functions and variables which implements the functionality of a specific hardware /software interface ?
In my application I have two Tv sets, one projector, one screen, a MET_ECOM...etc.
Is it wise to write a module which deal with all the functionality of the Tv sets ? A module which deal with the functionality of the Projector,..etc ? In general a define a different port for each hardware component witch has GUI.
If I implement all the functionality in one main file, it seems to me that it is very difficult to keep all the handling of the hardware interfaces in one file.
I don't give some data back to the main program, thus I only pass the GUI info to the modules and eventual the channels numbers. Also, I keep the constants in a axi file. If I have to change something I have to change it only in one file.
By background is software engineering and I was wandering if we can apply, the same techniques we use for developing OO applications, also for A/V applications.
I have been using AMX and ******** controllers for a few years and I am now trying to use the OO approach based on use cases and UML to develop the A/V applications.
On this forum has someone experience with OO approach for A/V applications ?
Thank you,
Ion
0
Comments
I have a basic rule-of-thumb that I follow on this.
I'll write a module for something that generally falls into these descriptions.
1) control of a single device that is used by more than one part of the program
2) Control of a single device that is tricky to control or involves a little more than single one-off commands.
3) Control of a device that has complex feedback.
4) something that runs 'under-the-hood' and doesn't effect the program.
5) I'm writing code to be used in other projects that I'm reasonably sure won't need to be tweaked. (Ex. pushing button one on the module's virtual device turns on a Surround Processor of brand X)
6) I don't have to pass a lot of information in and out of the module. (I'm not planning on using values from variables in the rest of my program.)
I'll wirte an include if
1) I'm just trying to separate a chunk of code that deals with a specific discipline (ex: Whole House Aduio) but might have differing parts.
2) I'm just writing code that might need tweaking over the process of creating the project.
3) I'm writing code that will be used in other projects with minor tweaks.
I've found that modules vs. include seems to be somewhat confusing to a lot of people. It took me a while to get my head around it since I've worked in other programming environments. AMX's useage of the definition 'Module' and 'Include' are somewhat different from how other environments define it.
The origianl think at AMX early on was that modules would antiquate the use of includes. I remember noting to myself at the time that it made no sense and that there were many valid uses of the Include. They've softened on their stance on that over time and now actively support the use of both.
I personally think it's important to think about the theory behind why you want to do something before actually doing it. If you've spent the time doing that, it will act as a guide while you bungle your way through actually learning how to do it. I've seen a lot of modules written by people who clearly didn't understand why they were doing it in the first place. Those modules tend to be very clunky and unflexible. Some of the early AMX modules come to mind in this regard. Other's that followed the rules and were solid in their approach are still rock-solid today.
well, that's enough theroy for now.
Personally, I have been trying my best to move to an OO type approach. It takes a little longer to code sometimes, but I have found it easier to make changes in the future. I also find myself dreading going back to old projects that are not programmed like my new ones because it is so easy to make a lot of changes in my new code and so complex to make some changes on the old code.
Jeff
This is the fallen state of all programmers...
I recently have been forced to go back to a huge project I did about 3 years back because the owner changed all his DirecTVs to Comcast Cable. He also wanted to make some tweaks on how stuff genrally works. The guy who programmed it was a jerk.
Now if only my girlfriend would realise that me asking her to pass me a beer is purely an investigation in language theory
I began developing modules about six months after NetLinx first came out. I came from an OO background, and found developing modules to be very similar to developing classes in Java. Like a class, a module gives you data and method encapsulation; however, you lose something when you think of method overloading or polymophism. The strength of modules (aside from being able to instantiate multiple instances of them) is their ability to send and receive COMMAND and STRING messages. This is very much like the ability to set objects to be event handlers for other objects.
That being said (though not very well), when it comes to the question of whether or not to create a module, you need to ask yourself: Is it something more than just a generic function that I would use again? Is it something I would use multiple instances of in one program? Is it functionality I want to hide or encapsulate?
I write my modules much like I would write a class: Keep device control seperate from UI control, keep middle tier functionality seperate from low level device control. Use messages to tie them all together. For example, any module I write for control of a device uses a command queue and timing features so that commands go out at the correct time. Additionally, any module using an RS-232 port to communicate with the device includes a little piece of code that basically says, "If the device number is zero, assume the connection is really an IP connection and adjust timing accordingly." Then, if I want to use an external device server (like a Lantronix UDS1100), I have another module whose sole purpose is to create and maintain an ethernet connection. Because I pass the same device to each module (let's say the device is defined as 0:2:0), when the ethernet module opens an IP connection, the device module gets a Data_Event OnLine message. I can treat this almost the same as if the device were a comm port, and all the other code is the same. Do you see what I'm getting at? The device module is able to connect to an IP device instead of a comm port device without adding all that code (error handling, connection retry code, etc) to the device module. This was possible because of the event messages that occur.
Now let's say you have four monitors you want to turn on together because they make up a video wall. If they are all controlled via modules, you ought to be able to send one message to an array containing a virtual device for each module instance, and all monitors will receive the message ALMOST instantaneously. What's that you say? The monitors only need the power on/off command? So obviously, writing a module to control a monitor just for power on/off is silly. Why not write a module that you can send a device, a time to wait after sending, and a buffer to hold a command. Let it manage sending out commands to devices using the timings that you tell it to use. Now, whenever you have a device to control in simple ways, you can use this module to send out commands in a controlled way. If you want to look at the receive from one of these devices you can simply create a Data_Event message for it.
Here's my last example of module uses. Let's say you have a lighting system that you use and it has many advanced features. You may also have code to control it in many different ways. It's unlikely you would want to keep all that code in include files, because jobs with multiple UI devices can make the project messy, and the code would need to change. However, if the different feature sets were broken into different middle tier modules, adding or removing features becomes much easier. You'd first start with a Comm module for the lighting system that would handle all the available commands. The virtual device you pass into the comm module is like the instance variable when a class is instantiated. So if you had a lighting scheduler module, you'd pass in the same virtual device. Then when the scheduler had to turn on certain lights, it could send the command directly to the comm module. The scheduling data would be passed into the scheduler module and to the UI module for the scheduler.
As you can see, each module you define can be designed, in many ways, like you were designing a class. Passing messages back and forth using a virtual device much like the instance of a class. Much of the power of NetLinx is in its ability to handle events. This is what you'd use to tie modules together in order to combine and enhance features.
I hope this helps,
Larry L.
Dang, these are some really good ideas - and mostly ones that I eventually came up with on my own. My background is in hardware design, and I have zero knowledge of OO programming, but some of this seems obvious:
- Keep protocol translation apart from user interfaces. I don't hold with AMX's concept of UI modules, because they assume and enforce one particular (poorly-scalable) model of device control. By using channels and levels as they do, they make the main program *less* comprehensible, which is a big problem for me. I can guess what sending an 'off' command to a display module might do, but it's not at all clear what pulsing channel 57 might do. I know, I know, documentation exists and is always complete, correct and clear. But still.
- Always queue. Extron switchers can handle some amount of rapid-fire commands, but most gear can't.
- Years ago, I wrote a general-purpose queuer module, and that has proved to be an excellent use of my time. I use it for devices I don't think I'll see much in the future, or for things that IMO are silly to use "Comm" modules for, like XAPs and Audia Flexes (because the specific commands and feedback needed change so much from job to job).
- Provide for the IP control case. Some equipment has both methods available, and it varies job-by-job which one I'll need to use.
Another potential strength of modules is a consistent interface to the main program. All my "display" modules work the same, and I can mostly upgrade projectors (for example) by just dropping in a new module. The main program just has stuff like send_command displays[3],'on' - exactly what that does is determined by the module. By using this approach, I can also have different brands/models of, e.g., projectors in the same system.
Generally I like my modules to do one thing, and do it well. Then I can, as Larry says, use messages to tie them together. This approach gives you a lot of flexibility. Like Larry, I wrote a separate module whose only task is to establish and maintain an IP connection - with timeouts, retries, etc. This means I can use any RS-232-oriented module - mine, AMX's or someone else's - and control it via IP (natively or Lantronix, Moxa, Extron IPtools) by just adding one line of define_module.
Finally, the question of whether or not to write a module is, to me, the same question as "is there a reasonable chance I'll see this equipment again?" If the answer is yes, then the answer is yes.