Memory Space Question

[ATU]

I have one program that I duplicate 16xs in my application.  I had to make some major changes, so I deleted all the rungs in programs 2-16. Once I get it working, I will copy those rungs into those programs and make modifications
So I have 1 program with 743 code space memory locations. That is the number on the rung below the last instruction.
Before the copy, my program shows 10952/65536  code memory space
I paste only the rungs from first program into the shell of program 2 and the program space now shows 11748/65536

10952+743  = 11,695

Where did I lose  53 code space memory locations?  I want those back, what is going on?

[franji1]

There is more information stored in ladder memory than just the code you see.  Each code-block has start/end delimiter instructions, along with the list of rung handles (one opcode for every 2 rungs).  There are also hidden code blocks (but those are mostly constant, but can change based on what you are doing).

Also, until you write to the PLC, we don't know the precise number because some optimization/tweaking does occur at download time, and we end up with the actual buffer of DWORD opcodes, THEN we know EXACTLY how big your program is.

[ATU]

   Thanks.  I had no idea that more rungs cost me space, besides what is in the rung.  Good to know.  It would be nice to know the real approximate size of a program module in the editor.

[franji1]

  Thanks.  I had no idea that more rungs cost me space, besides what is in the rung.  Good to know.  It would be nice to know the real approximate size of a program module in the editor.

It does not hurt anything.  It is never executed, so it does not take a bump to the scan time.  If you are truly running out of memory, there are other ways to optimize your code other than removing the concept of a "rung".

I used to work with a guy that wrote totally unreadable C++ code, because he was more worried about making the compiler be fast (not the actual execution time, but compile time), because he thought he was being "smart".

Unless you are running out of memory, it is a complete waste of time/effort to optimize for "size".

[ATU]

I was over , dropped some features, wrote a few more subroutines  and got it down around 58K , but I am not done yet. I used a lot of stages to get the optimal execution speed for the project.  It's amazing what you can do  with the BRX.

[franji1]

Unless you are running out of memory...

Then maybe you will need to optimize for size  !

[ATU]

I guess I can hold off adding more features until you folks come out with a CPU having more memory.