Ah pardonne moi,
I jumped ahead in my thinking. I meant to say while creating 32
individual BOOL tags, and not a BOOL[32] array, we would inefficiently be using 32 bits per BOOL. I seem to recall making the very same mistake here before and someone else correcting me? I obviously haven't learned my lesson!
Thank you Daba, that was silly of me.
Yes, BOOL arrays are more efficient than individual BOOLs, memory-wise. But are BOOL arrays more efficient than using DINT members as BOOLs?
BOOL arrays are not the most supported method of using BOOL addressing. For instance, basic file type instructions such as COP and MOV do not support BOOL arrays. This is where creating the BOOL array inside a UDT may be necessary.
If we take the COP instruction, and needing to copy one BOOL array to another, we cannot use a BOOL array tag as the Source or Destination operand. To get around this we can create UDTs to nest the BOOL arrays; one for the Source and one for the Destination. This way we can add the tags of the User Defined Data Type to the COP instruction's Source and Destination operands and the array data will be sucessfully copied.
So in that case the use of BOOL arrays is inefficient by having to create UDTs, which uses extra memory, to facilitate a relatively simple copy operation. If you don't need to be copying or moving BOOL arrays then it may not matter. But there is another slight disadvantage to using BOOL arrays over DINTs with regard to memory...
If you add a DINT tag how much memory does it consume?
If you add a BOOL[32] array how much memory does it consume?
When it comes to memory, every tag of varying data type we create consumes a certain amount of memory. But we have to consider, when trying to conserve precious memory, how much a particular tag actually consumes beyond the known data type "bit width". We say a tag of DINT data type is stored using 32 bits. That is correct for the data type, but there is also overhead for things like the tag name, which can be up to 40 characters. The tag name is compiled and stored in the processor for reference, so it consumes memory at runtime.
A tag of data type DINT, while we say executes using 32 bits, or 4 bytes of memory, is actually stored in the processor using 88 bytes, when we include the overhead.
A tag of data type BOOL[32], while we say also executes using 32 bits, or 4 bytes of memory, is actually stored in the processor using 96 bytes, when we include the overhead. The fact that this is an array adds a small bit more to the overhead.
Daba,
When you created the DINT[100] and BOOL[3200] arrays they both consumed 496 bytes. This is because they are both using the same data type bit width, the same tag name overhead, and the same array overhead.
So memory-wise, a single DINT tag will consume less memory if used for BOOL tags when compare to a BOOL[32] tag.
Geospark said:
...Add an INT member to a UDT and what size is it?
Add an INT[2] member to a UDT and what is it?...
Robobob said:
They are both 4 bytes in size.
Exactly.
A single tag of data type INT will consume 4 bytes in the UDT, the same as a single tag of data type DINT. This is a waste of 2 bytes. Whereas an INT[2] array inside the UDT will still consume 4 bytes, wasting nothing.
Of course, all these finer details don't really matter unless your fighting to retain or recoup precious memory.
Another simple, but not always possible, task is to perform another download. This will recompile the code into contiguous memory and if there were sufficient changes of the right nature made since the last download then this could be surprisingly useful in freeing up memory.
Regards,
George
