Do modules make sense for limited function?
jisaac
Junior Member
Gentlemen,
I understand that it is good form to use as many modules as are available, else write one when controlling specific devices. Does this however, still apply when you have a device for which you only need access to limited functions. example:
A module for an AV receiver.
i only ever use the following functions from any AV receiver ,
power on/off, volume up/down, mute, switch xxx_input.
would a module make sense for this, or would it just be ok written right into the main program?
thanks.
I understand that it is good form to use as many modules as are available, else write one when controlling specific devices. Does this however, still apply when you have a device for which you only need access to limited functions. example:
A module for an AV receiver.
i only ever use the following functions from any AV receiver ,
power on/off, volume up/down, mute, switch xxx_input.
would a module make sense for this, or would it just be ok written right into the main program?
thanks.
Comments
-
If there is a module available from AMX, I would try that first. Most modules for devices like an AV receiver make use of command queueing and two way feedback. If AMX doesn't have any modules available for the device you are controlling, you will have to decide how much control you want over the device and how reliable you need it to be.
I have written modules for Plasmas that only manage power and input switching, but I still wrote a module for portability and for ease of replacement should I ever need to upgrade to a different plasma.
Jeff -
Yes yes yes
Always use a separate module to control a separate device except for the most trivial ones eg relay control of a switch.
You may need only to send a very few commands but you still need a proper command queue and a state monitor so that your device module can worry about the box while your glue / control code worries about what the user wants.
However I would not recommend relying utterly on the AMX modules as they may let you down, and as the source code is not provided there's nothing you can do about it.
The box you refer to and what you want to do with it provide an excellent example of both issues. Power on / off has a timing implication, in that both can take some time and during that period other commands may be ignored.
That's certainly true for the Denon receiver I installed a while ago, and the AMX module that I installed missed that issue entirely. If you tell the module Power On - Mute set - Volume Set it will blindly send those commands to the box and of course the Mute and Volume commands are ignored. It became necessary to do the timing in the glue code, which meant that I had to build a state monitor and issue commands after due delays. -
I tend to make modules even for limited function devices, so when the time comes that I need to more functionality, I can expand it without rewriting all the code based on it. Reusability is the entire point of modules, after all.
-
I will write a module for things that have 2-way communication.
For things with only one-way (IR-only for example) I'll either write an Include File (don't have to transfer in and out any variables) or just copy-paste code from another project. Sometimes going through the hoops of writing a small module just isn't worth the time.
Of course, I tend to standardize all my touch panels. So the button numbers never change from one job to the next. -
ericmedley wrote:For things with only one-way (IR-only for example) I'll either write an Include File (don't have to transfer in and out any variables) or just copy-paste code from another project. Of course, I tend to standardize all my touch panels. So the button numbers never change from one job to the next.
I guess Eric is referring to things like VCR and DVD control by IR in cookie-cutter residential installations. I wish. Every job I do is complicated in some way so I always follow the yellow brick road and use modules.
All of my IR modules are in fact one generic IR module with different includes for the different boxes. You only have to write the module once and you can use it hundreds of times. You can therefore make it as clever as you like, with things like the ability to send a sequence of IR flashes for some purpose, to include pauses, and to have different pulse lengths.
Having invested the time in the generic module, I now find that IR control of new boxes tends to be very quick to do, and usually all I have to mess about with are things like getting forward and reverse the wrong way round. -
NMarkRoberts wrote:... and usually all I have to mess about with are things like getting forward and reverse the wrong way round.
Aha, good to know I'm not the only one who does that
.
Leave a Comment
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