Logix Memory Analysis Tool

Mispeld

Member
Join Date
Feb 2017
Location
VA
Posts
644
I'm looking for a tool that will analyze a Logix 5000 program file (e.g., an L5X), and provide estimated memory usage by logic, tags, documentation, etc.; broken down by controller and individual program scopes. Ideally the results could be sorted and visualized to help determine where it is all going.

For example, we just encountered a situation where a project was delivered with a controller at 90%+ memory usage. The complexity of the task did not seem to justify that much memory. It turned out there was an excessively-dimensioned array of user defined types, with embedded arrays allocating a significant chunk of memory. Around 20% could be recovered by simply re-dimensioning to what was actually needed.

The manual approach to finding this was tedious. Built-in Logix reporting was not very helpful in this regard, as far as I could go with it. There did not seem to be anything in any of the Rockwell add-on tools, either. Are there any Rockwell or third-party tools for this type of analysis that I'm missing?
 
I can't share any of the tools I've created, but I can share some advice on how to get started. The L5X file contains most of what you need to work with except for datatype size information. This information is stored in the ACD file, but it doesn't get exported. However, if you locate the temporary files created when editing an ACD file, you'll find an accessible XML file with datatype and tag information. If this file has no size, just close and reopen the ACD file. Combining this data allows you to calculate tag memory usage by scope. I suspect this is how RSLinx is able to create offline OPC namespaces when a topic's symbol database is specified as an ACD file. Most of the other temporary files are locked, but checking the size of the comment file could give you an idea how much memory they occupy.
 
I'm looking for a tool that will analyze a Logix 5000 program file (e.g., an L5X), and provide estimated memory usage by logic, tags, documentation, etc.; broken down by controller and individual program scopes. Ideally the results could be sorted and visualized to help determine where it is all going.

For example, we just encountered a situation where a project was delivered with a controller at 90%+ memory usage. The complexity of the task did not seem to justify that much memory. It turned out there was an excessively-dimensioned array of user defined types, with embedded arrays allocating a significant chunk of memory. Around 20% could be recovered by simply re-dimensioning to what was actually needed.

The manual approach to finding this was tedious. Built-in Logix reporting was not very helpful in this regard, as far as I could go with it. There did not seem to be anything in any of the Rockwell add-on tools, either. Are there any Rockwell or third-party tools for this type of analysis that I'm missing?

You need to talk to your SI, or constrain them with "standards"
 
Thank for the advice. While I was scanning through the L5X, I figured it was all there, not realizing a critical piece of information (datatype size) was missing. So thanks, Nomographer, on how to acquire this. Those are all excellent tips.

In this experience we were our own worst enemy with "standards." Since we are under management pressure to limit expansion of our spare parts inventory, the standard dictates hardware choices. So the SI shoe-horns the program into what we asked for -- though it would have been nice to get a warning before the equipment showed up. Now that we are farming out a lot more work, the standards will get some attention in this area.
 
Thank for the advice. While I was scanning through the L5X, I figured it was all there, not realizing a critical piece of information (datatype size) was missing. So thanks, Nomographer, on how to acquire this. Those are all excellent tips.

In this experience we were our own worst enemy with "standards." Since we are under management pressure to limit expansion of our spare parts inventory, the standard dictates hardware choices. So the SI shoe-horns the program into what we asked for -- though it would have been nice to get a warning before the equipment showed up. Now that we are farming out a lot more work, the standards will get some attention in this area.

When you open up the definition of a UDT, it tells you right there how many bytes of memory the data-type size is (see pic). Obviously a tag created from that UDT will have a memory overhead, to accommodate tag-name, attributes etc.

For your "standards", you might like to consider the following....

It is more advantageous in memory utilisation to create arrays whenever possible, instead of unique tags, as the overhead is only once per tag.

UDTs should be only as big as they need to be, i.e. no "spare" members to be allocated. UDT's cannot be edited online anyway, so any modifications to UDTs must be completed offline, and downloaded.

UDT creation should be optimised for UDT size. The members should be ordered in data-type order, lowest to highest, or highest to lowest, it matters not. If members are randomly ordered, it increases the byte count dramatically.

Arrays should be optimised with a maximum of xx% spare elements.

STRING data-types should be created to hold the maximum number of characters needed by the application. Using the native STRING data-type, which can hold up to 82 characters, for e.g. Recipe names, Ingredients etc., can be wasteful if you only require strings of up to, say, 20 characters in length.
 
Last edited:
While manually looking for tags with large memory allocation, I stumbled upon a convenient way to get data type sizes within the Logix/Studio5K: In the Controller Organizer, open up the data types, and expand the various categories (e.g., User-Defined, Strings, etc.). When you click on the type name, the pane below the organizer tree shows the description and size. You can then just arrow down through all of the types if you're only interested in total size. Then right-click and cross-reference any really large ones to see if, and how many times, the type is being used.

Interestingly, the cross-reference function is disabled for system-provided types. This was especially disappointing with the stock "STRING" type. However, you can cross-reference user-defined string types.

At least sorting tag databases by data type will group all of the STRING types to help locate any unnecessarily large arrays. This still needs to be done for each program and at controller scope. Also helpful if looking for multi-dimensional arrays.
 

Similar Topics

Could I ask what the FW column signifies on the file memory usage report on RSLogix 5.
Replies
2
Views
1,680
Hi all, I will be installing a brand new CF card into the slot on a CompactLogix L32 processor. This to provide permanent backup memory for the...
Replies
1
Views
884
I have backed up programs to a CompactLogix SD card probably fifty times in the last 3 years, so I am very familiar with the process. For some...
Replies
2
Views
1,152
Hello all, would anyone be able to let me know roughly how big of a program would fit on the 600kb 5069 cpu? i've only every really worked...
Replies
1
Views
1,536
Back
Top Bottom