Master doesn't appear to take new source code

alexsquared

I have a problem with an NI-3100 running the latest firmware. when I perform code changes, it appears to take the code just fine, but then when it is tested, none of the changes seem to be present. in this latest case, I added an IR command that was supposed to be sent anytime a the source is being changed. In watching device notifications, I see all the commands come through except for the new ones I added. Last time this occurred, I needed to essentially "clear" the master memory and then upload again. I'm hoping to not have to replicate this process anytime a change is made.

regallion

I've experienced something similar (except with NI-3101-SIG).

I'll make changes, compile, upload and notice that the changes didn't seem to take. If I do a Debug->Verify TKN on Netlinx Master it tells me that they do NOT match.

So I have to do the process again (which annoys the hell out of me 'cos I hate waiting for these things to reboot everytime).

This happens a LOT.

By the way, I'm not on the latest version of Netlinx Studio - I'm still running 3.2.0.418 after rolling back due to other issues with latest version.

PhreaK

Make sure the master is definitely rebooting after the code dump. I've heard reports that in the current (i think) version of NL Studio once you untick the reboot box in the file transfer dialogue it is somewhat reluctant to remember getting re-ticked.

ericmedley

Yeah, if you've unchecked the 'reboot' box once you'll be doomed to manual reboots for a while.

regallion

Nope - never unchecked that. I know it's rebooting as it relays are going off on reboot and on again as part of the startup code. And it's random - it doesn't do it every time.

I'm not sure if this is what the OP is experiencing however!

alexsquared

I know my master is rebooting as well. The real interesting thing, is that I just did a debug verify TKN and it says the files match???? When i test it though, i notice that everything but the IR command I added go through. this is really confusing to me.

DHawthorne

I had something like this happen to me once, and I got support on the phone while on site. The only thing that got it to recognize the change was clearing the master and re-sending anything. They were baffled as to what caused it in the first place. I suspect something in the routines that make persistent variable persistent ... some flag not getting set, or some other oddball issue causing the new data not to overwrite the old. But it's only happened to me once, and it was a real long time ago ... at least two years.

So, I guess if all else fails, run the clean doc command to wipe the master, then reload it once more.

alexsquared

That's what I had to do last time as well. The frustrating part for me is that this is the second occurrence on the same master.

rrdbstudios

Another possibility that has gotten me is a persistent array of items.

I found out how persistent really is... ie. even after firmware update and reloading program. If the variable name is the same, despite adding or removing values, it will just skip over that array in its portion of memory for persistent objects.

What I do in that case is load a dummy program then reload your program and good as new, the new values comes through or removed values are gone.

alexsquared

rrdbstudios wrote: »

Another possibility that has gotten me is a persistent array of items.

I found out how persistent really is... ie. even after firmware update and reloading program. If the variable name is the same, despite adding or removing values, it will just skip over that array in its portion of memory for persistent objects.

What I do in that case is load a dummy program then reload your program and good as new, the new values comes through or removed values are gone.

In this case, wouldn't doing a clean disk through the telnet prompt and then reloading also work? This would seem cleaner then downloading a dummy program and then updating again.

rrdbstudios

I reset to factory defaults, because I was so confused why old information was still popping up onscreen, and I verifed the TKN, and everything.

Even after factory reset and firmware update the information was still there, AMX told me the memory used with persistent variable is separate from all others, and is cleared with loading a new program with variable that dont match the names of existing ones loaded.

So to answer you question, no a reset doesn't erase it.

alexsquared

Wow, that's a mess. You would think these items would always be cleared in the midst of a program update.

rrdbstudios

alexsquared wrote: »

Wow, that's a mess. You would think these items would always be cleared in the midst of a program update.

Nope, reason be, if you want to keep your program up and running and all its settings, but want to reboot, or update firmware, etc.. or even software update but keep your data/settings intacted.

jimmyw

alexsquared wrote: »

You would think these items would always be cleared in the midst of a program update.

Isnt that kind of the point of Persistent?

If you want a variable to hold its value between power loss, use NON_VOLATILE
if you want a variable to hold its value between software reloads, use PERSISTENT

NON_VOLATILE uses the values defined in the program to set its initial value on program reload, and holds that value between reboots

PERSISTENT uses the INITIAL value defined in code, only on the first load, from that point on, all changes made to source and loaded are ignored!

alexsquared

jimmyw wrote: »

Isnt that kind of the point of Persistent?

If you want a variable to hold its value between power loss, use NON_VOLATILE
if you want a variable to hold its value between software reloads, use PERSISTENT

NON_VOLATILE uses the values defined in the program to set its initial value on program reload, and holds that value between reboots

PERSISTENT uses the INITIAL value defined in code, only on the first load, from that point on, all changes made to source and loaded are ignored!

I understand that, and in reading my post I see I wasn't clear. Ultimately, the problem is that this results in the new file not being uploaded. I don't think there should be any piece of data (variable, array, etc) that could potentially prevent your new data from being uploaded.