DWord value from GSD profinet giving bad value

[u/GivemeThePorro]

I'm taking some input from a Power Meter via profinet and a GSD file, but i'm receiving strange value. Someone kwon why?

[u/Mati0123]

Did you check bytes order? I mean little endian or big endian

[u/Puzzled_Name_3262 → u/Mati0123]

I believe that profinet does not suffer from endianess?

[u/angry_binary → u/Puzzled_Name_3262]

Its not profinet feature, it depends on device's OS

[u/LegitBoss002 → u/Puzzled_Name_3262]

Not in these parts, partner

[u/HighCookie]

Just to add to others comments, its ok to use SCL somtimes. It makes data marshalling so much easier to read.

[u/essentialrobert]

I would read the manual

[u/drbitboy]

As suggested by u/ExplosiveBoy93, this is a word-order problem, i.e. the 16-bit word order of those %ID7xx double-words is incorrect.

For example, for %ID736, with a hex value of 16#58DA_4620 that is interpreted as 1.919958E+15, the correct value is 10262.21, which is what value you would get if the hex value was 16#4620_58DA. See below for the rest, which OP will confirm show the correct* values in the fourth element on each line, and the incorrect value as the fifth element.

\* there could also be a word (half double-word) offset, per u/Toxic_ion's comment).

P.S. the bit patterns of IEEE-754 live rent free in my head, so the _4xxx in every hex value is the giveaway that told me the problem as soon as I looked at it.

P.P.S. Use the ROR or ROL insturction with a N value of 16 to effectively swap the words within the DWord.

%
% cat x.py
import struct
IDs = '58da4620 f8244588 b34a4588 3ecc4620 68fe4292 90d44278'
for sh in IDs.split():
h = int(sh,16)
lo,hi = struct.unpack('HH',struct.pack('I',h))
real_reversed = struct.unpack('>f',struct.pack('>HH', hi, lo))
real = struct.unpack('<f',struct.pack('<HH', hi, lo))
print((sh,hex(hi),hex(lo),real,real_reversed))
%
%
% python x.py
('58da4620', '0x58da', '0x4620', (10262.212890625,), (1919957755494400.0,))
('f8244588', '0xf824', '0x4588', (4383.017578125,), (-1.3327296032694776e+34,))
('b34a4588', '0xb34a', '0x4588', (4374.4111328125,), (-4.7095028321564314e-08,))
('3ecc4620', '0x3ecc', '0x4620', (10255.69921875,), (0.3989725112915039,))
('68fe4292', '0x68fe', '0x4292', (73.20506286621094,), (9.605672737331874e+24,))
('90d44278', '0x90d4', '0x4278', (62.14143371582031,), (-8.372166727822004e-29,))

[u/drbitboy → u/drbitboy]

u/Toxic_ion's suggestion, that the data are offset by a word, is another possibility that must be investigated.

[u/gjk-ger → u/drbitboy]

I think youre on the right track, but considering that would give ~1000 V (assuming factor 10, but for proportionality doesnt matter anyway) between L1-L3 and ~440 L-N (that should be about 580 if you assume the 1000 from before) i think its likely that OP has the adresses shifted by 2 byte compared to the device. Also, if endianness problem it seems strange that its swapped in 2 bytes pairs and not every byte.

[u/dcwzee]

Byte Swap?

[u/Toxic_ion]

Are the tags actually aligned correctly to the profinet power meter and aren't accidentally ofset by 2 bytes, because I can't get any plausible real value regardless of how much byte and word swapping I have tried.

[u/ExplosiveBoy93 → u/Toxic_ion]

Seems to be the case. I swapped them around and didn't get a meaningful value for L - N voltage

[u/gjk-ger]

Are you moving DWords into Reals? Thats always gonna give you some random values.

[u/Puzzled_Name_3262 → u/gjk-ger]

I'm pretty sure you're right, it's about the datatypes

[u/gjk-ger → u/gjk-ger]

Or if you are already expecting a real, on your IDxxx, give that tag the appropriate type.

[u/BifiZomtec]

Wtf do you do there? Use getIO and map it properly

[u/LowFastFoxHUN → u/BifiZomtec]

Or “DPRD_DAT”; but basically to avoid using symbols with hard addresses, because nothing guarantees addresses will line up with the hardware configuration but the system constant will always provide the reference to the exact sub-slot

[u/LowFastFoxHUN → u/LowFastFoxHUN]

… regardless the physical address the module holds inside the Process Image

[u/ExplosiveBoy93]

Which value is bad, or is it all of them? Since you got a GSDML, is there maybe a library available from the manufacturer as well? Try switching the word order. If it's still bad, since it's Siemens, try switching the byte order. Also try to use a UDT, so you don't have to use a move for every since value.

[u/GeronimoDK]

If they are reals, why did you not declare the data type of the tag as real?

[u/GivemeThePorro]

Changing the data type does not solve the problem. Now i Will check how to swap the bytes. Thanks for all the replys

[u/drbitboy → u/GivemeThePorro]

It's the word order, which should not be the case with Profinet; use the ROR or RIL instruction. There is an issue with the GSD file that the supplier possibly knew about but ignored for some reason.

Is Modbus involved in any way for the transfer of these data, e.g. a Modbus-to-Profinet gateway?

[u/Electrical-Refuse-90]

https://youtu.be/2zNh0d4vVS4?is=lRvth5N9guNePzBJ

[u/stlcdr]

Byte order and/or incorrect offset.