Home› AMX User Forum› AMXForums Archive Threads› AMX Hardware

Do different NI4K makes require different firmware?

youstrayoustra Posts: 135
in AMX Hardware
I've got an NI4K that got fried due to an IR port short/shock. I got another NI4K here that we swapped in it's place.

The orig NI4K had non-duet firmware. The replacement had previously been serviced and had duet firmware. Looking at the internals, they are different. The original has a single board on the backplane and the Coldfire processor is visible. It came w/ a 32MB card.

The replacement has a daughter-card (maybe for ICSNet?), I can't see the Coldfire, and the CF card is 128MB w/ duet firmware

Anyhow, I fired up the replacement and all is fine. Then I uploaded the program that had worked previously for months and it freezes up after a while. I can chase down the code issue, but it wasn't a code issue before...

So I swapped the CF cards (putting the original 32MB card into the replacement NI4K) and the thing doesn't boot period, even with the program disable DIP switch on.

Shouldn't the old CF card work? Or do later NI4K builds require the updated firmware that includes duet?

I'm assuming the CF card wasn't fried - I looked at it in Windows and it seemed ok.

I appreciate any assistance. I'm logging late hours at a client site and my wife is displeased.

Comments

  • Joe HebertJoe Hebert Posts: 2,159
    Might the replacement be an NI-4100 and not an NI-4000? The NI-4000 has been discontinued.
  • youstrayoustra Posts: 135
    Issues w/ porting code from NI4000->NI4100?

    That occurred to me right after I posted this. It was an NI4K that was sent in for servicing and came back as an NI4100. Sorry about that.

    But I'm surprised that a program that ran fine on an NI4K for years runs into problems on an NI4100. Did others experience migration problems? Are there any general guidelines?
  • yuriyuri Posts: 861
    nope, it should run faster :p
  • DHawthorneDHawthorne Posts: 4,584
    I had a similar issue where an NI-900 that merely had it's firmware updated refused to load code that was running just fine on the old firmware. I narrowed it down to a module that was doing a lot of processing on startup ... apparently the new firmware had more going on, and the extra processor load was enough to crash it.
  • ericmedleyericmedley Posts: 4,177
    DHawthorne wrote: »
    I had a similar issue where an NI-900 that merely had it's firmware updated refused to load code that was running just fine on the old firmware. I narrowed it down to a module that was doing a lot of processing on startup ... apparently the new firmware had more going on, and the extra processor load was enough to crash it.

    I've always wondered if Netlinx would allow for dynamic start runtime processing do you could build in some brakes on the startup process if it's going poorly.
  • DHawthorneDHawthorne Posts: 4,584
    ericmedley wrote: »
    I've always wondered if Netlinx would allow for dynamic start runtime processing do you could build in some brakes on the startup process if it's going poorly.

    All we really need is an idle() function to hand off processing and allow other threads to run in the middle of an intensive cycle. It's always re-entrant functions and while loops that wind up biting me.
Sign In or Register to comment.