CLX - Actual size in memory of Single/Multi-Dimensional Arrays?

[Righty]

Hey guys,
I am having issues, which I believe to be with data that is not visable.. I am wondering if anyone has a source describing the lengths and position of header data for arrays.

I have viewed documents that show memory usage for ADD operations for each Datatype.. is there anything that shows actual usage and location of arrays?

When copying a NULL single array into a NULL multi array, the multi array ends up with random 1(HIGH) bits.

I have tried the basic way, copying the UDT..
I have tried the advanced way, matching lengths...

There seems to be data which I cannot see.

The only place I can see data comming from is pointer or naming data burried within the multi-dimensional array.


UDT of DINT[5]
MajorArray[8,8] of UDT
MinorArray[2] of UDT (basic)
MinorArray[10] of DINT (advanced) ( have changed lengths, and also went to INTs to get byte sizes)

Trying to use COP to avoid 64+ rungs...

This is on RS5000, 20.01.. which shouldn't matter.

Thanks in advance.

-Righty

 

[bernie_carlton]

To help I think you will have to provide the exact UDT definition in question, a listing of contents of the tag before the Copying, the code used in Copying and the contents after the Copy noting the suspect data.

Possibly make a short version of the program with just the relevant data and code. Post a 'before' and 'after' version.

You will have to 'zip' the ACD file before posting.

 

[Ken Roach]

You'll have to provide more exact information about the UDT structures.

In general, the COP instruction collects enough data to fill the number of destination elements called for by the Length argument.

If the target is a UDT of (for example) 20 bytes, but the Source is a UDT of just 16 bytes, the COP instruction will grab 4 bytes from RAM beyond where the Source is stored.

I don't think there is any programmatic or project way to determine exactly what that data will be.

The usual and prudent way to solve the problem is to match the datatypes of the source and destination tags in the COP instruction.

 

[Righty]

@ ken
The UDT used remains the same. It is indeed 20 bytes (as shown from the UDT window).

I have an array of them, multi-dimensional 8x8. 64x20byte = 1280bytes.
How would you check actual length of the array?

Before worrying about lining up data, I'd like to solve why I'm getting 1's in null arrays.

My thinking is that lengths should not matter when copying in NULL data.

I copy a NULL array of 10 DINTs into a NULL multi-dimensional array 8x8 of DINT[5].. the copy length say 10 I everything should still be NULL.

As long as I'm still within the bounds of my multi-dimensional array, it wont matter.

Same thing without numbers:
Null single into NULL multi COPY length within bounds should all equal 0/NULL


This is just a make work project, but I'd love to dig deeper into how AB stores data.

For all I know COPY could skip a byte in memory between array elements(leaving out pointer info etc).

Thanks again gents ;D

 

[bernie_carlton]

Copy will copy from the source into the destination accurately as long as the source is equal to or longer than the destination. If the destination is longer it will then grab whatever garbage is after the source in memory and copy that into the rest of the destination. (What Ken said but in different words.)

Inestigate the File Fill (FLL) command to do this process.

 

[Ken Roach]

The Length argument of the COP instruction is the number of Destination elements, not the number of Source elements.

Let's say the destination is an 8x8 array, of which every element is a DINT[5].

If your Destination is ArrayTag[0,0] and the Length is 10 elements, the COP instruction will move fifty DINTs because every Element is a DINT[5].

 

[Righty]

I apologize, he did explain just that. I must have read over the second part of his sentence.

I have a feeling that when an element is added to an array, extra data is added to it, making it larger.
Trying to copy a single into a multi therefore has a smaller source and doesn't copy right.

The elements may be the same size, but there is more data added for each dimension of the array.

I will look into FLL tomorrow.

Thank you both, I didn't expect to have both juggernauts post in here ;D

EDIT
@Kens second post
There are two parts to this problem, one is COPYing single to multi, the other is copying data in a pattern.
Moving 50 DINTs is what I'd expect.

As suggested by Bernie, I'll look into the FLL tomorrow. I may be using the wrong tool for the job.

What I can promise you is that I am over complicating things.
The project is something that should never be on a PLC, and I am approaching it from a Higher level language angle.