#########################
# Squeeze EVERY last bit out of the processor
#########################
tip - If you need to make every single processor cycle count, use ON[variable] and OFF[variable] instead of variable=TRUE and variable=FALSE.
G'day Jeff,
I have found that using ON and OFF also use less memory.
I know that you have written some very large programs, do you have any tips for reducing compile size?
The reason I ask is that the tkn file for the job I am currently doing is already over 5.3MB and I still have a fair bit to write.
Have you come across any issues with very large programs?
Are you trying to run everything on 1 processor? If so, anything you can move to other processors will help greatly. I always run the COMM modules on the processor that is physically connected to the device. In recent years, I have even split my UI code into a separate processor. The UI compiled code is around 3MB right now.
Another thing is multidimensional arrays versus an array of structures. It depends on what you are trying to accomplish and how the data is formatted, but in most cases the structure method is preferred.
As for issues, one of the big reasons I moved the UI code to a separate processor was because I was running into problems with start up times and also with memory usage. One thing that has been added (or I have learned about since) is the device holdoff feature in the processors. This will prevent devices from coming online until the processor is ready to deal with them.
The last thing that comes to mind is multiple instances of the same module. I had so many problems, I stopped doing it. I am not sure if this has been fixed, but button hold events would be lost on all but the first module declared. Also, when passing in arrays of devices, each module allocates its own memory space for the devices or something along those lines and lots of memory is chewed up, not to mention painfully long boot times.
I have found that using ON and OFF also use less memory.
I know that you have written some very large programs, do you have any tips for reducing compile size?
The reason I ask is that the tkn file for the job I am currently doing is already over 5.3MB and I still have a fair bit to write.
Have you come across any issues with very large programs?
Cheers
Note that AMX now offers high-memory NetLinx units with 256Meg instead of the current 64meg.
After OS overhead, that yields about ten times the program space of the current units. About $250 extra. A bargain when memory matters.
I may be wrong, but isn't an upgrade to memory without an upgrade to the processor like loading in 4 tons of dirt into a Ford Ranger when you need a dump truck? If you manage to fill up that much memory - I'd love to see what the startup time is.
And if someone says, "Well startup only happens once", then it shouldn't matter if your computer takes 10 minutes to boot?
I may be wrong, but isn't an upgrade to memory without an upgrade to the processor like loading in 4 tons of dirt into a Ford Ranger when you need a dump truck? If you manage to fill up that much memory - I'd love to see what the startup time is.
No, adding memory isn't like a truck that you are trying to fill up with dirt. Its a resource, and more memory resources usually means you can get away with doing less computation freeing the processor to do other tasks. Algorithms often have to choose between being processor intensive or memory intensive, and previously you didn't have a choice. More memory is always good, I find it hard to believe anyone would think otherwise.
And if someone says, "Well startup only happens once", then it shouldn't matter if your computer takes 10 minutes to boot?
How does adding memory slow boot time? Memory is fast. VXWorks doesn't do any paging or swapping so hard memory is all you have for everything, so more is always better. Many things in AMX are limited by the amount of memory you have so by increasing those limits, you can do more.
Paul
How does adding memory slow boot time? Memory is fast
Oh, ok. I was only asking because my larger systems that need to allocate more memory than my smaller systems (older systems using less variables because of less options) take much longer to boot.
Is this memory that they've added equivalent to RAM or hard disk memory? Bit of a difference.
Oh, ok. I was only asking because my larger systems that need to allocate more memory than my smaller systems (older systems using less variables because of less options) take much longer to boot.
Is this memory that they've added equivalent to RAM or hard disk memory? Bit of a difference.
As described last go round, this is PROGRAM MEMORY not to be confused with FLASH CARD STORAGE memory that you can easily upgrade. This was formerly impossible.
And yes, the more you make it do, the longer it takes to do it. But that's better than not being able to do it.
We used to have to tell customers they couldn't have more than 24 panels if they had more than 32 rooms. Now they can have anything they want. There may be longer boot times when you have to set up many more devices, but being able to get there is worth the wait.
We used to have to tell customers they couldn't have more than 24 panels if they had more than 32 rooms. Now they can have anything they want. There may be longer boot times when you have to set up many more devices, but being able to get there is worth the wait.
Hmm.. that's some pretty serious systems you are talking about. How does AMX cope once it's up and running?
Do you get much lag when the system is really busy?
Hmm.. that's some pretty serious systems you are talking about. How does AMX cope once it's up and running?
Do you get much lag when the system is really busy?
Performance at any given time is indistinguishable in a 48 room system compared to a 3 room system, as everything is event driven, and panels are told what they need only when they need it. If there were 100 rooms IN USE BY 100 PEOPLE on 100 TOUCH PANELS all manipulating things at the same moment, there would be delays, probably really annoying delays. But that won't happen in even the busiest residence. With 5 to 10 people actively TRYING to interfere with each other in a "let's see if we can bring it down" contest... they can't really tell they aren't alone. In a real environment, there will seldom be more than a few actions at any one time.
Apparently we do things fairly differently than most. AMX tech folk have repeatedly commented on how fast our pages and actions are... well, they are just as fast in the middle of a huge system.
Apparently we do things fairly differently than most. AMX tech folk have repeatedly commented on how fast our pages and actions are... well, they are just as fast in the middle of a huge system.
Quite frankly, that has always been the biggest weakness in AMX provided modules and programs. It has always seemed to me they are developed and tested in a one-device, one-panel sandbox and have a tendency to fall apart in a real-world environment. The ones that kill me the most are the type that require a separate instance of the UI module for each control panel ... how can that possibly work efficiently if you have a dozen or more panels? Yet, it was the AMX standard for a number of years. All indications are they are trying to improve the situation, but progress is slow.
Apparently we do things fairly differently than most. AMX tech folk have repeatedly commented on how fast our pages and actions are... well, they are just as fast in the middle of a huge system.
Don't get your hopes up. If you think you're one in a million, there are six thousand people out there just like you. :-D
Gonna have to go with Dave's thoughts - I believe AMX is just not that well experienced in real-world thoughtfulness. Have you seen or heard about the MVP-9000i? Or the high gloss MVP-5200i? How about the R4?
Quite frankly, that has always been the biggest weakness in AMX provided modules and programs. It has always seemed to me they are developed and tested in a one-device, one-panel sandbox and have a tendency to fall apart in a real-world environment.
I agree. AMX modules are most often more useful as examples than as solutions.
I agree. AMX modules are most often more useful as examples than as solutions.
Of what? How not to write modules.
The only useful example would be if they opened up the com module. Then we would at least have a starting point to re-write and make their modules useful and customize them to our styles, needs and save some time so we can sell more AMX. Otherwise having 100's, maybe 1000's of modules that most folk don't use for one reason or another, since are many reasons, makes no sense. The one thing they could be useful for they don't allow and that's accessing the com module's code.
The only useful example would be if they opened up the com module. Then we would at least have a starting point to re-write and make their modules useful and customize them to our styles, needs and save some time so we can sell more AMX. Otherwise having 100's, maybe 1000's of modules that most folk don't use for one reason or another, since are many reasons, makes no sense. The one thing they could be useful for they don't allow and that's accessing the com module's code.
My first AMX project used a Yamaha receiver. Being new to AMX, I tried AMX's module. I was frustrated as it was closed, but I went on anyway. Due to a bug in the module, the system would lock up between two hours and two days later - hard lock up, the only way to get it running again was to reset the master. Removing the module stopped all lockups.
So, I called and inquired about the code. It took some hassle but they said they MIGHT get it to me, if I am willing to sign an NDA. Yes, an NDA for a module to control a medium line stereo receiver. Something for which a control protocol is readily available for.
I ended up rewriting the module - my interface code was far cleaner, the master was far more responsive, and it didn't lock up anymore.
When I later started writing Cres systems, and found that not only are their modules open but there is at least one large community group who shares code openly (*1), I really wondered - why is AMX still closed? What do they stand to gain from minimal testing and broken modules?
I've used a number of partner and other modules for Cres systems... or used information in said modules to understand an implementation, and write my own module... released a few myself as well... but I don't use AMX-sourced modules (*2). I write my own. It's too frustrating debugging problems when I can't see the code.
(*1 - in addition, ANY password-protected Cres module can be opened and looked at...aha)
(*2 - the only one I am using is the iPort Duet module, and only when necessary, because I haven't finished my module yet. I've fixed numerous bugs in the included panel interface module, reducing CPU usage dramatically, as well as adding UTF-8 support.)
Well, as long as we're bashing AMX modules, might as well join in. Nothing like a mob, init?
Several years ago I tried to use a Duet module for a Lectrosonics conferencing mixer. Even though the mixer would send easy to interpret status messages back to the module, the module insisted on keeping track of levels internally -- ignored feedback from the mixer. Very frustrating, but the Lectrosonics is not hard to control, so went without the module.
Just the other day had the joy of controlling a 2X2 matrix of large NEC LCD screens. There is a module for these, but it didn't respond properly to send_commands. Really would have like a decent module for this one as the NEC protocol is the most obtuse I've ever seen, but even if the module worked properly, it isn't easily configurable to the multiple screen matrix thing and controls for the matrix, best I can tell, aren't included in the module.
Been looking at the module for the new Polycom SoundStructure audio mixer/telephone interface. I liked the way the Vortex protocol worked, but that's gone so I have to do something. Looks like the Duet module for this thing is way, way too complicated when all you want to do is control a teleconference dialer and adjust some audio gains/levels. I think it would take twice as long to try to get the module to work properly as it will be to just modify the Vortex code that I already have.
Well, as long as we're bashing AMX modules, might as well join in. Nothing like a mob, init?
Are y'all refering to the comm modules or the UI modules? I can count on one hand the times I have had issues with comm modules. The UI modules are just for an example though, and in no way are written to use without serious modification or rewrite. I would have to say that my experience with AMX modules has been the exact opposite of most here. Odd.
Paul
Are y'all refering to the comm modules or the UI modules? I can count on one hand the times I have had issues with comm modules. The UI modules are just for an example though, and in no way are written to use without serious modification or rewrite. I would have to say that my experience with AMX modules has been the exact opposite of most here. Odd.
Paul
The three instances I was whining about:
1. Lectrosonics returns simple to parse strings indication mute and gain status. Comm module ignores these returned strings and resets all gains to mid point at every start up. It's not hard to write code to supplement the comm module and set the levels and channels that it uses to keep track of gains and mutes, but that obviates the usefulness of the module. This is a comm module issue, not UI.
2. NEC multisync comm module does not respond properly to send_commands as specified in the user documentation. Specifically the ?PROPERY and PROPERTY send_command dialog does not function. As a result, couldn't set the necessary device ID for the target monitor (all monitors function from one RS232 port. The comm module does not appear to allow grouping of the monitors into a single display or the ungrouping of the monitors so that they display independently. This is the most important reason why these monitors are used and the absence of these controls from the comm module makes the comm module useless.
3. I haven't actually tried to implement the module for the Polycom SoundStructure mixer/telephone hybrid, but I've looked at both the module documentation and the Polycom documentation and I see no point in writing code for a more complicated protocol than the protocol of the device itself. Particularly when I'd like to stay Duet free as life is way to short already. I do notice that there is basic functionality in the Polycom protocol (assignment of physical channels to the necessary virtual channels) that is not available in the AMX comm module.
I'm with a_riot42 on this one - if we're talking duet comm modules. I wouldn't touch any of the UI or NetLinx based modules with a long stick. AMX definately seem to be (at least prior to now) lacking in quality control and pre-release testing standards, however there are at least a couple of authors that seem to produce pretty stable work. Branding every single AMX module as a steaming pile of you know what is akin to saying that all control systems are destined to be buggy and horrible just because you were scarred by a couple of systems running poorly written code a few years ago.
From what I've heard the internally rolled modules use the AMXTools framework. If you ask the right people its not to hard to obtain a copy which will at least provide some insight to the internal structure.
Branding every single AMX module as a steaming pile of you know what is akin to saying that all control systems are destined to be buggy and horrible just because you were scarred by a couple of systems running poorly written code a few years ago.
Most of my bad experiences occured trying to use standard Netlix modules and you can only get burned so many times before realizing it's not worth it to even try anymore. So now I'm gun shy of standard AMX modules and I try not to use and to the best of my knowledge don't use DUET modules because of the performance hit which everyone talks about. I will ocassionally use the standard com modules and toss the rest when I'm being lazy or feeling stupid but otherwise I'd rather roll my own.
If com modules were open everyone would benefit. The AMX community would contribute more in providing better code that every one could use. In the end AMX would benefit by having better code available, better examples for newbies to emulate and build their own modules from. A win, win for all.
Let me pile on about a couple of modules that I had trouble with.
Both were Duet modules. Both were with the comm module since I never use the UI modules for anything.
First is the on for the NEC LCD6250 display. It works fine when you are only loading a module for one display. Load a second instance and it not only kills itself, but steps all over the other duet modules you have loaded. I just went without using a module in this case.
The second was for the Sony SRXT110 projector. This one would only semi-work. My problem here was with the lamp hour feedback. The projector sends back a simple message with the hours for both lamps. The module doesn't know what to do with this. I ended up writing my own module for this projector.
I've had mixed results with standard AMX Netlinx modules. Some work quite well for me, some don't. I tend to give them a try at first and bail pretty quickly if I sense danger in the air.
I've had real good luck with the Lutron Homeworks module. Also, the Apex Destiny 6100 (RIP) worked quite well too.
Modules on my bottom 10 list: AMX MAX. all 10 spots... (RIP)
You guys do realize there's another side to this coin, right?
Say someone calls AMX TS and says "hey I am having problems with my system, I have an Autopatch switcher, I'm using your module, and it doesn't work."
TS can pull up the documentation, source of the module, and walk the user through some tests to make sure the device is talking and the feedback from the module is being interpreted correctly by the user's main program, etc. So it seems there might be SOME benefit from standardization.
Now suppose in an alternate universe, someone calls AMX TS and says "hey I am having problems with my system, I have an Autopatch switcher, the system doesn't work as expected; I downloaded the module from your website a month ago before version 1.3 was published, changed lines 234-238 because I think mute feedback should be returned as a level, 260-273 because I wanted the module to return the zones first and not the source for SWITCH= feedback, and line 74-82 for some other reason."
Remember, there was a day when it was not assumed AMX programming would be done by programmers.
You guys do realize there's another side to this coin, right?
Yeah that's the age old argument for keeping AMX modules locked up. Since most of us are adults here I'm pretty sure we can manage to find a way to overcome this minor little problem. How about no TS for unlocked mods versions. AMX can keep there intact locked module with full TS support and there can be an open version for us to play with. Then the froums can do what they do best and be the tool for this support. There could be someone in AMX to evaluate modifed mods upon request and if it makes sense they can update the locked version. Plus were open 24/7 and don't cost $1,200.00 per year. Chances are if a person is having code problems they're better off here anyway and they are probably also in the pricing level where they don't recieve free TS either.
I have no problem with the concept of AMX distributed modules and I don't even mind too much that the modules are locked down. It's a very tempting option to have a solution to a new piece of RS232 controlled equipment -- nice solution requiring a minimum of trouble writing code and getting the thing to work, it's a very nice idea. My problem is that almost invariably there is something that doesn't work right or there is something important missing from the functionality that I need. Then there is often the case that the damned module won't work without a particular response string from the physical device so it can't be tested/evaluated except on site -- typically I don't have access to the equipment beforehand. I know that's what's commonly called a "personal problem", but it's the situation I have to work with. Then there is the problem with bloat. And, have I mentioned that the documentation for every AMX module I have ever looked at totally sucks?
If the module is mostly functional, you can always use the PASSTHRU and PASSBACK options to add the couple of commands you need. Still a lot better than writing the whole thing from scratch in most cases. I have have my share of bad results, but over all, most of the AMX Comm modules are good. As was stated before, the UI modules are provided only as points of reference designed for testing, not implementation.
Comments
G'day Jeff,
I have found that using ON and OFF also use less memory.
I know that you have written some very large programs, do you have any tips for reducing compile size?
The reason I ask is that the tkn file for the job I am currently doing is already over 5.3MB and I still have a fair bit to write.
Have you come across any issues with very large programs?
Cheers
Are you trying to run everything on 1 processor? If so, anything you can move to other processors will help greatly. I always run the COMM modules on the processor that is physically connected to the device. In recent years, I have even split my UI code into a separate processor. The UI compiled code is around 3MB right now.
Another thing is multidimensional arrays versus an array of structures. It depends on what you are trying to accomplish and how the data is formatted, but in most cases the structure method is preferred.
As for issues, one of the big reasons I moved the UI code to a separate processor was because I was running into problems with start up times and also with memory usage. One thing that has been added (or I have learned about since) is the device holdoff feature in the processors. This will prevent devices from coming online until the processor is ready to deal with them.
The last thing that comes to mind is multiple instances of the same module. I had so many problems, I stopped doing it. I am not sure if this has been fixed, but button hold events would be lost on all but the first module declared. Also, when passing in arrays of devices, each module allocates its own memory space for the devices or something along those lines and lots of memory is chewed up, not to mention painfully long boot times.
Hope this helps,
Jeff
Yep, compiled size anyway. I'll check run time size and get back to you.
Note that AMX now offers high-memory NetLinx units with 256Meg instead of the current 64meg.
After OS overhead, that yields about ten times the program space of the current units. About $250 extra. A bargain when memory matters.
And if someone says, "Well startup only happens once", then it shouldn't matter if your computer takes 10 minutes to boot?
No, adding memory isn't like a truck that you are trying to fill up with dirt. Its a resource, and more memory resources usually means you can get away with doing less computation freeing the processor to do other tasks. Algorithms often have to choose between being processor intensive or memory intensive, and previously you didn't have a choice. More memory is always good, I find it hard to believe anyone would think otherwise.
How does adding memory slow boot time? Memory is fast. VXWorks doesn't do any paging or swapping so hard memory is all you have for everything, so more is always better. Many things in AMX are limited by the amount of memory you have so by increasing those limits, you can do more.
Paul
Wow, that's a huge program, over twice as large as the largest tkn in any of my projects, even with multiple duet modules in them. Why so large?
Paul
Is this memory that they've added equivalent to RAM or hard disk memory? Bit of a difference.
As described last go round, this is PROGRAM MEMORY not to be confused with FLASH CARD STORAGE memory that you can easily upgrade. This was formerly impossible.
And yes, the more you make it do, the longer it takes to do it. But that's better than not being able to do it.
We used to have to tell customers they couldn't have more than 24 panels if they had more than 32 rooms. Now they can have anything they want. There may be longer boot times when you have to set up many more devices, but being able to get there is worth the wait.
Hmm.. that's some pretty serious systems you are talking about. How does AMX cope once it's up and running?
Do you get much lag when the system is really busy?
Performance at any given time is indistinguishable in a 48 room system compared to a 3 room system, as everything is event driven, and panels are told what they need only when they need it. If there were 100 rooms IN USE BY 100 PEOPLE on 100 TOUCH PANELS all manipulating things at the same moment, there would be delays, probably really annoying delays. But that won't happen in even the busiest residence. With 5 to 10 people actively TRYING to interfere with each other in a "let's see if we can bring it down" contest... they can't really tell they aren't alone. In a real environment, there will seldom be more than a few actions at any one time.
Apparently we do things fairly differently than most. AMX tech folk have repeatedly commented on how fast our pages and actions are... well, they are just as fast in the middle of a huge system.
Quite frankly, that has always been the biggest weakness in AMX provided modules and programs. It has always seemed to me they are developed and tested in a one-device, one-panel sandbox and have a tendency to fall apart in a real-world environment. The ones that kill me the most are the type that require a separate instance of the UI module for each control panel ... how can that possibly work efficiently if you have a dozen or more panels? Yet, it was the AMX standard for a number of years. All indications are they are trying to improve the situation, but progress is slow.
Gonna have to go with Dave's thoughts - I believe AMX is just not that well experienced in real-world thoughtfulness. Have you seen or heard about the MVP-9000i? Or the high gloss MVP-5200i? How about the R4?
I agree. AMX modules are most often more useful as examples than as solutions.
The only useful example would be if they opened up the com module. Then we would at least have a starting point to re-write and make their modules useful and customize them to our styles, needs and save some time so we can sell more AMX. Otherwise having 100's, maybe 1000's of modules that most folk don't use for one reason or another, since are many reasons, makes no sense. The one thing they could be useful for they don't allow and that's accessing the com module's code.
I agree completely.
So, I called and inquired about the code. It took some hassle but they said they MIGHT get it to me, if I am willing to sign an NDA. Yes, an NDA for a module to control a medium line stereo receiver. Something for which a control protocol is readily available for.
I ended up rewriting the module - my interface code was far cleaner, the master was far more responsive, and it didn't lock up anymore.
When I later started writing Cres systems, and found that not only are their modules open but there is at least one large community group who shares code openly (*1), I really wondered - why is AMX still closed? What do they stand to gain from minimal testing and broken modules?
I've used a number of partner and other modules for Cres systems... or used information in said modules to understand an implementation, and write my own module... released a few myself as well... but I don't use AMX-sourced modules (*2). I write my own. It's too frustrating debugging problems when I can't see the code.
(*1 - in addition, ANY password-protected Cres module can be opened and looked at...aha)
(*2 - the only one I am using is the iPort Duet module, and only when necessary, because I haven't finished my module yet. I've fixed numerous bugs in the included panel interface module, reducing CPU usage dramatically, as well as adding UTF-8 support.)
Several years ago I tried to use a Duet module for a Lectrosonics conferencing mixer. Even though the mixer would send easy to interpret status messages back to the module, the module insisted on keeping track of levels internally -- ignored feedback from the mixer. Very frustrating, but the Lectrosonics is not hard to control, so went without the module.
Just the other day had the joy of controlling a 2X2 matrix of large NEC LCD screens. There is a module for these, but it didn't respond properly to send_commands. Really would have like a decent module for this one as the NEC protocol is the most obtuse I've ever seen, but even if the module worked properly, it isn't easily configurable to the multiple screen matrix thing and controls for the matrix, best I can tell, aren't included in the module.
Been looking at the module for the new Polycom SoundStructure audio mixer/telephone interface. I liked the way the Vortex protocol worked, but that's gone so I have to do something. Looks like the Duet module for this thing is way, way too complicated when all you want to do is control a teleconference dialer and adjust some audio gains/levels. I think it would take twice as long to try to get the module to work properly as it will be to just modify the Vortex code that I already have.
Are y'all refering to the comm modules or the UI modules? I can count on one hand the times I have had issues with comm modules. The UI modules are just for an example though, and in no way are written to use without serious modification or rewrite. I would have to say that my experience with AMX modules has been the exact opposite of most here. Odd.
Paul
The three instances I was whining about:
1. Lectrosonics returns simple to parse strings indication mute and gain status. Comm module ignores these returned strings and resets all gains to mid point at every start up. It's not hard to write code to supplement the comm module and set the levels and channels that it uses to keep track of gains and mutes, but that obviates the usefulness of the module. This is a comm module issue, not UI.
2. NEC multisync comm module does not respond properly to send_commands as specified in the user documentation. Specifically the ?PROPERY and PROPERTY send_command dialog does not function. As a result, couldn't set the necessary device ID for the target monitor (all monitors function from one RS232 port. The comm module does not appear to allow grouping of the monitors into a single display or the ungrouping of the monitors so that they display independently. This is the most important reason why these monitors are used and the absence of these controls from the comm module makes the comm module useless.
3. I haven't actually tried to implement the module for the Polycom SoundStructure mixer/telephone hybrid, but I've looked at both the module documentation and the Polycom documentation and I see no point in writing code for a more complicated protocol than the protocol of the device itself. Particularly when I'd like to stay Duet free as life is way to short already. I do notice that there is basic functionality in the Polycom protocol (assignment of physical channels to the necessary virtual channels) that is not available in the AMX comm module.
From what I've heard the internally rolled modules use the AMXTools framework. If you ask the right people its not to hard to obtain a copy which will at least provide some insight to the internal structure.
If com modules were open everyone would benefit. The AMX community would contribute more in providing better code that every one could use. In the end AMX would benefit by having better code available, better examples for newbies to emulate and build their own modules from. A win, win for all.
Both were Duet modules. Both were with the comm module since I never use the UI modules for anything.
First is the on for the NEC LCD6250 display. It works fine when you are only loading a module for one display. Load a second instance and it not only kills itself, but steps all over the other duet modules you have loaded. I just went without using a module in this case.
The second was for the Sony SRXT110 projector. This one would only semi-work. My problem here was with the lamp hour feedback. The projector sends back a simple message with the hours for both lamps. The module doesn't know what to do with this. I ended up writing my own module for this projector.
I've had real good luck with the Lutron Homeworks module. Also, the Apex Destiny 6100 (RIP) worked quite well too.
Modules on my bottom 10 list: AMX MAX. all 10 spots... (RIP)
Say someone calls AMX TS and says "hey I am having problems with my system, I have an Autopatch switcher, I'm using your module, and it doesn't work."
TS can pull up the documentation, source of the module, and walk the user through some tests to make sure the device is talking and the feedback from the module is being interpreted correctly by the user's main program, etc. So it seems there might be SOME benefit from standardization.
Now suppose in an alternate universe, someone calls AMX TS and says "hey I am having problems with my system, I have an Autopatch switcher, the system doesn't work as expected; I downloaded the module from your website a month ago before version 1.3 was published, changed lines 234-238 because I think mute feedback should be returned as a level, 260-273 because I wanted the module to return the zones first and not the source for SWITCH= feedback, and line 74-82 for some other reason."
Remember, there was a day when it was not assumed AMX programming would be done by programmers.
edit:
Yeah, I know. Whine, whine, whine.
Jeff