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  <2017 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
<== Date ==> <== Thread ==>

Subject: Re: Default value to field SCAN
From: Dirk Zimoch <dirk.zimoch@psi.ch>
To: <tech-talk@aps.anl.gov>
Date: Thu, 5 Jan 2017 11:10:31 +0100
On 04.01.2017 17:11, Andrew Johnson wrote:
On 01/04/2017 08:46 AM, Michael Westfall wrote:
We have a Bancomm card that provides an 80Hz clock tick, so I see that
the 0.01 second scan rate, at least, is going to be a problem...

I'm not sure why this isn't a problem (or hasn't been noted) on our
legacy vxWorks systems... Need to do more investigation...

IIRC the Gemini distributions might have had some code somewhere that
sets the VxWorks system clock rate to 100Hz or even higher — look for a
call to sysClkRateSet(int Hz). I remember Peregrine was playing with
running it at or beyond 1KHz on one mv167 system, but that does tend to
waste lots of time counting so I'm not sure how long that experiment lasted.

- Andrew


We have a few IOCs that set sysClkRateSet(1000) in their startup script. The wasted CPU cycles counting system time are not so much of a problem. But you cannot run too many records on a ".001 second" scan rate.

Unfortunately sysClkRateSet has hardcoded limits of 10...5000. Nothing one could not hack in the startup script though. ;-)
E.g. set limit to 60000 (on PPC):
*(sysClkRateSet+8)=0x27fffff6+60000
(max 65545 Hz)
Even at 50 kHz clock rate the CPU uses < 5% for interrupts.

Calling sysClkRateSet *before* iocInit works just fine for everything in EPICS.

I only had to fix the vxWorks 5.5 DHCP client code which was so broken that it did not renew the leases any more when the sys clock rate was increased. One would think it simply renews the lease too early, but oh no...

Also have a look at your BSP if any function "cleverly" saves sysClkRateGet() in a variable at boot time like this:

LOCAL int	fei82557ClkRate = 0;
fei82557ClkRate = sysClkRateGet ();

and change it to something like this:
#define fei82557ClkRate (sysClkRateGet())

Otherwise some timeouts may be unexpectedly short.

Dirk


On Wed, Jan 4, 2017 at 10:40 AM, Mark Rivers <rivers@cars.uchicago.edu
<mailto:rivers@cars.uchicago.edu>> wrote:

    > We see these warnings too with custom scan rates of 0.01 and 0.0125 seconds.
    > The warnings are emitted even when no database is loaded, thus no records connected to these scan rates.
    > We are using EPICS 3.14.12.4 with RTEMS 4.10.2 on MVME2700.

    What is the system clock rate on this system?  On vxWorks in the US
    with the MVME2700 the default is 60 Hz.  I believe the EPICS timers
    will complete on the next clock tick.  Since your scan rates are
    less than 1/60 of a second then the actual scan time would range
    from 0 to 16.6 ms?

    Mark

    ________________________________
    From: tech-talk-bounces@aps.anl.gov
    <mailto:tech-talk-bounces@aps.anl.gov>
    [tech-talk-bounces@aps.anl.gov
    <mailto:tech-talk-bounces@aps.anl.gov>] on behalf of Michael
    Westfall [mwestfal@gemini.edu <mailto:mwestfal@gemini.edu>]
    Sent: Wednesday, January 04, 2017 7:34 AM
    Cc: tech-talk@aps.anl.gov <mailto:tech-talk@aps.anl.gov> Talk
    Subject: Re: Default value to field SCAN

    Hi,

    We see these warnings too with custom scan rates of 0.01 and 0.0125
    seconds. The warnings are emitted even when no database is loaded,
    thus no records connected to these scan rates.
    We are using EPICS 3.14.12.4 with RTEMS 4.10.2 on MVME2700.

    I was meaning to ask about this....

    On Tue, Jan 3, 2017 at 4:55 PM, Andrew Johnson <anj@aps.anl.gov
    <mailto:anj@aps.anl.gov><mailto:anj@aps.anl.gov
    <mailto:anj@aps.anl.gov>>> wrote:
    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?

    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.

    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?

    > 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.

    - Andrew

    --
    Arguing for surveillance because you have nothing to hide is no
    different than making the claim, "I don't care about freedom of
    speech because I have nothing to say." -- Edward Snowdon



    --
    Mike Westfall
    Control Systems Software Engineer

    [http://www.gemini.edu/images/GeminiLogo_4.5in_newSmall.png
    <http://www.gemini.edu/images/GeminiLogo_4.5in_newSmall.png>]




--
Mike Westfall
Control Systems Software Engineer




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
Re: Default value to field SCAN Michael Westfall
RE: Default value to field SCAN Mark Rivers
Re: Default value to field SCAN Michael Westfall
Re: Default value to field SCAN Andrew Johnson

Navigate by Date:
Prev: RE: Installing areadetector on raspberry-pi2 OS raspbian pixels avanish
Next: RE: Installing areadetector on raspberry-pi2 OS raspbian pixels Mark Rivers
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
Navigate by Thread:
Prev: Re: Default value to field SCAN Andrew Johnson
Next: Re: Question about CSS Data Browser plot Kasemir, Kay
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
ANJ, 14 Feb 2017 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·