Studio 5000: Copy Float to DINTS, Questioning the value.

[AutomationTechBrian]

I know this is something that is done all the time... I think I've used it before communicating with a VFD. But right now it's not making sense, and I don't program everyday. I'm struggling to see what has gone wrong.

Test_REAL is a Float
TEMP01 is an array of DINTS
POC is an array of DINTS

POC is a real-world thing that I'm working with. It's a communication array made of DINTS. For the REAL values, the value takes up two DINTS, but the arrangement is opposite:

TEMP01[0] gets moved into POC[1]
TEMP01[1] gets moved into POC[0]

I loaded this into the customer's PLC, feeling confident it would work as expected. The I put a place-holder REAL value with a value of "0" in the place where Test_REAL is in this example. I ended up getting -5741 for the TEMP01[0] value, and 16783 for the TEMP01[1] value. So, I came home and did the same on my CompactLogix L16ER. The value of Test_REAL is 100. Does this look right to you? (attached, below)

Then, what is the way to re-assemble the two array DINTS back to a REAL? There's something with the order of the two DINTS, but I'm just not finding it and I've run out of spare time.

 

[drbitboy]

You seem to be saying that
- Test_REAL is a floating-point balue
- Test_REAL has the same footprint as two DINTs


Since DINTs are 32 bits (4 bytes) each, Test_REAL has twice 32, or 64, bits (8 bytes).

If Test_REAL is a floating-point value, then it should be double-precision i.e. an LREAL.




Also, are you are saying that if Test_real is 100.0, then the two DINTS you get are 1120403456 and 573645373?



cf. https://literature.rockwellautomation.com/idc/groups/literature/documents/rm/1756-rm006_-en-p.pdf#%5B%7B%22num%22%3A2009%2C%22gen%22%3A0%7D%2C%7B%22name%22%3A%22XYZ%22%7D%2C52%2C704%2C0%5D also https://literature.rockwellautomati...{"num":6986,"gen":0},{"name":"XYZ"},45,604,0]






Update II

• Zero (0.0) in floating point, whether REAL or LREAL, must yield all zeros in all COPied-to DINTs.
• So if you got -5741 and 16783 as the DINTs COPied from a floating-point value, then that floating-point value was not zero (0.0),

Update I


Okay, there is at least one problem: Test_REAL should be an LREAL if it actually does take up the same space as two DINTs;



See the Python example below: the 32-bit DINT decimal value 1120403456 is 42c80000h in hex, which is the same hex sequence as the 32-bit REAL decimal value 100.0; the 64-bit LREAL decimal value 100.0 has a very different hex sequence*

% cat z.py 
import struct
temp01 = 1120403456,573645373
print('\n### {0} and {1} as hex:'.format(*temp01))
print('{0:08x} {1:08x}'.format(*temp01))
dbl = 100.0
print('\n### {0:.1f} 64-bit double-precision floating-point (Studio5000 LREAL) as hex:'.format(dbl))
print(''.join(['{0:02x} '.format(ord(s)) for s in struct.pack('>d',dbl).decode(encoding='8859')]))
print('\n### {0:.1f} 32-bit single-precision floating point (Studio5000 REAL) as hex:'.format(dbl))
print(''.join(['{0:02x} '.format(ord(s)) for s in struct.pack('>f',dbl).decode(encoding='8859')]))
print('')

% python z.py 

### 1120403456 and 573645373 as hex:
42c80000 2231223d

### 100.0 64-bit double-precision floating-point (Studio5000 LREAL) as hex:
40 59 00 00 00 00 00 00 

### 100.0 32-bit single-precision floating point (Studio5000 REAL) as hex:
42 c8 00 00 

%

* although 42c8h is identical to 4059 if the former shifted 3 bits after the initial [4] bit, to account for the 8- vs. 11-bit exponent difference between REAL and LREAL:

42c8 => 01000[COLOR=blue][B]0101[/B][COLOR=Red][B]1001[/B][/COLOR][/COLOR]000  REAL
4059 => 01000[U][COLOR=orange][I][B]000[/B][/I][/COLOR][/U][COLOR=Blue][B]0101[/B][COLOR=red][B]1001[/B][/COLOR][COLOR=black]  LREAL[/COLOR][/COLOR]
[I][B][COLOR=orange]              ^
              |
              +-- shift of 3 extra bits for LREAL exponent[/COLOR][/B][/I]

 

[plvlce]

I've never really dealt with REALs on this level, but from what you are saying the data will be coming in as 64-bit (two DINTS), is this correct?

Afaik, Logix only supports 32-bit REAL values.

Your COP then has a source of 32 bits (one REAL), but a destination of 64 (two DINT). To fill the remaining 32 bits it will simply grab whatever is next in controller memory.

If you've got a tech connect contract, see https://rockwellautomation.custhelp.com/app/answers/answer_view/a_id/36632 for some help converting from a 64-bit to 32-bit

 

[drbitboy]

To summarize, there is no way to COPy two DINTs into one REAL.


You can COPy one DINT to one REAL, or you can copy two DINTs to one LREAL.

 

[janner_10]

Without knowing the format or data type your receiving device is expecting as a SP, it's hard to offer any advice.

It's unusual anything is going to need a SP comprising of 2x DINTS.

Post a bit of the manual explaining what it needs.

 

[AutomationTechBrian]

There it is! I was supposed to use INTs, not DINTS. I knew I overlooked something simple. Thanks!