The CoDeSys 2.3 sim and PLCWinNT don't seem aware of the not-a-number type. Attached to this post (in reverse order, apparently) are a few screenshots demonstrating the improper handling of NaNs by the simulator and PLCWinNT.
It seems I've forgotten my download area credentials (did I ever have them? there's no link to try to restore the password), so the most recent version I have is 2.3.9.41 and the misbehavior can be reproduced in it.>Zitat:
Are you developing a test suite for a CoDeSys compiler?
Nah, that sounds like a 3S developers' job. I'm just poking this creature with a pointy stick for fun. And I think in this particular case the runtime is to blame, not the compiler. It'd be nice to have NaNs consistently and reliably supported.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The CoDeSys 2.3 sim and PLCWinNT don't seem aware of the not-a-number type. Attached to this post (in reverse order, apparently) are a few screenshots demonstrating the improper handling of NaNs by the simulator and PLCWinNT.
Use the following code to reproduce the results:
2.3.9.40 build has Apr 16 2013 date. I will be surprised with any fixes ((
Are you developing a test suite for a CoDeSys compiler?
PS
I was wrong, 2.3.9.49 is available for download now. Have you tried it?
It seems I've forgotten my download area credentials (did I ever have them? there's no link to try to restore the password), so the most recent version I have is 2.3.9.41 and the misbehavior can be reproduced in it.>Zitat:
Are you developing a test suite for a CoDeSys compiler?
Nah, that sounds like a 3S developers' job. I'm just poking this creature with a pointy stick for fun. And I think in this particular case the runtime is to blame, not the compiler. It'd be nice to have NaNs consistently and reliably supported.
so what is the definition of a NaN.
so poking is not always giving an answer.