UINT to INT

[drbitboy]

See above. I got it working.


Thanks for all the help!

If you did not correct the off-by-1 error of post #21, then it still may not be working correctly yet.

Are you sure you are pairing the correct low-word, odd-address Modicon value with its corresponding high-word Modicon value (near 17024)?

If all of the pressures are roughly the same, then the error would be less than 1%, so you cannot tell by looking at the resulting floating point values.

Bookkeeping. Just trying random things until it "looks" right, which is pretty obviously what was being done, is not enough.

 

[drbitboy]

but you're missing the part where the data on the RIGHT is the data I have to work with. It represents what came in. The data on the left is the source.

It does not matter.

>>> import struct

>>>

>>> ### Logix indices [3] and [4] (from image below):

>>>

>>> struct.unpack('f',struct.pack('hh',-19905,16999))

(57.924068450927734,)

>>>

>>> ### Logix indices [5] and [6]:

>>>

>>> struct.unpack('f',struct.pack('hh',-18350,17065))

(84.86000061035156,)



 

​

N.B. struct.unpack(...,struct.pack(...)) is Python equivalent of Logix COP/CPS.

​

 

[drbitboy]

Could someone with a 5380 please code and run the following rung on it?

MOV 64.0 a_float    SUB a_float 4e-6 a_float     COP a_float a_two_element_INT_array[0] 2

​

Data tags are

• a_float, REAL
• a_two_element_INT_array[2], INT

Then report the two values in a_two_element_INT_array[0] and a_two_element_INT_array[1]?

The values will be 17023 and -1, but it is the order I am curious about.

Thank you.

 

[5618]

I ran the DrBB request on an L82. I expect the same behavior from 5380.

63.999996 COP'd to two INTs.

INT[0] is -1. INT[1] is 17023.

 

[5618]

Had some more fun in Logix. As parky was doing in Mitsubishi, you will need to byte swap. Here’s four possibilities. Real2 most closely represents your expected value so I expect that's the ticket. EQUs are there just for a way to see values. Not shown in my clipped screenshot are NOPs to the right if it matters.

Edit: Whoops! INTArray[5] didn’t populate with the MOV after the EQU. Fixing that makes Real4 -6.73946476e-016. Still not close to the expected value.

 

[cjjeeper]

I don't need to do byte swap. I literally posted the solution already.


Make a UDT of data type UINT and then copy the INT into the UDT.


and then copy that into a REAL

The only stopper was that the compact logix COP command did not support COP of data type UINT.


Also must have Studio version 32 or above.

 

[5618]

And I gotta make another correction. I did word swap, not byte swap. That's another possibility that could be encountered.

Any chance of mechanical destruction or bodily harm if you're wrong?

 

[drbitboy]

I don't need to do byte swap.

I understand and agree, but the code must do a word (not byte) swap; @5618's exercise in Post #35 confirms this.

It was already stated that the REAL value to be recovered within the Logix 5380 is in the pair of adjacent Modbus device Holding Registers {4}0504 and {4}0505.

If the code does not do a word swap, then that code is using the wrong word for the least-significant half of the REAL, i.e. it is most likely pairing the previous word from Modbus device Holding Register {4}0503, instead of the next word from Modbus device address {4}0505, with the most-significant half of the REAL from Modbus device Holding Register {4}0505.

If the code swaps the words, so the value of Holding Register {4}0504 is after the value of {4}0505 in the Logix array that is COPied to the Logix REAL, then that code implements a correct solution.

If the code does not swap the words, then that code does not implement a correct solution. As noted earlier, the error is less than 1%, so it might not be noticed if there is noise in the REAL value over time.

Bookkeeping.

​

 

[drbitboy]

The only stopper was that the compact logix COP command did not support COP of data type UINT.

@5618, care to do one more test, please? Summat like this:

Rungs:



    MOV -1 t_INT[0]            MOV -32768 t_INT[1] 

    COP t_INT[0] t_UINT[0] 2   EQU t_UINT[0] t_UINT[1]

    MOV 65534 t_UINT[2]        MOV 32769 t_UINT[3] 

    COP t_UINT[2] t_INT[2]     EQU t_INT[2] t_INT[3]



Data:



    t_INT[4], INT

    t_UINT[4], UINT

​

 

[drbitboy]

Whaddya know, MicroLogix 1100 is LSW-first as well.

​

 

[cjjeeper]

And I gotta make another correction. I did word swap, not byte swap. That's another possibility that could be encountered.

Any chance of mechanical destruction or bodily harm if you're wrong?

No. No chance of that.

 

[cjjeeper]

Perhaps this will help

Perhaps this will help.


I did have to order a prosoft card for the modem interface in my other post.


While I was on the phone with prosoft I specifically asked them about this issue with the UINT.



Prosoft gave me the solution with the UDT. In my experience when it comes to AB doing MODBUS there is no one that is better at it than Prosoft.



Tested it and it works.

 

[drbitboy]

Tested it and it works.

If you are not swapping the words, then I suspect 1% accuracy is good enough to not notice the error, so you will never know the difference.

Godspeed to thee.

 

[5618]

Unfortunately, many of the images in this thread are not loading for me now so I don’t have all the values I wanted to play with. Here’s a screenshot of the fun tonight.

Prosoft is excellent for Modbus integration and gives word and byte swap options in the module setup if you don’t want to swap in the PLC code.