I don't load brand-new firmwares anymore, unless they specifically address a problem I am experiencing. I wait until they have been out a couple months, and even then only if I think it might improve something on the target system, or clear up some mysterious issue I'm having. I used to be quite cutting-edge about firmwares, but now I'm more in the "if it ain't broke, don't fix it" camp. There have been too many releases that broke something my code depended on. Sometimes, those changes were even necessary, but I wasn't in a place that I could afford the time to re-write, yet the firmware change forced it.
I have enough systems out there that keeping the firmware up-to-date is a bit daunting. So, I too don't try to be bleeding-edge on firmware. I will say that as of late, it seems to be more of a big deal since NS and TP4 are more and more non-agnostic about the firmware. If I need to make a program tweak or whatnot, a lot of times NS will break a working system because the firmware on the master is old enough that the program doesn't work.
I've seen some strange stuff in the latest firmware versions in the past year or so.
What are a few examples of changes to running code that you had to make due to a NetLinx Firmware change? While we've found issues in some releases that caused issues so we avoided them (and they were resolved with replacement releases), never yet have we had to revise any actual programming due to new firmware.
Actually, that goes across the board - no firmware change for any AMX device has ever, to my recollection, required CHANGING our code. And we do have a lot of code.
We've had to adjust for changing available memory footprints, but that's not really the same thing. By the way, at least in our application, the NetLinx firmware of the last 6 months has ADDED about 3 MEG to our available memory, a real surprise!
I think what Eric is referring to is when the compiler changes, or when SNAPI changes there could be an issue where it needs a specific firmware. I recall this happening once before when I updated Studio and I lost my Duet devices after the download, requiring a firmware update.
But this would be less of a firmware problem and more of an NS problem - but point your finger at whomever to satisfy your argument. It's a problem regardless.
I think what Eric is referring to is when the compiler changes, or when SNAPI changes there could be an issue where it needs a specific firmware. I recall this happening once before when I updated Studio and I lost my Duet devices after the download, requiring a firmware update.
But this would be less of a firmware problem and more of an NS problem - but point your finger at whomever to satisfy your argument. It's a problem regardless.
Yes, that's what I'm referring to: Duet modules can get blown up. For example, I have an install with a pool controller that no longer works and the company isn't planning on redoing their module. I could write my own, but that's the point of getting a module....
And, is this not breaking code? In my world, code that worked yesterday and doesn't today is braking code.
Yes, I'd say that was breaking code, and thanks for the examples. We make little use of the Duet environment so our exposure there has been minimal so far.
It appears that this fiirmware release is recommended if you are installing or upgrading a system featuring an MVP-9000i touch panel. The release notes also recommends updating the device firmware at the same time.
There was a time a few years back when a device firmware update broke the IR queuing functions on IR ports ... the SP (and XCH as I recall) command could lock up the port if you weren't careful, and let me tell you, it was an utter nightmare for me, since I used it in every single project.
There was a time a few years back when a device firmware update broke the IR queuing functions on IR ports ... the SP (and XCH as I recall) command could lock up the port if you weren't careful, and let me tell you, it was an utter nightmare for me, since I used it in every single project.
Interesting. I never knew that since I never use those functions myself. You learn something every day!
e
Wasn't there another firmware that broke channels above 255 for TP pushes? This wasn't a set_virtual_port_count issue although that would fix the problem if called/set for non virtual device ports.
I was thinking of something else ... as I recall, consecutive calls with SP would lock the IR port entirely, as would XCH calls, intermittently. When the bug bit you, you completely lost the IR port. My solution was to replace individual SP's with CP (which clear the queue first), and to roll my own XCH that started each sequence with a CP. The worst thing about it was it was intermittent. You might think you were OK, then a day later that irate phone call came in ...
TurnipTruck
Posts: 1,485
Comments
I'll probably upgrade the office 1st to see what grief if any it creates.
Welcome to NetLinx v3.60.453 Copyright AMX LLC 2010
>show mem
Display Memory
Volatile Free : 10400424/67108864 (largest free block in bytes/max physical)
NonVolatile Free: 1047536/1047536 (bytes free/max physical)
Disk Free :107757568/128299008 (bytes of free space/max physical)
Duet Memory Free : 0 (bytes)
Partition 1 - <UNKNOWN>
Partition 2 - <UNKNOWN>
>set duet mem
Duet Memory: 36M
Enter new Duet Memory size (between 3M and 36M): 3
Duet Memory set to 3M
It did report DUET correctly too.
Welcome to NetLinx v3.60.447 Copyright AMX LLC 2010
>show mem
Display Memory
Volatile Free : 8736224/67108864 (largest free block in bytes/max physical)
NonVolatile Free: 564488/1047536 (bytes free/max physical)
Disk Free :107741184/128299008 (bytes of free space/max physical)
Duet Memory Free : 1016828 (bytes)
Partition 1 - 1016828 (bytes)
Total Collections - 13
Average Time Between Collections - 7799911ms
Partition 2 - <UNKNOWN>
Welcome to NetLinx v3.60.453 Copyright AMX LLC 2010
>show mem
Display Memory
Volatile Free : 8914048/67108864 (largest free block in bytes/max physical)
NonVolatile Free: 564416/1047536 (bytes free/max physical)
Disk Free :107757568/128299008 (bytes of free space/max physical)
Duet Memory Free : 935448 (bytes)
Partition 1 - 935448 (bytes)
Total Collections - 6
Average Time Between Collections - 61923ms
Partition 2 - <UNKNOWN>
I've seen some strange stuff in the latest firmware versions in the past year or so.
Actually, that goes across the board - no firmware change for any AMX device has ever, to my recollection, required CHANGING our code. And we do have a lot of code.
We've had to adjust for changing available memory footprints, but that's not really the same thing. By the way, at least in our application, the NetLinx firmware of the last 6 months has ADDED about 3 MEG to our available memory, a real surprise!
But this would be less of a firmware problem and more of an NS problem - but point your finger at whomever to satisfy your argument.
Kevin D.
Yes, that's what I'm referring to: Duet modules can get blown up. For example, I have an install with a pool controller that no longer works and the company isn't planning on redoing their module. I could write my own, but that's the point of getting a module....
And, is this not breaking code? In my world, code that worked yesterday and doesn't today is braking code.
It appears that this fiirmware release is recommended if you are installing or upgrading a system featuring an MVP-9000i touch panel. The release notes also recommends updating the device firmware at the same time.
e
http://www.amxforums.com/showthread.php?1250-New-NI-firmware-breaks-XCHM
I was thinking of something else ... as I recall, consecutive calls with SP would lock the IR port entirely, as would XCH calls, intermittently. When the bug bit you, you completely lost the IR port. My solution was to replace individual SP's with CP (which clear the queue first), and to roll my own XCH that started each sequence with a CP. The worst thing about it was it was intermittent. You might think you were OK, then a day later that irate phone call came in ...