Experimental Physics and
Industrial Control System

Andrew Johnson <[email protected]> · Wed, 4 Jan 2017 10:11:36 -0600

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

> On Wed, Jan 4, 2017 at 10:40 AM, Mark Rivers <[email protected]
> <mailto:[email protected]>> 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: [email protected]
>     <mailto:[email protected]>
>     [[email protected]
>     <mailto:[email protected]>] on behalf of Michael
>     Westfall [[email protected] <mailto:[email protected]>]
>     Sent: Wednesday, January 04, 2017 7:34 AM
>     Cc: [email protected] <mailto:[email protected]> 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 <[email protected]
>     <mailto:[email protected]><mailto:[email protected]
>     <mailto:[email protected]>>> 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
> 
> 

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

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System