Experimental Physics and
Industrial Control System

1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 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 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 <2021> 2022 2023 2024
<== Date ==>		<== Thread ==>

Subject:	Re: CA Gateway converts int/float value to hex
From:	"andrej.manojlovic--- via Tech-talk" <tech-talk at aps.anl.gov>
To:	"Johnson, Andrew N." <anj at anl.gov>
Cc:	tech-talk <tech-talk at aps.anl.gov>
Date:	Wed, 25 Aug 2021 18:07:26 +0200 (CEST)

 Hi Andrew,

thanks for your help. Replacing epicsScanDouble() with sscanf() does fix the
problem.

I'm not sure if this change will break any other Gateway functionality relying
on the use of epicsScanDouble(). I'll follow up with a new issue on Github.

Thanks,
Andrej 

From: "Johnson, Andrew N." <anj at anl.gov>
To: "andrej manojlovic" <andrej.manojlovic at cosylab.com>
Cc: "tech-talk" <tech-talk at aps.anl.gov>
Sent: Thursday, July 29, 2021 1:34:57 AM
Subject: Re: CA Gateway converts int/float value to hex

Hi Andrej,

On Jul 28, 2021, at 3:41 PM, andrej.manojlovic--- via Tech-talk <tech-talk at aps.anl.gov> wrote:

I've encountered a situation with CA Gateway where a `caput` to PV through

Gateway behaves differently compared to a `caput` directly to IOC, bypassing the gateway.

If I caput to an IOC (no Gateway involved):

$ EPICS_CA_ADDR_LIST=ioc_address caput x:ai 10w

The record will store the value 10. The excess 'w' character at the end is

ignored, which is OK.

However when doing the same through CA Gateway:

$ EPICS_CA_ADDR_LIST=gateway_address caput x:ai 10w

The 'w' character at the end will cause the record to store value 16 (10 hex),

which I don't expect. The 'w' is just an example and can be replaced by a

string.

Is this implicit conversion to hex known behavior when using CA Gateway? Can it

be changed to behave the same way as a caput directly to IOC behaves?

Interesting, I agree that this is strange behavior.

It is happening because caput sends the value as a string, and the gateway is apparently converting the string to a double to match the target PV before forwarding the put operation. Unfortunately the C++ code in what I assume is the gateway’s conversion
routine (in pcas/src/gdd/aitConvert.cc) looks like this:

            int j = epicsScanDouble(
pString, &ftmp );

if ( j !=
1 ) {

                    j = sscanf ( pString,"%x",
&itmp );

if ( j ==
1 ) {

                ftmp = itmp;

            }

else {

return
false;

            }

The epicsScanDouble() call returns 0 if there any extraneous characters are found in the string, and in that case the code tries again using the “%x” format, and as long as that manages to convert some of the string it accepts the hex version. An older
version of this code (pre-2004) called sscanf() with a “%lf” format instead of using epicsScanDouble(). With that version extraneous characters would not have caused the first conversion attempt to fail, so the hex conversion would not have been attempted.

The switch to epicsScanDouble() happened in this commit to the pcas module:

commit 0dc034962ccae79fd7fdcfddead52496c837014a

Author: W. Eric Norum <wenorum at lbl.gov>

Date:   Tue Oct 12 17:45:31 2004 +0000

    Use epicsScanFloat/epicsScanDouble rather than sscanf.

    This allows proper handling of Nan/Inf on all architectures.

At that time some EPICS architectures (probably Windows) didn’t convert Inf and Nan properly, so I can understand
why the change was done, but I suspect it could be undone here (the other changes in the same commit were outside of the pcas & gdd code).

At this point Ralph Lange will need to comment and decide what to do about this, and in the meantime you could undo that change, rebuild the gateway and report back whether that fixes the problem.

Thanks for the bug report!

- Andrew

-- 
Complexity comes for free, simplicity you have to work for.

References:: CA Gateway converts int/float value to hex andrej.manojlovic--- via Tech-talk; Re: CA Gateway converts int/float value to hex Johnson, Andrew N. via Tech-talk

Navigate by Date:: Prev: Re: Watlow_PM communication Mark Rivers via Tech-talk; Next: RE: Watlow_PM communication Taufer, Gary via Tech-talk; Index: 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 <2021> 2022 2023 2024
Navigate by Thread:: Prev: Re: CA Gateway converts int/float value to hex Johnson, Andrew N. via Tech-talk; Next: RE: New Radiation Monitor options [SEC=UNOFFICIAL] STARRITT, Andrew via Tech-talk; Index: 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 <2021> 2022 2023 2024

ANJ, 25 Aug 2021

· Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System