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  2008  2009  2010  2011  2012  2013  2014  2015  2016  <20172018  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  <20172018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: Default value to field SCAN
From: Gabriel de Souza Fedel <[email protected]>
To: <[email protected]>
Date: Wed, 4 Jan 2017 11:19:06 -0200
Hi Andrew,

Em 03-01-2017 17:55, Andrew Johnson escreveu:
Hi Gabriel,

On 01/03/2017 12:58 PM, Gabriel de Souza Fedel wrote:
I'm having problems with a set of records without SCAN field that are
consuming a lot of CPU, and receiving this messages:

dbScan warning from '.2 second' scan thread:
        Scan processing averages 0,00 seconds (0,00 .. 0,02).
        Over-runs have now happened 283681 times in a row.
        To fix this, move some records to a slower scan rate.

dbScan warning from '.5 second' scan thread:
        Scan processing averages 0,00 seconds (0,00 .. 0,03).
        Over-runs have now happened 290049 times in a row.
        To fix this, move some records to a slower scan rate.

dbScan warning from '.1 second' scan thread:
        Scan processing averages 0,00 seconds (0,00 .. 0,03).
        Over-runs have now happened 278431 times in a row.
        To fix this, move some records to a slower scan rate.

If i remove small choices from dbd file (.1, .2 and .5 seconds) solves
the problem. Apparently the records are being created with all SCAN
values...some idea to solve this?

These symptoms are very strange; as Mark Rivers suggested those average
processing times should be larger than the nominal scan period. Please
cd to your base/src/libCom/test directory and type 'make runtests' and
report any test failures here. Also please try running the IOC with the
LANG environment variable set to "C" instead of whatever it is currently
set to in case that is causing the problem.
First, setting LANG=C stop this messages....why?

Interesting, what is your normal value for LANG?
On this machine, the LANG is "pt_BR.UTF-8". On pt_BT decimal separator is ",".

The IOC works out what scan periods to create by converting the menuScan
choice strings into a floating-point number using strtod(). It looks
like in your case the strtod() routine is not recognizing the '.'
character as the decimal separator (in the warning messages you showed
the printf() output uses ',' as the decimal separator which is what
suggested this to me) so for the sub-second periodic scan threads the
scan period is being set to 0, hence the above warnings. By setting LANG
to C you change the decimal separator that strtod() recognizes back to
'.' and now the IOC can correctly convert those fractional-second
periods into a non-zero value.
Hum! Interesting! Thank you for the explanation!

The stranger thing is this is the first time I have this problem.

You could try editing the choice strings in your menuScan.dbd file to be
",1 second" ",2 second" and ",5 second" but that solution risks
incompatibility with any .db files that use the original strings in
their SCAN field values (especially for .db files that you may use from
support modules such as synApps or Asyn).

Can you find a slightly different locale setting for LANG (or maybe just
for the LC_NUMERIC variable) that will allow both ',' and '.' to be used
as decimal separators in your language? Since none of the European EPICS
users have complained about this I suspect there may be one, but this
isn't an area that I know very much about — have any other EPICS users
already resolved this kind of problem?

For my machine, I can change LANG (or LC_NUERIC), that probably don't will cause any problem. But I will find why this happens only with this IOC.


Secondly, I ran the tests, and some errors happened (attached), but
doesn't look to be anything related to that messages.

True, that failure probably just means that the test program wasn't able
to write to the Base directories — you can ignore this.

Thank you again,

Gabriel

- Andrew


--
Gabriel Fedel
Software de Operação das Linhas de Luz
Laboratório Nacional de Luz Síncrotron – (LNLS)
Centro Nacional de Pesquisa em Energia e Materiais (CNPEM)
[email protected] | +55 (19) 3512 1226
www.lnls.cnpem.br

References:
Default value to field SCAN Gabriel de Souza Fedel
Re: Default value to field SCAN Andrew Johnson
Re: Default value to field SCAN Gabriel de Souza Fedel
Re: Default value to field SCAN Andrew Johnson

Navigate by Date:
Prev: Re: BACnet driver writing values to a device Kyle Lanclos
Next: Re: Default value to field SCAN Michael Westfall
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <20172018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: Default value to field SCAN Andrew Johnson
Next: Re: Default value to field SCAN Michael Westfall
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <20172018  2019  2020  2021  2022  2023  2024 
ANJ, 21 Dec 2017 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·