EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  <20082009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  <20082009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: floating point problem in CA?
From: Maren Purves <[email protected]>
To: Rok Šabjan <[email protected]>
Cc: EPICS Techtalk <[email protected]>
Date: Thu, 28 Feb 2008 07:02:20 -1000 (HST)
Hi Heinrich (and Rok),

I remember seeing this on one architecture (don't remember what it
was, it was about 8-10 years ago), only for doule precision types
(ai is/was double), and we got around it by converting to strings.
CA is very good about the conversion, so this never turned into
a problem (the application may still be running like that, I
don't remember what it was and whether we still have the device)

HTH,
Maren

On Fri, 29 Feb 2008, Rok ?abjan wrote:

Hi Heinrich,

I remember this problem as we had it in 2004. I remember that we were not able to solve it, but it did not occur if we used a command-line client that wrapped the CDEV library. At that time I did not care about that, but it may help if you want to track down the problem.

Regards,
Rok


On 28.2.2008, at 23:51, Heinrich du Toit wrote:


Hi

This is weird and I'm not really sure how to track it down.

I have an embedded ARM board. I've compiled EPICS onto that.

I run vlinac (just to get something ) on my host PC (x86)

Then I take an ai variable. (in other words a floating point thing)

If I say from the ARM board caput  pvname value
Then the correct value gets into the pv on my host pc.
But.. the wrong value gets back via channel access.
if I caget the value I get the wrong answer.

It seems that the network byte order is done wrongly maybe.. I'm not sure.
If I put 1.0
and then get again I get: 5.29981e-315

Which is almost like the wrong network byte order but not exactly it seems.
It could be that somewhere along the lines something thinks double is 6 bytes only (rather than 8) and then also swaps the byte order.


Maybe there is an htons or something missing somewhere in the code?
But how this is possible baffles me. :/

I've written a small program to test the structure and layout off "double"
From [email protected] Thu Feb 28 16:38:18 2008
Received: from epics.aps.anl.gov (zora.aps.anl.gov [164.54.10.60])
by o2.aps.anl.gov (8.13.8+Sun/8.12.9) with ESMTP id m1SMcI0A002994
for <[email protected]>; Thu, 28 Feb 2008 16:38:18 -0600 (CST)
Received: from zora.aps.anl.gov (localhost [127.0.0.1])
by epics.aps.anl.gov (8.13.8+Sun/8.12.9) with ESMTP id m1SMZNDR029862;
Thu, 28 Feb 2008 16:35:24 -0600 (CST)
Received: from herald.aps.anl.gov (herald.aps.anl.gov [164.54.50.61])
by epics.aps.anl.gov (8.13.8+Sun/8.12.9) with ESMTP id m1SH2fot005792
for <[email protected]>;
Thu, 28 Feb 2008 11:02:41 -0600 (CST)
Received: from aps.anl.gov (hestia.aps.anl.gov [164.54.98.20])
by herald.aps.anl.gov (8.13.7/8.13.7) with ESMTP id m1SH1thE009602
for <[email protected]>; Thu, 28 Feb 2008 11:01:55 -0600 (CST)
Received: from ([128.171.90.17])
by hestia.aps.anl.gov with ESMTP id 4440338.11519070;
Thu, 28 Feb 2008 11:02:21 -0600
Date: Thu, 28 Feb 2008 07:02:20 -1000 (HST)
From: Maren Purves <[email protected]>
To: =?ISO-8859-15?Q?Rok_=A6abjan?= <[email protected]>
Subject: Re: floating point problem in CA?
In-Reply-To: <[email protected]>
Message-ID: <alpine.LRH.1.00.0802280658240.1201@vb>
References: <[email protected]>
<[email protected]>
User-Agent: Alpine 1.00 (LRH 882 2007-12-20)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-esp: ESP<6>= RDNS:<0> SHA:<0> UHA:<6> BAYES:<0> SenderID:<0> DKIM:<0> TS:<0> SIG:<dNmpVi11AUGe0lxhHlWDZv-FksLSZQs__PGVYstSI8WyxSoPMWqzsu9TrqkT
ghNobx-BiEfpwGHoyZb3obys6uzanfB6gyHVlyP1DHJ55fQUpUV-hJ23qte4
Px84pBzq0zxVxH5mrMYr_JlIhjFRb7O772c3XgB2CkJ3Ku0uKjygz97xVGbQ
AbJ12qp8X9PNEAm0i8NkrzCTkAsBtHpRewKSkbOOFOwVDlcNA> DSC:<0> TRU_marketing_spam: <0> TRU_money_spam: <0> TRU_cn_political: <0>
TRU_cn_entertainment_spam: <0> TRU_cn_business_spam: <0>
TRU_scam_spam: <0> TRU_cn_profanity_spam: <0> TRU_adult_spam: <0>
TRU_stock_spam: <0> TRU_phish_spam: <0> TRU_jp_misc_spam: <0>
TRU_watch_spam: <0> TRU_cn_misc_spam: <0> TRU_profanity_spam: <0>
TRU_jp_adult_spam: <0> TRU_medical_spam: <0> TRU_cn_class_ad: <0>
TRU_html_image_spam: <0> TRU_legal_spam: <0>
TRU_embedded_image_spam: <0> TRU_misc_spam: <0> TRU_lotto_spam: <0>
TRU_cn_scam_spam: <0> URL Real-Time Signatures: <0>
X-Spam-Status: No, score=-500.0 required=500.0 tests=FROM_HESTIA,
UNPARSEABLE_RELAY autolearn=unavailable version=3.1.3
X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on herald.aps.anl.gov
Cc: EPICS Techtalk <[email protected]>
X-BeenThere: [email protected]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: EPICS Mailing List <tech-talk.aps.anl.gov>
List-Unsubscribe: <http://www.aps.anl.gov/mailman/listinfo/tech-talk>,
<mailto:[email protected]?subject=unsubscribe>
List-Post: <mailto:[email protected]>
List-Help: <mailto:[email protected]?subject=help>
List-Subscribe: <http://www.aps.anl.gov/mailman/listinfo/tech-talk>,
<mailto:[email protected]?subject=subscribe>
Sender: [email protected]
Errors-To: [email protected]


Hi Heinrich (and Rok),

I remember seeing this on one architecture (don't remember what it
was, it was about 8-10 years ago), only for doule precision types
(ai is/was double), and we got around it by converting to strings.
CA is very good about the conversion, so this never turned into
a problem (the application may still be running like that, I
don't remember what it was and whether we still have the device)

HTH,
Maren

On Fri, 29 Feb 2008, Rok ?abjan wrote:

Hi Heinrich,

I remember this problem as we had it in 2004. I remember that we were not able to solve it, but it did not occur if we used a command-line client that wrapped the CDEV library. At that time I did not care about that, but it may help if you want to track down the problem.

Regards,
Rok


On 28.2.2008, at 23:51, Heinrich du Toit wrote:


Hi

This is weird and I'm not really sure how to track it down.

I have an embedded ARM board. I've compiled EPICS onto that.

I run vlinac (just to get something ) on my host PC (x86)

Then I take an ai variable. (in other words a floating point thing)

If I say from the ARM board caput  pvname value
Then the correct value gets into the pv on my host pc.
But.. the wrong value gets back via channel access.
if I caget the value I get the wrong answer.

It seems that the network byte order is done wrongly maybe.. I'm not sure.
If I put 1.0
and then get again I get: 5.29981e-315

Which is almost like the wrong network byte order but not exactly it seems.
It could be that somewhere along the lines something thinks double is 6 bytes only (rather than 8) and then also swaps the byte order.


Maybe there is an htons or something missing somewhere in the code?
But how this is possible baffles me. :/

I've written a small program to test the structure and layout off "double" on both my PC and the ARM. it seems identical to me.

If anybody has any idea how I can "check" this or try and find the problem it would be help full.
I am aware that the problem is not necessarily in epics but could be in the compiler options or something like that.



thanks -Heinrich


on both my PC and the ARM. it seems identical to me.

If anybody has any idea how I can "check" this or try and find the problem it would be help full.
I am aware that the problem is not necessarily in epics but could be in the compiler options or something like that.



thanks -Heinrich



References:
floating point problem in CA? Heinrich du Toit
Re: floating point problem in CA? Rok Šabjan

Navigate by Date:
Prev: Re: floating point problem in CA? Rok Šabjan
Next: RE: floating point problem in CA? Glen Wright
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  <20082009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: floating point problem in CA? Rok Šabjan
Next: RE: floating point problem in CA? Glen Wright
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  <20082009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 02 Sep 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·