New Master Firmware Out Today

TurnipTruck

Any of you guinea pigs try it yet?

vining

setting Duet memory greater than 99 for the new NI-X100/256

Is that new [ NI-X100/256 ] and only couple hundred more $$ to step up from 64m.

I'll probably upgrade the office 1st to see what grief if any it creates.

John Nagy

I suspect we'll see another release very shortly. This one reports ZERO Duet memory in any configuration with or without code running.


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

John Nagy

By the way, we had good experience with the hot patch limited release firmware just before this one...
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>

John Nagy

Well now. After about 30 minutes running, I checked again, as I wanted to see if it was leaking memory. Now it shows DUET memory about normal. Huh.

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>

DHawthorne

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.

ericmedley

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.

John Nagy

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!

jjames

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.

shr00m-dew

At least they finally released a version for the X000's...

Kevin D.

ericmedley

jjames wrote: »

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.

John Nagy

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.

[Deleted User]

MVP-9000i support

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.

DHawthorne

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.

ericmedley

DHawthorne wrote: »

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

jjames

I believe this is what happened.
http://www.amxforums.com/showthread.php?1250-New-NI-firmware-breaks-XCHM

vining

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.

DHawthorne

jjames wrote: »

I believe this is what happened.
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 ...

jjames

Hmm, I don't remember that. But that's just another example of how firmware can break code.