:smile:

Simulated under TIA Portal for the S7-1500..

..and then using subtraction to see the actual difference:

It is in the way the REAL data type works.. there is always some small variation to the number. That means ==R  should actually be something like..
a) V0 = V1 - V2
b) V0 > -1e-3 and V0 < 1e-3

Yeah, William, I understand what you mean.

But this "problem" is too much strange to be solved with an "approximating" workaround.

If everytime we have to compare two reals we have these doubts then it is better that Siemens tells us sumthing more... I hope that any german guy of Siemens comes here and enlight us...

(sigh) ..now you hurt my feelings.

This has nothing to do with Siemens.
It has to do with the way the REAL number is constructed and how it works.
This is the nature of the beast.

Please believe me when I say that in PC programming and embedded systems, this is always something to keep in mind when working with real numbers.

If you should work in LREAL the issue  would be in another scale..
but it will still be there.

It is important to know what digits after the decimal point is still significant and adapt accordingly. A type of rounding of the number can also be done to the significant decimal that you really need.

For the least worries it remains the best to work with integers as far sanely possible.. that comes much more natural to digital systems.

w

William,

we do not have to care on how numbers are constructed in a PLC, unless we want to make "experiments" like word/byte swapping , etc.

If Siemens says this is a Real number and Siemens says that this is another Real number and Siemens says that "CMP_R" is a command that compare two reals, well, 1804.0 must be > than 1800.0.

Otherwise there is something wrong with Reals or in the CMP_R, something that differs from mathematic, or anyway something that Siemens MUST clearly explain on manuals.

A proof of this is that for example PLCs that I use like Omron, Allen Bradley and Simotion does not have such kind of troubles, 1804.0 or 1804 is greater than 1800.0 or 1800 or 1800+/- 10^-6.

I used 1007.9 instead of 1008

I am on a project that requires REAL numbers

There are 11 ranges to set up calibrations for

All other numbers were ok except for this one

so the work around was to make it an odd range to make up for the way that Siemens constructs REAL numbers

WHAT EVER!

The REAL answer to this dilemma is that you can never use a number like 1008.0 when using Step 7 you should always use 1008.1 or 1007.9 because xxxx.0 causes these kinds of problems

Have a nice day 

Davinator

we do not have to care on how numbers are constructed in a PLC, unless we want to make "experiments" like word/byte swapping , etc.

 But you should understood what it is the "finite precision floating point number".

Davinator

If Siemens says this is a Real number and Siemens says that this is another Real number and Siemens says that "CMP_R" is a command that compare two reals, well, 1804.0 must be > than 1800.0.

A proof of this is that for example PLCs that I use like Omron, Allen Bradley and Simotion does not have such kind of troubles, 1804.0 or 1804 is greater than 1800.0 or 1800 or 1800+/- 10^-6.

I can assure you that on all of those system you will get the same results as all of them follow the same IEEE standard. (ok, there might be same bugs in inplementation like once in the Pentium processors, but this is not the case here)

Davinator

Otherwise there is something wrong with Reals or in the CMP_R, something that differs from mathematic, or anyway something that Siemens MUST clearly explain on manuals.

There's is only one "wrong" thing about "Reals" - many (most?) people get them wrong. And manuals can't cover whole knowledge one should get during education process. BTW, who reads manuals anyway...

[quote]

 But you should understood what it is the "finite precision floating point number".

[/quote]

Indeed, but in any manner 1804 is greater than 1800. Even if a float has a finite or infinite precision. That's mathematic.

[quote]

I can assure you that on all of those system you will get the same results as all of them follow the same IEEE standard. (ok, there might be same bugs in inplementation like once in the Pentium processors, but this is not the case here)

[/quote]

No Jacek, I assure you that these systems are not affected by this. For them 1804 is greater than 1800.

[quote]

There's is only one "wrong" thing about "Reals" - many (most?) people get them wrong. And manuals can't cover whole knowledge one should get during education process. BTW, who reads manuals anyway...

[/quote]

Yeah, jacek, nobody read manuals, hehe also because here in Siemens, the smalles is +200 pages long so sometimes it is scaring. But anyway, if there is something that must be learn during education process, why Siemens in the help of CMP_R says "with some reals it doesn't work" ?

Why in Simotion world 1804 is greater than 1800 ?

Hi!

You made me curious, so I also made some experiments.

Davinator

William,

we do not have to care on how numbers are constructed in a PLC, unless we want to make "experiments" like word/byte swapping , etc.

If Siemens says this is a Real number and Siemens says that this is another Real number and Siemens says that "CMP_R" is a command that compare two reals, well, 1804.0 must be > than 1800.0.

Otherwise there is something wrong with Reals or in the CMP_R, something that differs from mathematic, or anyway something that Siemens MUST clearly explain on manuals.

A proof of this is that for example PLCs that I use like Omron, Allen Bradley and Simotion does not have such kind of troubles, 1804.0 or 1804 is greater than 1800.0 or 1800 or 1800+/- 10^-6.

Call me crazy (smile).. I do read manuals.
But I will confess that retaining the information
or knowing exactly where it was written, is sometimes an issue.

I think I have read something about REAL numbers in the ControlLogix family that would have been interesting to mention here. For them the number 1800.0 is the same as 1800.0 +/- {small number}. The compare function they have is not looking at a exact match but rather close enough.

In most.. if not all.. this should be okay.

..also strange design used by ControlLogix is that smaller whole numbers are converted to 32 bit numbers. That means that you have a processing penalty when working with INT numbers. I expect that this type of processing penalty also applies to the REAL compare when thinking on how Siemens works.

With advancements in processing power.. this is not really an issue anymore.

As for some motion controllers, they actually work with whole numbers that are scaled to some real number. Internally the whole numbers are used. I do not have enough Simotion background to speak out on those.

Even though we push to have universal answers, the fact is that designers think different and approach a solution different. ("standard" network protocols as classic example). This sadly forces us as system integrators to need deeper information on what the differences are between the brands. 

..until we can convince some design manager to change his mind and abandon brand tradition. But also keep in mind - Optimal solutions only come to light when there is a difference of opinion.

I also prefer ControlLogix's way of handling REAL numbers..
but I do not like having I/O be updated asynchronise with the scan cycle.

EDIT 1: From manual of ControlLogix..