a_riot42 wrote: »
That's what they said about moving buttons too.
annuello wrote: »
I'd like a more scalable/flexable mechanism for firmware transfers. I'm mentioning it here since NLS is currently the only way of managing firmware. My following suggestions may be better implemented in something like RMS (which I guess counts as an AMX tool), or a new stand-alone firmware tool, so here goes anyway:
1) We retain a local/server-side firmware repository where our preferred versions of firmware sit for all our hardware. The repository should allow for multiple versions, so we can roll back in those few rare instances where we may need to do so, and for each product type we can select one version to be the "preferred version". (This allows us to test newer versions before rolling it out in bulk.)
2) We build a list of comm settings for all our masters. (Already done in RMS.)
3) A "firmware-meister/manager" (FM) program audits each system for firmware versions for all masters/devices. (Already done in RMS, to some extent.)
4) The FM program then highlights all whose version does not match our "preferred version" from our repository. Older versions are marked as red, newer versions are marked as yellow, matching versions are marked as green. (Perhaps some form of RMS-like exception highlighting would be good, where "okay" results are collapsed.)
5) For each master/device we can then specify what version we want (via a dropdown populated with the available versions in our repository), and a time/date when to push the firmware out to the master/device. The FM then pushes out the firmware at the specified time/date. It the solution was a standalone app, we would have to leave it running 24/7. RMS is already doing this anyway.
I don't ask for much, do I! We could upload the firmware into RMS via the web interface, where it manages it's own repo of versions. (You could even supply an easy "update repo" button where RMS automatically pulls down the latest versions from the AMX site!) Given that RMS has/had it's own internal scheduling engine, that could be reused to initiate the FW updates. My idea is mostly inspired by the Tandberg Management Suite where (from what I saw several years ago) it can also control firmware for all the various video conference endpoints. Another good one to look at is the AXIS Camera Management app. It can push firmware out either in parallel, or sequentially. It also gives you options of what to do if a failure occurs (skip to next, halt, etc.) It also allows you to build config templates and push them out to which ever cameras you like. This could be useful to manage, say, Duet Memory Allocations where you want to ensure that the memory in the older units are not fully allocated to Duet, which results in you non-duet program not launching.
Trying to keep more than 20 masters current with the same firmware version becomes unwieldy, particularly when you work the same hours that the systems are in use. (Many of our classrooms are used from 8am to 10pm.) It becomes even more fun when you have a mix of 32Mb & 64Mb NI-700s (which have different firmware for each type), NI-3000s, NI-2100s and NI-3100s, CV7s, 700vi, MVP8400, and the occasional Vol3. Thankfully the firmware update mechanism is smart enough to know what firmware package it should be using, so this could be leveraged to select the correct .kit. It sounds like the new R4 updates are very order-specific. A managed mechanism could check to ensure that the appropriate order it followed, where such firmware dependencies exits.
I know my suggestion may cause discussion along the lines of "If it ain't broke, don't fix it." My approach is that if ever I need to contact tech support, their first question is often "Are you running the latest firmware? If not, update it, since your issue may already be addressed." When running large quantities of masters and AMX devices it helps to maintain the same firmware version across the entire fleet. This reduces the possible variations from room to room, which makes fault-finding much easier.
PhreaK wrote: »
Just got back from the Brisbane tech talk. Almost excatly what you desribed there has been implimented and is awaiting release. Oh yeah, and it will integrate with RMS.
rgelling wrote: »
Some very great ideas so far. I like them. Some I've thought of before, most I haven't. I was expecting sarcasm so very glad to see you guys are taking these suggestions seriously.
PhreaK wrote: »
Update: One of the tech's from AMX just got back to me. Looks as though it's not going to be released, it's only intended for AMX internal use.
Rick, can another request be added to get a similar tool brought out for the greater unwashed?
edgelitoc wrote: »
For TP4 I would like to see something that animates the button which you dont need to have a special animation done on third party software.
Joe Hebert wrote: »
There is a built-in tweener used for animation. You may want to check it out if you haven't already.
icraigie wrote: »
...how about opening up G4 Panel Builder beyond the strict conventions currently imposed on the users (ie, the programming model locked in there sucks).
jjames wrote: »
Could you explain? From what I understand, you can still create your own templates in TPD4 - and use them in G4PB. Painful? In a way. Very useful in the long-run? You betcha!
jjames wrote: »
IREdit - good for what it's for. I would however, love a way to do a batch import of HEX codes. Perhaps import a CSV file and it'll do what it needs to do. Also, we can import HEX codes, but we can't export them - is there a particular reason why? (It'd be SUPER slick if we could import other manufacturer's codes into an AMX IRN / IRL file, i.e. the RTI library - though this probably creates a sticky situation - so until then, I'll keep working on an RTI library importer program. )
Jimweir192 wrote: »
The AMX IR database lags way behind various internet lists / resources. I would rather AMX spent R&D time on being able to harness those resources rather than trying to maintain an upto date IR database. There are utilities to covert between various other IR files so why not between RTI and AMX...
Jimweir192 wrote: »
In IREdit I would like the ability to open a new IR file and pre load this with the command titles to match the various device functions standardised by AMX, and then be prompted command by command to paste the HEX values, hit enter, next command hex value, enter etc
jjames wrote: »
Not to drift off too far from topic, but I think the answers would be this (as I understand it.) One, AMX & RTI are competitors (sort of - though I don't consider them to be), I doubt they'll open up communication on the sharing of IR files.