When I need to write a module !!

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

Comments

  • ericmedleyericmedley Senior Member - 4000+ posts Posts: 4,166
    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 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.
  • Spire_JeffSpire_Jeff Formerly Caffeinated Programmer Posts: 1,917
    The question you are asking tends to fall into the personal preference category. If you think your are going to need the module to control the TVs on future jobs, and you cannot find a module that already exists, then writing a module might make sense. If you are doing something special for this job only, you might make it a series of function calls and pass the device to the function so you only need to write the functions once and use them for both TVs. If you already have a skeleton module and you just need to change the commands being sent, you might make it a module regardless.

    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
  • ericmedleyericmedley Senior Member - 4000+ posts Posts: 4,166
    Spire_Jeff wrote: »
    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... :D

    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.
  • PhreaKPhreaK Senior Member Posts: 966
    It's not 'necessary' to write a module, it's not 'necessary' to use functions, it's not 'necessary' to use constants or declare device either; it does help though. NetLinx and other coding languages exist to help us humans communicate with computers in an attempt to instruct them to perform specific tasks. As with all languages we can get lazy and relax the structure and grammer we use, humans are capable of basic communication via grunts and simple utterances - our ancestors managed to survive and communicate that way for quite some time, and it can still be seen within the bounds of many a share house. However as with all languages - spoken, written or code - the more structured and defined they become, the easier it is to convey deep meaning and assuming the target of the language posses a similar knowledge of this grammer and language structure, the more efficently this language can be utilized. To use the spoken vs code example you could probably instruct a fellow share house dweller to grab you a beer from the fridge while they are there purely through the use of grunts. By using two forms of grunt - one indication positive and one negative - varying the sound of the grunt the couch dweller could commicate his request to his/her kitchen based co-inhabitant. This would most likely turn into a rather lengthy process, but given time chances are the goal would eventually be reached. Alternatively using the more advanced grammer of english the exact intent could be commicated with ease and the goal reached in a more effecient manner. Now to relate this back to your question, no you do not need to use modules, but as the external party (the master) already has an understanding of them as a component of it's 'grammer' if the way you communicate utilizes them its another way to neaten up and improve effecieny and effectiveness of the langauge.

    Now if only my girlfriend would realise that me asking her to pass me a beer is purely an investigation in language theory :)
  • LCubed@snet.net[email protected] Junior Member Posts: 38
    Ion,

    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.
  • PhreaKPhreaK Senior Member Posts: 966
    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."
    Thats a really good idea.
  • DHawthorneDHawthorne Junior Member Posts: 4,584
    I write modules for any device more complicated than simple IR. I also write them to encapsulate portions of my program just to make it easier to deal with the components. For example, if I have a multi-room audio system and a theater room on the same job, I'll typically write the theater as a module so all it's code is in one spot, and not scattered throughout the multi-room code.
  • chillchill Luddite Posts: 186
    Ion,

    [...] 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.
    [...]
    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.
    [...]
    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.
    [...]
    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.
Sign In or Register to comment.