Home› AMX User Forum› NetLinx Studio

Program problem

ericmedleyericmedley Posts: 4,177
in NetLinx Studio
This one is driving me (and AMX Tech Support) Crazy!!!!

I have a program that worked fine prior to this problem.

Here's a Cliff's Notes version of the history...

NI-2000 at site loses ICSNet port (one works -the other doesn't)

Send NI in for repair. comes back with new ICSNet card.

Upload program as they had to zap the RAM.

No feedback to panels is working and things are sluggish.

After much troubleshooting discover than any part of the program that uses a NON_VOLATILE or PERSISTENT variable doesn't work anymore. Cannot see variables in Debug, in fact Debug will hang and crash if you leave it on too long. Also tons of run-time errors saying things like INDEX TOO LARGE or ZERO INDEX on some thing hard coded. ex. SECURITY_ZONE_STAT[1]=something. (How can this index be too large???)

If I change these variables to VOLATILE, they work just fine and no run-time errors. (works - but not good for storing volume peresets and whatnot.)

AMX TS says, possible bad mother board messing up RAM. send master in. no fault found. sent back.

So I put the program in an NI-3000 we have here at the shop. Same badness.

Now I put it in a brand new NI-2100, same badness.

If I put another project with same hunks of code (with Persistent variables) They all work just fine.

I've trashed all the .tko and .tkn files in the project folder(s) in an effort to force NS to make new ones.

All this has failed so far.

any wisdom form on high???

eric

Comments

  • John GonzalesJohn Gonzales Posts: 609
    Did you check if the firmwares matched what you were running the program with originally? Possible that a firmware upgrade may have broken something in your code and it was no issue on the original piece. After they switched the ICS board, perhaps the firmware was upgraded, and maybe the 3100 and 2100 in your shop are a different firmware from what you had originally too. I still remember when Ricardo's XCH commands got broken by a firmware update because of a syntax rule that got stricter.

    --John
  • AMXJeffAMXJeff Posts: 450
    Divide and Conquer

    If the firmware version are the same, I would assume it is a code problem and start commenting out all of your code, and slowly uncomment the code back in until you find the problem.
  • yuriyuri Posts: 861
    are you writing a lot of stuff to flash?
    Doing a lot of polling of some sort? Maybe problems with communicating with the master?
  • Spire_JeffSpire_Jeff Posts: 1,917
    Did the duet memory size or something along those lines change? Have you checked the available memory on the processor?

    One problem I have had when going back to older jobs is that sometimes the compiler uses a different version or copy of a module I wrote because it likes to "help" you and search for files on its own. I have gotten a LOT better at using version numbers in my file names and because of this, I know when a program expects an older version but is unable to find it, but early on this caused a few problems that were tough to put a finger on because I only made 1 or 2 minor changes.

    Another thing would be to disconnect all of the wires from the processor and try connecting them 1 at a time to make sure the problem is not coming from one of the connected devices. I had a problem once with an AXD-IR+ that was causing all kinds of weird problems and I think it was RF interference being picked up by the wire connecting the IR+ to the processor. The way it presented itself tho was COMPLETELY unrelated to the IR+ and it's operation.

    Hope one of these helps,
    Jeff
  • ericmedleyericmedley Posts: 4,177
    problem found.

    In the DEF_VAR section I found a little comment that I made uncommented.

    I would compile but wigged out the processor. re-commented and it works fine again.

    Thanks for all the suggestions!

    e
Sign In or Register to comment.