Register COP, MOV, MVM Unsigned to Signed, Etc.

[AMarks95]

I'm having to make an AOI to use with a generic ethernet device because the manufacturer does not provide an AOP. I just want to do a sanity check to make sure I'm copying/moving/masking things correctly to get the results I expect, since these are not things I typically do.

The bits are easy enough to handle, it's just the combining of SINTs and conversion to other datatypes.

The input data structure is an array of SINTS. Here's an example:

Breakdown of Data | type SINT[12] :
Bytes 0/1 - UINT Trip Code
Bytes 2/3 - Trip Bits | [2].2 = Ground Current, [2].3 = Thermal Overload, [3].0 = comm trip
Bytes 4/5 - INT Temperature (deg C)
Bytes 6/7/8/9 - UDINT Current (x0.01 A)
Bytes 10/11 - Misc. Stats and Current | [11].0 - [11].5 ( 0 - 63 )


Trip code:
COP(Source = Data[0], Dest = TripCode, Length = 1) | where TripCode is type INT
Not worried about signed vs unsigned here because the code will never be larger than 555.


Trip Bits:
GroundCurrentTrip = XIC(Data[2].2)
ThermalTrip = XIC(Data[2].3)
CommTrip = XIC(Data[3].0)


Temperature:
COP(Source = Data[4], Dest = Temp_INT, Length = 1) | where Temp_INT is type INT
MotorTemp = ( Temp_INT * 9/5 ) + 32 | where MotorTemp is type REAL


Current:
COP(Source = Data[6], Dest = Current_Temp, Length = 1) | where Current is type DINT
Current = Current_Temp / 100 | where Current is type REAL
Less confident about this one because of the unsigned/signed thing. Should Current_Temp be type UDINT? - COP doesn't like the datatype UDINT, and UDINT is not allowed inside CPT


Misc. Stats and Current:
COP(Source = Data[11], Dest = Temp_SINT[0], Length = 1) | where Temp_SINT is type SINT
MVM(Source = Temp_SINT[0], Mask = 2#11111100, Dest = Temp_SINT[1])
Current2 = ( Temp_SINT[1] / 32 ) * 100 | where Current2 is type REAL
I realize the COP is an extra step, but I like it for readability's sake.


Any help is much appreciated. Thanks!

 

[JeremyM]

COP() is a great choice for mapping bytes of incoming data, since it is bit-wise work.

I would argue it’s the best choice.

You can take it a step further:
- construct a UDT that matches their layout
- then simply COP(Device:I, UDT, 1)

 

[AMarks95]

COP() is a great choice for mapping bytes of incoming data, since it is bit-wise work.

I would argue it’s the best choice.

You can take it a step further:
- construct a UDT that matches their layout
- then simply COP(Device:I, UDT, 1)

What do you mean by a UDT that "matches their layout"?
If I created a UDT with data elements in the exact same order accounting for every bit, but not necessarily the same type, I can copy directly?

So, for instance in this case, my UDT would be:
Data_UDT :
TripCode type UINT
Trip_Bits type SINT[2]
Temperature type INT
Current type UDINT
Misc type SINT[2]


Then do a COP(Device:I, Data_Map, 1) | Data_Map is type Data_UDT

Will it copy the data over in order and then I can go from there?
So, essential the COP operation would just fill up TripCode with the first 16 bits, then Trip_Bits with the next 16, then Temperature with the next 16, then Current with the next 32, and Misc with the next 16?

 

[JeremyM]

You can copy directly.

Can also combine trip bits into an INT or UINT, same for MiscType.

 

[AMarks95]

COP() is a great choice for mapping bytes of incoming data, since it is bit-wise work.

I would argue it’s the best choice.

You can take it a step further:
- construct a UDT that matches their layout
- then simply COP(Device:I, UDT, 1)

Combine trip bits into an INT or UINT, same for MiscType.

Right, but that's pretty much optional and personal preference. It'll still work, right? The basic understanding is the same.

 

[JeremyM]

It will work, yes.

Dealing with an array sub-element instead of a matched INT/DINT can become cumbersome later when you go to use it in code:
- Data.Status[0].4 or Data.Status.4?
- Data.Status[1].3 or Data.Status.11?

Then there's MiscType:
- Is it really just INT/UINT from the device?
- If so, you'll be doing another COP(Data.MiscType[0], AnotherMiscTypeTag, 1) instead of just using Data.MiscType directly.

 

[AMarks95]

I've got a UINT now with the first 8 bits being status bits, the next 6 being an INT, and last 2 being status bits. How do I go about extracting those 6 bits from the center?

 

[drbitboy]

I've got a UINT now with the first 8 bits being status bits, the next 6 being an INT, and last 2 being status bits. How do I go about extracting those 6 bits from the center?

1) Mask (bitwise AND) with 0x3f00 and divide result by 256 (0x0100)


or


2) https://literature.rockwellautomation.com/idc/groups/literature/documents/rm/1756-rm003_-en-p.pdf#%5B%7B%22num%22%3A4093%2C%22gen%22%3A0%7D%2C%7B%22name%22%3A%22XYZ%22%7D%2C45%2C399%2C0%5D

 

[AMarks95]

1) Mask (bitwise AND) with 0x3f00 and divide result by 256 (0x0100)

MVM does not like UINT for whatever reason. Neither does COP. I'll just do that one separately from the raw data, rather than extracting from the COP to UDT.

 

[JeremyM]

I've got a UINT now with the first 8 bits being status bits, the next 6 being an INT, and last 2 being status bits. How do I go about extracting those 6 bits from the center?

In that case, you can take a small step back in your UDT and make the UINT two USINT.

First one is StatusBits, second one gets ANDed with 0x3F mask, and remaining pair of bits can be addressed directly (byte.6, byte.7).

 

[JeremyM]

MVM does not like UINT for whatever reason. Neither does COP. I'll just do that one separately from the raw data, rather than extracting from the COP to UDT.

Just use AND instruction in ladder or AND operator in ST. No need for MVM.

 

[drbitboy]

MVM does not like UINT for whatever reason. Neither does COP. I'll just do that one separately from the raw data, rather than extracting from the COP to UDT.

I wrote "mask (bitwise AND)," not MVM.

 

[AMarks95]

I wrote "mask (bitwise AND)," not MVM.

Ya, sorry. When I hear mask, I just automatically think MVM.

AND also does not like UINT

 

[JeremyM]

Ya, sorry. When I hear mask, I just automatically think MVM.

AND also does not like UINT

That’s news.

Fortunately, INT will work fine for status bits.