firmware and stuff
rfayer1
Posts: 22
I started with AMX almost 2 years ago by having adopted,when our engineer left, the resonsibility of finishing off some installations and updating or just plain fixing others. I work for a university and there are so far about 5 small to moderately sized installations here. I didn't even have much programming experience when I started. Since then I've been focused on basics both with the learning curve and with the installations themselves. Now that they're a little more functional and I've had time to try and step back to see the bigger picture I've realized that these (mostly ME260) netlinx masters are running firmware versions that don't appear to be listed in the PI-like v2.10.85 (I'm guessing its pre DUET). Also, I am wanting to make these really fullfill their potential ( and mine) and not just work. I think about connecting the masters (right now all are independant but in the same building), making better UI's, other applications across campus, etc.
So I'm wondering in particular if there is any reason not to update these firmware versions, and in general about where to go for general guidelines/best practices type stuff for people still new to this. I've had great help from the forum but Ii'm curious about where to go first and when. There are so many different issues and scopes that sometimes I just want a new or more general perspective rather than a specific question to post. I'm familiar with the PI, I have manuals, the documentation from P1 and P2, I just discovered the UI design site... What other resources do people depend on as they move on with this?
So I'm wondering in particular if there is any reason not to update these firmware versions, and in general about where to go for general guidelines/best practices type stuff for people still new to this. I've had great help from the forum but Ii'm curious about where to go first and when. There are so many different issues and scopes that sometimes I just want a new or more general perspective rather than a specific question to post. I'm familiar with the PI, I have manuals, the documentation from P1 and P2, I just discovered the UI design site... What other resources do people depend on as they move on with this?
0
Comments
you are indeed on an older firmware version for THAT master. the current version is 2.31.139. On the other hand, an ME-260 is not capable of going up to the duet firmware. This, in and of itself, is not a bad thing. In fact, for the most part, you'll be able to do just about anything you want within the limits of the RAM on the thing.. For example, I run my current home on one just fine.
If you were planning on using any AMX written module, you might find that some devices are duet only and then you'd be forced into writing your own code.
You're not at any huge disadvantage by sticking with them, however. They're not the quickest ships at sea but they still have plenty of horsepower to get the job done.
If it really does bother you, you can upgrade them to ME-260/64s. then you'd be up to speed.
Firmware updates are funny and sometimes break systems that have worked fine for years. If you want to increase efficiency I would methodically go through the existing code and tweek it to make it work better, handle feedback better and add new features to make the users experience better.
I started off in a very similar situation to you, except that I had a (non-AMX) programming education, and a moderate AV background. I love working at the one "company" since it allows me to continually improve the work I do. Being onsite when things go wrong has (I think) given me a good insight as to how academics appreciate/loathe my handiwork. It also allows me to see the issue first-hand, which makes debugging much easier.
When I started programming here we had a variety of AMX systems that had been installed by various contracting companies. This resulted in a different touch panel layout for each venue, depending on which company initially built the room. One of my first goals was to standardise the touch panel layout (and perceived behaviour of the systems) as much as possible to create a consistent experience for academics, regardless of which room/campus they were in. My rationale was that this would give them more confidence with using the system even if they were in a room that they have never been in before. It has taken much longer to standardise the "behind the scenes" equipment, and after 6 years we still have a few legacy issues here and there. On the whole we are able to hide such issues from the academics though.
When it comes to firmware, I try to keep everything at the most recent version. (As you can see, there are differing opinions as to updating firmware or leaving it alone.) I have a feeling that not every bug-fix is documented in the older change logs, particularly if it effected a small number of people. I think AMX are now being more verbose with the bug-fixes, which is good. Occasionally there is a questionable firmware release, so I tend to hold off for a month or so until things have settled down before rolling out the new firmware. We have so many rooms that I try to reduce the variance from room to room, which includes keeping all firmware version the same. This make it easy to rule out firmware issues when 30 other identical rooms are working fine but one room is causing problems.
The only time I've had firmware update break a master is when there is "external traffic" (generated by a non-AMX device) on a serial port while updating the device firmware for that serial port. In my case it was an RS485 lighting system with a heartbeat packet every 0.7 seconds. Since the port generates traffic on the I2C bus inside the master, the firmware transfer to the various device chips fail. Unplugging the external device first solves this issue. (Once bricked, the master will need to be returned to AMX for repair). Note that if the traffic was to be generated by the AMX then it is not an issue, since the firmware update process kills your on-board program before applying the update. I've had the occasional CV7 firmware update not work either, but that was an issue with the firmware release itself.
If you can, try to obtain a development master so you can practice to your hearts content, as well as test new firmware before rolling it out to your wider community. It is very frustrating when your only opportunity is in a venue with 2 hours here, 1 hour there, and at the end of your development the venue has to work! If your institution won't/can't buy a dev system for you have a look on eBay.
As for enhancing your existing systems, some useful things you could start with are:
1) Logging of how the academics use the systems. Proj on/off, basic source selection. This is useful to combat claims of "it didn't work", when the logs show that they pushed the wrong buttons. Useful more so for your own sanity than picking fights!
2) Time-sync the masters so all your log times match up to a since time server. See i!-TimeManager. It's pretty straight forward.
3) If your systems control room lights you could implement some "green" policies using a PIR motion sensor. We have a moderately complex policy, but essentially it:
If the system is left running for 90 minutes with no movement, turn off the system. This is sufficient to watch a typical DVD in a media class.
If the system is off and someone walks into the room, the lights turn on to prevent people tripping in the dark.
If the system is off and there is no movement for 5 minutes, the lights turn off again.
While the system is running, the academic has control over lighting levels via the touch panel.
I hope this gives you some ideas/inspiration as to what you could do.
Roger McLean
Swinburne University
Sorry to threadjack; can someone from AMX engineering confirm this? If this is correct, unplugging serial devices from the master should definitely be listed in the upgrade instructions for each firmware release. I'm surprised I haven't heard of this before!
Is the same true for push events on I/O ports, etc.?
I had 10 or so masters that are coming to the end of their 3 year warranty. Having bricked one device after only 6 months (performing a firmware update), I wanted to get the rest of our device firmware updated to current version before the warranty expired. AMX had only a few instances (globally) of devices being bricked by a firmware update and, after exploring numerous option, suspected external traffic was the cause. Given that I could absorb the loss of a few masters for a few months, we set about some verbose tests to see what was causing the failure.
I methodically updated our masters, starting off with nothing plugged in (no RS, IR, IO, etc), increasing it to all "non-chatty" serial devices, then eventually all serial devices. I also tried just the chatty serial device by itself. Every time the chatty device was plugged in, the device firmware would get bricked. I passed the info onto AMX along with 2 masters with bricked devices. They graciously repaired my 2 bricked devices under RMA. Hopefully my tests have helped them in locating the issue.
I suspect that AMX are probably working on a fix to the way firmware is deployed to the device, perhaps by monitoring the I2C traffic first to wait until it is quiet (speculation). If not, I guess a technote will eventually appear.
I'd also like to hear from AMX Engineering on this one.
Roger McLean
Swinburne University
AMX has a policy about not speaking of problems until they have a solution. You can sometimes get an off-the-record response from an individual, but there is never any official word until it's a fait accompli. The best you can ever expect is, "we are aware of the problem and are working on it," but I have many times reported an issue and never heard another thing about it until a subsequent firmware update fixed it.
I'd be happy to unplug devices from masters when updating firmware as a temporary solution if I knew having external devices plugged in may brick them! I'm sure others would too...
In the mean time, I'm also inclined to disconnect chatty RS232/485 devices when updating device firmware. Just being verbose, but in my observations it was only devices that generated traffic by themselves (regardless of the AMX program, PRD, etc) that caused issues. I've got not trouble at all leaving "non-chatty" devices still plugged in while doing firmware updates.
Roger McLean
Swinburne University
Just to confirm for all (even though I'm not from AMX Engineering), I've now tried the most recent firmware (master v3.50.430 and device v1.20.7) which appears to address the issue. One thing to be aware of is that if you are updating the NI-device firmware from a version OLDER than v1.20.7 then you should unplug any chatty serial devices, as they congest the I2C bus during the firmware upgrade.
I have tested the above versions by doing the following:
1) Unplug chatty serial device.
2) Update master firmware. Once firmware update is complete, reboot master.
3) Update device firmware. Once firmware update is complete and device has rebooted, reboot MASTER.
4) Plug chatty serial device back in.
5) **This is my test** Update device firmware (from v1.20.7 to v1.20.7) while the chatty device was plugged in. NI-device did not die during the update, though I had to reboot the master afterwards to get my program to start polling the non-chatty devices.
While updating the device from one version to the same version may not be as thorough test as is possible, it does show that once the new master + device firmware is deployed, subsequent updates with chatty devices will not brick the NI-device.
For those that may be searching the forums at a latter date, the lighting system is: QEngineering Dimmax series, baud settings are 4800,N,8,1 485 ENABLE. We are updating them to Dynalite soon - yay!
Roger McLean
Swinburne University