SLC 5/03 Memory full! Need to clean house!

Hey guys, I've got a system that has been around for 10+ years now, many changes have been made, things have been added things have been removed. It seems data files were always added, never removed with the changes.

Today I got a messge saying I'm out of memory, and of course I need to add more to the system. I've gone through all the files, clicked on the "usage" button to determine what files and addresses I can delete and what I can't. However, I'm concered about the indexed addresses, and the indirect addresses that are being used. Does the "usage" button account for these? I've used the find tool and searched the through the addresses for "#" and "[", and I've been successful finding the corresponding indexed and indirect adresses;I'm just wondering if I could still be over-looking something.

Easiest way is to upgrade to a processor with more memory.

you didn't specifically mention looking for and removing any memory "holes" ... this post will explain if you're not familiar with the term ...

and no, the "Delete Unused Memory" feature will NOT recover wasted memory from a file which includes an INDIRECT address ... simple reason: the software has no way of knowing what value you're going to put into the [pointer] address ... files using INDEXED addressing will usually be handled correctly ... that's because the # pointer is specified in the instruction's LENGTH entry - so the software has a better idea of what's going on with the memory usage ...

and I'm SURE that you've already thought of this - but ... MAKE A BACKUP COPY ! before you do anything else ...
good luck with your project ...

The main thing you have to be aware of, when upgrading, is the communications. We upgraded from a 5/03 to a 5/04 because of memory issues, and had a heck of a time getting the original network between the computer, PLC, and Panelview back and working.

Edit: Ok, it really wasn't a heck of a time, we were prepared, but were kind of rushed at the time, and it took about twice as long as what they had given us to upgrade.

Thanks Ron, looking for and removing any memory "holes" is exactly what I want to do! Great post!

Spending more time/money on a proccessor upgrade for this system is not worth it, were already dumping enough money into other aspects of the system, a CPU upgrade due to poor memory management is not a good reason to justify the expense.

It's funny how upgrade justifications work. Poor memory management is ultimately the reason for the upgrade, but we are talking about an old, often modifed production system that needs more available memory for an upgrade.

I would think that your time digging through unused memory (not to mention indirect addressed memory) plus potential risk would be significantly more expensive than to just purchase the upgrade. Certainly true if you're an integrator - I guess it would be hard to justify to your boss if you've been working on this system for years.

Good luck to ya either way.

Paully's5.0 said:

Thanks Ron, looking for and removing any memory "holes" is exactly what I want to do! Great post!

Spending more time/money on a proccessor upgrade for this system is not worth it, were already dumping enough money into other aspects of the system, a CPU upgrade due to poor memory management is not a good reason to justify the expense.

Click to expand...

Ron,
Awesome tool and way of using the S&R to "fill" the "holes". This could work wonders for a simple project. Your indirect addressing explaination and example is dead on, however it's worth emphasizing again:

OP - make absolutely sure that you know where the indirect addressing is going before removing holes. I don't know exactly what would happen, but know that it couldn't be good.

What happens in a SLC if you try to indirectly address a non-existant register? My guess is that it ranges from a bad/incorrect value to a crash. Does this result depend on anything else?

Ron Beaufort said:

you didn't specifically mention looking for and removing any memory "holes" ... this post will explain if you're not familiar with the term ...

and no, the "Delete Unused Memory" feature will NOT recover wasted memory from a file which includes an INDIRECT address ... simple reason: the software has no way of knowing what value you're going to put into the [pointer] address ... files using INDEXED addressing will usually be handled correctly ... that's because the # pointer is specified in the instruction's LENGTH entry - so the software has a better idea of what's going on with the memory usage ...

and I'm SURE that you've already thought of this - but ... MAKE A BACKUP COPY ! before you do anything else ...
good luck with your project ...

Click to expand...

inductiveautomation said:

Ron,

What happens in a SLC if you try to indirectly address a non-existant register? My guess is that it ranges from a bad/incorrect value to a crash. Does this result depend on anything else?

Click to expand...

the processor will goes to fault mode causing set major error bit

Greetings to all ...



and thank you for the kind compliments ...



along these same “memory” lines, here’s a little programming trick that I discovered several years ago while reading through a customer’s program ... I’d never seen it used before - and I’ve never seen it used since ...








at first I looked at this and just scratched my head ... “what the heck is this silliness?” ... basically we’re just COPying 10 words of data FROM itself right back TO itself ... and that’s just a waste of time and processing power ... but no, the AFI keeps the COP from executing anyway ... then it hit me ... I checked further and sure enough - those 10 words of data were being used on another rung for INDIRECT addressing ...



the guy who did this little trick either had some previous “been-bit-by-that-dog-before” experience - or else he was a paranoid programming genius ...



here’s the punch line - just in case you haven’t seen it yet ...








those X-marks wouldn’t be there without the “marker” rung above ... specifically, INDIRECT addressing won’t show up when you use the “Usage” feature ... but ... INDEXED addressing will ... and the "do-nothing" COP instruction uses that 10 word range of data as an INDEXED address ...



so the original programmer was just “staking out” his claim to this area of the data tables - so that anyone else (and possibly himself later on) who started digging around for some available data would hopefully leave this little section alone ...

Ron - that is COOL. I think I'll borrow that little tip.

Ron Beaufort said:

you didn't specifically mention looking for and removing any memory "holes" ... this post will explain if you're not familiar with the term ...

Click to expand...

Ron,

As usual, your posts are great! I read the post referenced above and learned something I did not previously know:

When using "search-and-replace", I always did a cut-and-paste of the descriptions. I never realized that you can get descriptions to follow the replacement by selecting the appropriate option box!

Thanks for the time-saving tip which I will most certainly use in the future. (I clean up a lot of old, badly-written programs... Some are even written by me.)

Well, using Ron's suggestion this is what my program found:



Even found my one indirect address Once the system has some downtime available I'll drop the edited program in, stick around for startup, and be available with the original program just in case.

Notice that the big hit was the ST file. 11 elements times 80 bytes equals 440 words of memory! I recently went through a similar change on a 5/04 and found that a bunch of "spare" ST files were hogging all my free user memory.

Also, don't forget to expand some of those data tables if necessary to support your upcoming changes before you download, or you'll have to stop the process again to squeeze in your changes.

Ron,

Wow, great info. Sorry for not having replied to that original thread (I was the O.P.) Not sure why. I don't remember ever coming back to that thread. DOH! I'll definately save that info for next time.

Is there a way to do the search/replace with blocks of data instead of just one address at a time. Our 5's are now 11+ years old and we've got lots of those holes, but they're not follewed by just one or two addresses.

FYI...we upgraded to the 60 and we haven't done much since. I found a couple used 60Ls on (cough) Ebay for under a grand each, so I figure why not try and see what we get. Been running for almost a year now with no troubles.

OkiePC said:

.....
Also, don't forget to expand some of those data tables if necessary to support your upcoming changes before you download, or you'll have to stop the process again to squeeze in your changes.

Click to expand...

Yup, they've been accounted for.