Jump to content
OMRON Forums

Modbus Float Conversion


jbeasley

Recommended Posts

When using ModbusFloatWrite to a PLC that uses the IEEE-754 Floating Point 32-bit Single Precision system for Real Numbers I seem to be loosing something. If I write from a series of P-Var's or an array depending on the number it is sometimes correct and other times wrong.

 

Power PMAC Side

P200=15.6789

P201=1000.4567

mb1(0)=4.5

mb1(1)=-10.8

 

PLC Side

MHR200:R=15.625

MHR202:R=1003.45

MHR204:R=4.5

MHR206:R=-10.75

 

Also why does Power PMAC sometimes convert the variables to something else. I'm guessing it has something to do the floating point accuracy but If i set something to -10.2 why does it then show -10.1999999999 I'm wondering if this is somehow problematic in the 64 to 32 bit floating point conversion?

 

Example:

Terminal

p300=-10.2

p300

P300=-10.1999999999999993

 

 

Thank you,

John

Link to comment
Share on other sites

  • Replies 2
  • Created
  • Last Reply

Top Posters In This Topic

Popular Days

Top Posters In This Topic

You are obviously losing precision in your data transfer. It appears that one of the 16-bit components of the 32-bit floating-point representation is getting dropped somewhere in the transfer process.

 

The first 16 bits contains a sign bit, the 8-bit exponent, and the high 7 bits of the mantissa. This appears to be making it through. (15.625 has a binary representation of 1111.101)

 

The second 16 bits contains the low 16 bits of the mantissa. This does not appear to be making it through.

 

You can see the actual data PMAC is sending in a cycle using the ModbusQuery command (PMAC as client) or the ModbusServerQuery (PMAC as server) command. This may help you pinpoint the stage in the process where the data is dropped.

 

As to Power PMAC's floating-point reporting: Most fractional values expressed in decimal format do NOT have an exact binary representation in floating-point format, so they are stored as the closest binary value. It is possible to then report them rounded back to a short decimal value (although this takes "judgement" and added calculation time), but you can get into some very nasty cases where two variables that report the same value do not evaluate as "equal" in a condition. This is VERY hard to debug. (Been there, done that...)

Link to comment
Share on other sites

Thanks Curt. You nailed it.

 

The problem had to do with the Modbus Register Layout. So in my PLC writing from PMAC to Register 200 actually writes to 201.

 

I have to position data on specific word boundary's for type casting inside the PLC. So I have to write the data into 199 from the PMAC for it to populate register 200 & 201 on the PLC. I also had to set Modbus[0].Config.ServerMode=1 for byte swapping.

 

Once I used ModbusQuery to compare the PMAC HEX to the HEX in the PLC register it was very clear.

 

This is going to be great as my previous iteration of this code on Turbo PMAC i was forced to use implied decimals which works well but is just one more thing to remember when doing calculations to exchange back and forth.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.

×
×
  • Create New...