Next generation master controllers feature requests
champ
Posts: 261
in AMX Hardware
If you were to have a say in the features of the next generation of master controllers what would you want and why?
I personally want to be able to change code without rebooting the processor, when AMX first came out with modules they marketted them as if you could load a new module at run time without having to reload the while program.
I have noticed that things get prioritised if you can show evidence that they will make the company lots of $$$ so pretend you are pitching to the boss.
BTW, you are not pitching at me, i am just hoping the people who have the power read the forums
I personally want to be able to change code without rebooting the processor, when AMX first came out with modules they marketted them as if you could load a new module at run time without having to reload the while program.
I have noticed that things get prioritised if you can show evidence that they will make the company lots of $$$ so pretend you are pitching to the boss.
BTW, you are not pitching at me, i am just hoping the people who have the power read the forums
0
Comments
So I'm into some geeky things to keep me sane, and one of those things is the electric imp. It's essentially an Arduino inside an SD card, with built-in WiFI (b/g/n) and connects to a cloud service to run & get the code. Well, one of the problems they faced was getting the imp to connect to the WiFi network. How do you connect something to a network when it has no interface? They made a way that'd send all that info over optics. Essentially, it's Morse code on steroids.
Here's what I'd love - build in an optical sensor into the master and do the same thing. Imagine the programmer using software or a website to populate all the information for every device he has in a system (IP address, device number, etc., etc.) and then saves it to the cloud where his installers can use this information on their smart phone. They then walk up to each device, select which device it is on the phone, and click "Send Blink". They then hold the phone to the device's optic sensor and let the phone do its magic, sending all of this information to the AMX device in a matter of 10-30 seconds.
In my opinion, having a feature like that would significantly speed up deployment and have a competitive advantage. Imagine *any* of your employees, not just your installers, having the ability to set up AMX devices with a simple smart phone and clicking one button.
And AMX, if you're listening - electric imp is licensing it's blink-up technology.
I've played round with a similar concept in the past for the NI's. Basically building a small dongle with a single button and a 232 port. Plug it into the program port and press it once and it will set all networking to DHCP, setup security standards required for an install and basically configure the master to a set standard. After this it would load a tko that on start simply connects to an FTP server and downloads the appropriate 'real' system then reboots. Essentially a hardware key that could be given to an installer to 'program' a system in an enterprise environment. Hold the button for 5 seconds and it performs a factory reset / secure wipe.
The optical sensor concept is a funky idea though as like you mentioned, rather than it being IR based like all those old school phones using visual spectrum allows any device to program it and you also remove security concerns surrounding an NFC based solution.
1) Command-line History for the current Telnet session. I.e. You can use the up/down arrows to scroll through your session history, then press <enter> to re-issue that command again. I'll often debug code via Telnet where I frequently use the command line send_command to flex my modules. It is a pain when your debugging requires more than one send_command, since you have to type each command out every time. I don't think there would be any need to store the command history beyond the current telnet session, and it could even be limited to say the last 100 commands. (I'd even settle for the last 20 commands!)
2) The option of halting/restarting the active program immediately, from the telnet session. I'm thinking something akin to the PDR switch, but as a special telnet command which is effective immediately (rather than on reboot). While I would only expect to use this in a dev/debug context myself, it would allow us to kill a program immediately. Could be useful for debugging run-away situations, endless loops, etc. Default at boot-time would be as per the physical PDR switch. It would be nice for the command to also override the PDR switch so we could start a program in a remote room where the PDR switch is active (program disabled). I don't know if this would be a security issue, but given that to do this you would already have telnet access to they system.....
3) Finer-grain control over locking of front panel button. (I've only tried the DVX-2100 with v3 firmware, so I don't know how other masters or fw versions compare yet.) I'd like to have ONLY the 4 Macro buttons enabled, with everything else disabled. Yes, disable input selection. Yes, disable volume control, muting, config mode, etc. Someone else probably wants the Macro buttons disabled, Input selection enabled, config disabled, etc. The Full/MenuOnly aught to be more flexible, with individual enable/disable per button type as per the button grouping in the manual: Macro, Input Select, Mic Select, Video/Audio Menu, Navigation (inc volume +/-), Video/Audio Mute.
4) Perl-flavoured RegEx matching function find_regex(haystack,pattern,start) for parsing the many "interpretations of XML" that we now have to deal with. I'm sure VxWorks has a few RegEx commands tucked away at the OS level that could be leveraged. Failing that, I'll once-again mention http://www.boost.org/doc/libs/1_44_0/libs/regex/doc/html/index.html While RegEx can be scary even for seasoned programmers, it is fantastically powerful and would be really useful in our domain - integrating with many other protocols. There are plenty of online sites dedicated to creating RegEx patterns.
Obviously AMX have to juggle priorities with development resources, etc just like the rest of us.
Roger McLean
Swinburne University
I completely agree with #4, and I have asked for it in the past.
#1 can pretty much be handled by using a different telnet client. I am a fan of Indigo by http://www.shadeblue.com/ It has a command widget that you can create a list of custom commands that are sent through telnet by double clicking them. You can also set it up to automatically send "msg on" and to automatically reconnect to the AMX master upon the master rebooting.
Yes, I admit there are various clients that sort-of achieve the same outcome, and than you for those suggestions. Here is why I think the history "caching" should be done by the AMX Telnet server rather than the client:
- While diagnosing on-site in our classrooms I may not have the luxury of BYO telnet client. I typically use the OSX Teminal/telnet, but some times I am stuck with the WinXP telnet client. As for temporarily installing a special telnet client on enterprise-deployed computers to do 12 seconds of fault-finding... well.... that is next to impossible in my context.
- I'm not a huge fan of the NLS telnet client caching my admin password in clear text in it's right-click popup menu. If anyone is looking over my shoulder while I reveal the popup menu it is a bit of a security risk.
- Pre-written/common commands may be useful as per the Indigo example, but debugging doesn't always work using the same commands in every situation. If I have to "set up" a command when a rare case occurs it is not a very efficient way of working.
- Both the above suggested solutions require me to use a mouse. I like to give the impression of smoke coming off my keys from my words-per-minute prowess! Think WeirdAl White-n-Nerdy, Minesweeper scene.
- All other modern OSes that have a CLI seem to have a cached history, accessible via the up/down arrows.
Now where did I put my CO2 fire extinguisher? I need to cool down this keyboard.
Roger McLean
Swinburne University
And if it's a "rare case" command that you would not have set up for, it also isn't likely to be in the recent cache.
Just sayin that your corner cases as to why the existing tools wouldn't work would also challenge any server-side tool/cache.
Perhaps my 12 seconds was a little on the slim side. However, the point remains that when you work in a University (or any enterprise environment) with hundreds and hundreds of AMX masters to look after, you don't always have your preferred telnet client available at every location every time. You have to use what is closest to you when the issue occurs.
Here is a scenario that people may be able to relate to a bit better. Imagine servicing a room with a mesh of AV switchers, routing signals all over the place. Maybe some "valued customers" have re-patched some of the cables due to boredom/mischief. You are trying to figure out what goes where so you can rectify the patching without ripping it all apart and starting again, so a telnet session is a reasonable place to try to diagnose the situation. Yes, in this scenario you could put the first common part (send_command dvSwitcher) into the clipboard and paste it each time, which is what I do. But there is still a fair bit of retyping required. How much nicer would that be if the CLI has history, especially if we could left-arrow to modify the line before executing it with the <enter> button.
Without boring everyone with the details of the multi-server modules that write, I frequently need to get my modules to perform a series of multiple actions. The particulars of these actions vary from time to time, so I may want to modify the actions a bit before performing them again. This would be a breeze if the CLI supported history. Imagine the following with multiple devices: And in every room that I go to the X & Y values change. Yeah, fun.... With CLI history you would only need to focus on getting the initial sequence of commands right, and then press the up arrow X times to repeat the cycle.
I suspect it may be one of those features which, if it ever gets implemented, we won't know how we lived without it - like transferring programs/firmware over IP rather than RS232. In the OP Champ was asking for ideas/suggestions - I gave some of mine. Any other suggestions?
Roger McLean
Swinburne University
send c [dev],'yadayada
send s [dev],'moreyada
No need to underscore and spell all of COMMAND (or STRING) and no need to close the single quote either.
You could also use shorter device names for the heavily used items, like "ds2" instead of "dvSwitcher2" (or make both available).
If the scenarios you describe are frequent, consider adding coded diagnostic modes of your own that you can call from telnet that walk through the permutations and report as they go.
Again, offered as ideas to make your life easier with or without your request being granted by AMX.
FWIW, we've enabled voice control to simplify use of our diagnostics. Just say what you want to see or do, and then watch in telnet. In some cases, just listen and the status or feedback is recited audibly with text-to-speech.
I'd like to point out this thread is about "feature requests" not "why I think you're lazy". I find these sort of discussions have a bad tendency to veer into arguments about why Idea A is silly cause you could just as easily follow Steps 1, 2, and 3.
As engineers, it's our job to know how things work and, more importantly, how they can work together so we can accomplish something new. Unfortunately, having this knowledge leads us to find many ideas "simple", especially when it's a fellow engineer, because an alternate solution is so obvious to us. However, it is these simple ideas that make life easy and keep us employed. If we treated our customers as condescendingly, we'd be out of work: "What's the point of making one button to do all that? See, all you have to do is pick up the remote for the TV and turn to Input 2, then get the remote for your cable box..."
I think it's great to point out what tools are already available to achieve a goal but when the question is "what do you wish it could do", there's never a wrong answer.
There's no certainty, maybe not even a likelihood, of most feature requests made here of getting implemented.
Even if they are, it will be in the future.
The WANT therefore remains a current want.
If anyone has immediate ways around the issues brought up here as WANTS, sharing those ways is about as constructive as anything can be.
And in truth, a few WANTS arise from a misunderstanding or lack of awareness of the already available tools.
And my pie-in-the-sky wish is for a master small enough to go in a CubeSat. (Less than 100mm x 100mm square.) It could be a good PR exercise for AMX to have University students (and others) send up CubeSats with AMX gear as the main CPU. I don't think the market is big enough to justify a CubeSat-specific design and AMX probably don't want to extend warranties to space travel just yet, what with the extra radiation issues. If a DIN-rail master was designed cleverly such that it could be butchered/re-purposed for CubeSat use, AMX could get off the warranty "hook" since the butchering process would void the warranty. Besides, could you imagine trying to organise delivery for a CubeSat requiring an RMA?
Roger McLean
Swinburne University