Changing memory allocation in a CompactLogic

Is there a way to change the memory allocation in a CompactLogic processor. I am runing out of "Data and Logic" memory but have tons of unused I/O memory.

Can I steal some of the I/O memory to give me a little boost in Data and Logic?

No, but you can consolidate related tags by creating User-Defined types. When you instantiate a UDT object, the usual memory overhead (IIRC, 80 bytes per tag) is reduced to one 80-byte penalty per UDT object created. If you have many type-homogeneous tags (DINTs everywhere, BOOLs galore, UDTs willy-nilly, and so on) create arrays of them if it makes sense within the scope of your project, for the same reason.

If you are running v24 of Studio 5K or later, you can create public parameters (tags that can be accessed from other programs directly) defeating the need to write program-scoped tags to a controller-scoped duplicate of the tag for other programs to consume.

If you've exhausted your options, a higher-capacity processor is what remains.

JeremyM said:

No, but you can consolidate related tags by creating User-Defined types. When you instantiate a UDT object, the usual memory overhead (IIRC, 80 bytes per tag) is reduced to one 80-byte penalty per UDT object created. If you have many type-homogeneous tags (DINTs everywhere, BOOLs galore, UDTs willy-nilly, and so on) create arrays of them if it makes sense within the scope of your project, for the same reason.

If you are running v24 of Studio 5K or later, you can create public parameters (tags that can be accessed from other programs directly) defeating the need to write program-scoped tags to a controller-scoped duplicate of the tag for other programs to consume.

If you've exhausted your options, a higher-capacity processor is what remains.

Click to expand...

I seem to recall a trick, usable only for UDTs, whereby the order of variables determines the total memory usage of an entry. If you have a BOOL, followed by a DINT, followed by a BOOL, that uses more bytes than a BOOL/BOOL/DINT. Now, if you have a great number of these, the difference could be noticeable.

jdbrandt said:

I seem to recall a trick, usable only for UDTs, whereby the order of variables determines the total memory usage of an entry. If you have a BOOL, followed by a DINT, followed by a BOOL, that uses more bytes than a BOOL/BOOL/DINT. Now, if you have a great number of these, the difference could be noticeable.

Click to expand...

I fully confirm that.
The memory is allocated by 4 bytes, so even 1 BOOL will be allocated with 4 bytes.
The general unwritten rule (let's call it good practice ) is to create the UDT's using the smallest fraction of a byte at the start followed by the other data types. Something like a piramide.

This may help also. It seem the memory online can get fragmented just like a hard drive:

Fragmentation of Controller memory can also occur over time from heavy Online program modification. (e.g. if a routine is deleted and the space it once utilized is now open, a new routine may or may not be able to occupy that space depending upon it's size. This can lead to pockets of free memory of various sizes.) Re-downloading to the Controller will once again compile the application using contiguous memory and essentially defragment the memory.

Another not from the manual on UDT's:
Group members of the same data type within a structure.: A Logix5000 controller aligns every data type along an 8-bit boundary for SINTs, a 16-bit boundary for INTS, or a 32-bit boundary for DINTs and REALs. BOOLs also align on 8-bit boundaries, but if they are placed next to each other in a user-defined structure, they are mapped so that they share the same byte.