Stuido5k COP question

[ceilingwalker]

Hello all. I have a Danfoss VLT feeding an INT into my CpLX program. I need to concatenate the MSB and LSB for position. I used a COP, making sure they are contiguous and in the correct order however, I do not get an accurate count vs. what I see on the VLT's software (MCT10). When I create two new arrays and then MOVE those values into them, then use a COP, it works perfect. I am not understanding what the difference is here. The top one is feeding back the correct info but I have the added steps to make it work that I don't think I should have to?

 

[drbitboy]

>>> for i,j in [(23,0,),(-13686,65536,),(1559178,0),(-896925673,1<<32,)]: i,hex(i+j)

...

(23, '0x0017')

(-13686, '0xca8a')

(1559178, '0x0017ca8a')

(-896925673, '0xca8a0017')

See items (i) and (vii) below.

Think about the bits, and the meaning of the Length parameter to the COP instruction.

In the first example, which gives the correct result, the COP should be between the MOV ...Data[3] PosStorage[0] and the MOV Position WhereIis, but the result is the same as long as the ...Data elements do not change; when they do change, it will take an extra scan cycle to update WhereIis).

In the second example, the contents of PosStorage are never written to Position. The non-functional COPs, and the final MOV to WhereIis could probably be replaced by a single SWPB Position WhereIis WORD instruction.

 

[plvlce]

Your MOV instructions invert the order of the bytes in PosStorage compared to the direct COP. If this is resulting in a correct result it implies you are wrong about which byte you think is more important.

This could also be accomplished using the SWPB instruction.

 

[Aardwizz]

What is the data type of Cartesian_Z:1iata ?

If it is a DINT (even though only containing 16 bits of data) and PosStorage is an INT, then what you are doing is what you have to do.

The number of bits copied by a COP is determined by the destination (and length).

The DINT data type has 32 bits, whether they are used or not. A COP (DINT[0], REAL, 1) is only going to copy 32 bits (the size of the REAL) from the DINT array into the REAL, and thus will take all 32 bits of DINT[0] and nothing of DINT[1].

OTOH, a COP (INT[0], REAL, 1) is also going to copy 16 bits from INT[0] and still need to copy an additional 16 bits, so it will take those from INT[1].

If the function is COP(SINT[0], REAL, 1), then the 8-bit patterns from SINT[0], SINT[1], SINT[2], and SINT[3] would be copied to form the 32-bit REAL.

Does that help ?

You might be able to "fix" things depending on how Cartesian_Z:1iata got defined, either by editing the EDS file or by changing the configuration of the Generic Ethernet Device (if that's what you're using) for a Comm_Format of "Data - DINT" to "Data- Int".

But that could break other things, so caveat emptor / you get what you pay for and this is free advice and thus paid for with nothing and worth the same.

 

[lostcontrol]

Can you not change the RS5K config to be DINTS instead?

 

[drbitboy]

The top one works because it swaps the word order:

 

[ceilingwalker]

The top one works because it swaps the word order:

Thank you, I understand that. In the VLT's config s-ware I am able to change the order of the PCD's, changing the registers as they are read by the PLC. I have reversed the order there however, it gives me a funky number not even close to the actual position. I have tried to change the order of the words before the PLC several times so I can use the COP but the only way I have been able to get it to read correct is with my example above and I am just not getting why. This seems as though it should be so cut and dry but.......

 

[chelton]

Thank you, I understand that. In the VLT's config s-ware I am able to change the order of the PCD's, changing the registers as they are read by the PLC. I have reversed the order there however, it gives me a funky number not even close to the actual position. I have tried to change the order of the words before the PLC several times so I can use the COP but the only way I have been able to get it to read correct is with my example above and I am just not getting why. This seems as though it should be so cut and dry but.......

From memory the PCD's are byte's, you might be only changing the order of the bytes not the word.

 

[drbitboy]

From memory the PCD's are byte's, you might be only changing the order of the bytes not the word.

^ this


If you are byte-swapping on the Danfoss VLT, then on the CpLX the data are both MSByte- and MSWord-first in the four bytes of .Data[2] and .Data[3], so try the SWPB instruction's REVERSE mode after the COP.

 

[drbitboy]

Actually, rather than trying to do the bookkeeping (which is all this is), whether you byte-swap on the Danfoss side or not, simply trying all combinations, like this:

COP Cartesian_Z.I1.Data[2] dint32 1

SWPB dint32 dint_reverse REVERSE

SWPB dint32 dint_word WORD

SWPB dint32 dint_hilo HI/LO

​

Will result in one of those dint32* tags having the correct value, and then you can use the SWPB mode that works and drop the other two.

 

[ceilingwalker]

From memory the PCD's are byte's, you might be only changing the order of the bytes not the word.

That's exactly what I am seeing.