I have an application with S7-1200 CPU 1214C is communicating through CM 1241 card Modbus RTU communication with a PH/Turbidity Instrument.

The communication is done correctly and the PLC is receiving values from the instrument, but the values is too different from the values appears on the instrument screen.

The manufacturer of the instrument stated that his i device is sending the data with

"32-bit registers as “little-endian byte swap”.

The plc is receiving about 28 Bytes from this instrument, i made an unoptimized data block to store the data received from the instrument.

But as i stated the values received is too different from the actual values.

how could this problem been solved?

I think Vippi has given a valuable answer.
Swapping words may be needed.

In case you are still stuck, inform us what the raw data readings are as well as what you expect. Have the data as bytes or words displayed in the hexadecimal format.

I suggest strongly that you use software like ShareX to make proper screen captures. ZIP the images if you share more than one.

~

 Dear Einstein,

attached the modbus map of the instrument, i notices that there is a reading is been sent on byte 1 and as you said that my data block skipped byte 1 and started from byte 2 after byte 0.

i hope the attachment will help in solving my problem.

0_Einstein

A couple of quick online searches (to help you find things out on your own in the future):

"site:siemens.com s7-1200 s7-1500 endian systems manual" AND
"modbus rtu 32-bit registers as little-endian byte swap"

and you can locate these next 2 well known pieces of information:

Online searches

1. S7-1200 & S7-1500 PLCs store and retrieve data in 32-bit Little-Endian chunks (registers if you will).

2. Modbus/RTU normally sends 16-bit registers in big-endian.  So, when you see "modbus rtu 32-bit registers as little-endian byte swap", you can see how this data was a match perfectly made for Siemens S7-1200/S7-1500 PLCs.

So, if you extend that a bit, it means the data being transmitted will match perfectly with 4-byte entities in the Siemens S7-1200 PLC.  Note the instrument did not state 32-bit IEEE floating point format, so the data is being sent as an integer (of some type).

That means the value will be some scaled integer value with as many inferred decimal places as are configured in the instrument.

If you simply change the 4-byte datatype (32-bits) in MB/RTU receive DB from REAL to UDINT or DINT (depending on whether a negative value is possible, like temperature), you may be able to "see" the original values and figure out what decimal value to divide by.

Just curious what byte 0 is supposed to be since byte 1 has been skipped by the way the DB has been organized.  If you cannot visually see the instrument values, read the following very carefully and make sure you understand what you need to change.  You may have difficulty actually changing it, so if that happens, come back here and post a screenshot of the DB with online HEX values displayed (like your original REAL screenshot), and the logic you tried to use to make it work.

You may REALLY want to verify what the instrument is sending via MB/RTU.

If it is sending 1 byte followed by 4 bytes, you need to change how you receive the data.

Regardless, you will need to account for byte #1 - after offset 0.0 there is an unclaimed byte of received data. It has been lost.

I recommend changing (temporarily) to a new (non-optimized) DB for receiving data which is simply:

MB_DATA : Array [0..57] of BYTE

From there, you can see where byte 1 of Inlet Turbidity actually starts.

The 3rd & 4th bytes are likely where most of the Turbidity value are found.

Here's a simple logic check for Inlet Turbidity (assuming you have made the above DB replacement - for testing purposes (attached image) 

After implementing and testing, you will know:

1. Which byte is the first byte of inlet turbidity reading
2. What scaling factor constant value to use

From there, you can repeat something similar for each 4-byte sequence (except you will KNOW which byte is the 1st byte and will only need one Deserialize call). 

Please post your results.  I know it can be frustrating sometimes when integrating PLCs with instrumentation with unknown scaling and byte structuring. 

zaghlol

I have an application with S7-1200 CPU 1214C is communicating through CM 1241 card Modbus RTU communication with a PH/Turbidity Instrument.

The communication is done correctly and the PLC is receiving values from the instrument, but the values is too different from the values appears on the instrument screen.

The manufacturer of the instrument stated that his i device is sending the data with

"32-bit registers as “little-endian byte swap”.

The plc is receiving about 28 Bytes from this instrument, i made an unoptimized data block to store the data received from the instrument.

But as i stated the values received is too different from the actual values.

how could this problem been solved?

 

use instruction ROR to swap 

New question published by ibrahim85 is split to a separate thread with the subject Is Excessive starting time-Locked rotor available in soft starter (3RW5) or not ?.

Best regards
The Helping Hand