Jacek,

please look at the attached file.

And apologize if 1008.0 >= 1008.0, you can call it revelation, or fantasy. In some other places they call it math.

Sorry but I do not have more time to make other experiment, but the attached file shows what  Iwould expect from a PLC. Unfortunately i don't have a simotion ready right now, I hope that 1200 is enough.

Ah wait, it's a 1214-F, probably it's more intelligent ?

:D Bye

jacek d

 

Davinator

 What I think is this : if systems makes a MUL_R and it gets as result 1799,99999995678, where clearly the result was 1800, it must round up it.

 Once again: "The system" is not knowing all fantasies of programmers. The result is as it is.

Davinator

I do not call fantasy that 1800 is not geq than 1800. Neither does the Simotion that is IEEE754 compliant, for him 1800 is GEQ than 1800, whatever the calculus comes from.

We are just comparing two reals, not two Riemann's Z functions ...

It is curious that nobody has still replied to the fact that in Simotion this does not happens... Maybe in motion control you need that 1800 is equal to 1800 if not you have troubles ?

Maybe :D

 

My Simotion must have been unaware of you revelations... Possibly outdated FW...

Excuse me strange variable names. Had no time to alter running machine too much.

Well, I don't know what math do you mean, but for sure it is not Finite Precision Floating Point math.

Unfortunatelly, I'm not familiar with S7-1200 and their architecture. Maybe some expert can shed some light on the results you showed us.

And unfortunatelly I don't have S7-1200 CPU at hand. But I used simulator... I hope it works well as with your SCL example it showed same results.

However try to do the same in LAD. I'd love to see screenshots. If your precious time allows for this, please also (in LAD) calculate this 1200.0*0.84-1008.0.

Notice the difference!...

Hello,

just to add another screenshoot.....

im working with schneider premium and i make same calculation with this simulator...... same result...

Best Regards

Thank you William_B and mindware for your contribution.

IMHO there's a flaw in S7-1200. Or some strange optimizations in the compiler? Nice issue to ask Siemens Support...

@Davinator: nice equipment you use, for it 1008.0-1008.0<>0.0

 Hi!

   I think that Davinator's frustration comes from the fact that when this program is monitorized, it does not inform the human that at the result of the MUL block displayed is not quite the same as what is inside the memory.

So there is some optimization done for the monitoring but that is not used further in the e.g. compare or SUB blocks.

Anyway, I think that all those who will read this discussion will learn that working with IEEE 754 real numbers needs more attention.

Kahl

So there is some optimization done for the monitoring but that is not used further in the e.g. compare or SUB blocks.

 I'm afraid that it's opposite. Pls investigate carefuly screenshots from Davinator and William_B.

jacek d

Kahl

So there is some optimization done for the monitoring but that is not used further in the e.g. compare or SUB blocks.

 I'm afraid that it's opposite. Pls investigate carefuly screenshots from Davinator and William_B.

 Opposite of what I said means: " some optimization is NOT done for the monitoring but it is DO used further", but I do not want to do hairsplitting, especially when I definitely need to make some corrections:

So there is some optimization done when monitoring in Ladder but that is not used further in the e.g. compare or SUB blocks in Ladder (referring to William_B's second LAD network).

I have to agree with you about the "strange optimization" issue.

BTW, I hope you will share us the answer from your support request. I am very curious.

Hi!

I think that Davinator's example and William_B's SCL example relates to "constant folding".

First multiplication is done during runtime while second multiplication is done during compilation.