EPICS Home EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

Format page
for printing


Search Tech-talk
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: Problem with TSE="-2" records
From: Mark Rivers via Tech-talk <[email protected]>
To: 'Eric Norum' <[email protected]>
Cc: Andrew Johnson <[email protected]>, Joao Afonso via Tech-talk <[email protected]>
Date: Thu, 7 Feb 2019 22:09:04 +0000

Have you tried setting ASYN_TRACE_WARNING on that asyn port?  It will tell you if you got a ring buffer overflow, which seems unlikely but is worth checking.

 

Mark

 

 

From: Eric Norum <[email protected]>
Sent: Thursday, February 7, 2019 3:50 PM
To: Mark Rivers <[email protected]>
Cc: Andrew Johnson <[email protected]>; Joao Afonso via Tech-talk <[email protected]>
Subject: Re: Problem with TSE="-2" records

 

O.K.

I added two more columns to the display.  The columns are now:

  1. Offending PV name
  2. Offending PV timestamp (POSIX)
  3. Name of PV whose callback started this acquisition cycle
  4. Timestamp of PV whose callback started this acquisition cycle (all PVs in the cycle should have exactly this timestamp)
  5. Difference between the two timestamps in seconds
  6. Difference between the two timestamps converted back to MRF ticks
  7. Offending PV nanoseconds field (in hex)
  8. Timestamp nanoseconds (in hex) of PV whose callback started this acquisition cycle

 

Nothing really stands out.  They just seem mangled.  Sometimes even the most significant byte.

 

Fairly reliably all three scalar values that I’m monitoring from a particular BPM show up as bad— and with the same bad value.  Could it be that something inside EPICS (client or server) is occasionally getting the time from something other than the record timestamp?????

 

SR06C:BPM4:SA:X 1549576111.51139688  SR03C:BPM6:ADC0:rfMag 1549576111.53667688  -0.025279999 -3157737.288   1E7B4D38 1FFD0BEC

SR06C:BPM4:SA:Y 1549576111.51139688  SR03C:BPM6:ADC0:rfMag 1549576111.53667688  -0.025279999 -3157737.288   1E7B4D38 1FFD0BEC

SR06C:BPM4:ADC0:rfMag 1549576111.51139688  SR03C:BPM6:ADC0:rfMag 1549576111.53667688  -0.025279999 -3157737.288   1E7B4D38 1FFD0BEC

SR03C:BPM5:SA:X 1549576126.10589290  SR12C:BPM8:ADC0:rfMag 1549576126.10493994  0.00095295906 119034.593   064FCE53 064143A9

SR03C:BPM5:SA:Y 1549576126.10589290  SR12C:BPM8:ADC0:rfMag 1549576126.10493994  0.00095295906 119034.593   064FCE53 064143A9

SR03C:BPM5:ADC0:rfMag 1549576126.10589290  SR12C:BPM8:ADC0:rfMag 1549576126.10493994  0.00095295906 119034.593   064FCE53 064143A9

SR11S:IDBPM4:SA:X 1549576129.69702196  SR02S:IDBPM2:ADC0:rfMag 1549576129.69711995  -9.7990036e-05 -12239.984   298BB6B3 298D36FA

SR11S:IDBPM4:SA:Y 1549576129.69702196  SR02S:IDBPM2:ADC0:rfMag 1549576129.69711995  -9.7990036e-05 -12239.984   298BB6B3 298D36FA

SR11S:IDBPM4:ADC0:rfMag 1549576129.69702196  SR02S:IDBPM2:ADC0:rfMag 1549576129.69711995  -9.7990036e-05 -12239.984   298BB6B3 298D36FA

SR05C:BPM8:SA:X 1549576142.46080399  SR03C:BPM5:ADC0:rfMag 1549576142.46929693  -0.0084929466 -1060858.209   1B7751E0 1BF8E9A1

SR05C:BPM8:SA:Y 1549576142.46080399  SR03C:BPM5:ADC0:rfMag 1549576142.46929693  -0.0084929466 -1060858.209   1B7751E0 1BF8E9A1

SR05C:BPM8:ADC0:rfMag 1549576142.46080399  SR03C:BPM5:ADC0:rfMag 1549576142.46929693  -0.0084929466 -1060858.209   1B7751E0 1BF8E9A1

SR02C:BPM3:SA:X 1549576176.92789292  SR03C:BPM5:ADC0:rfMag 1549576176.99409699  -0.066204071 -8269583.616   374E8964 3B40BA8E

SR02C:BPM3:SA:Y 1549576176.92789292  SR03C:BPM5:ADC0:rfMag 1549576176.99409699  -0.066204071 -8269583.616   374E8964 3B40BA8E

SR02C:BPM3:ADC0:rfMag 1549576176.92789292  SR03C:BPM5:ADC0:rfMag 1549576176.99409699  -0.066204071 -8269583.616   374E8964 3B40BA8E







On Feb 7, 2019, at 1:20 PM, Mark Rivers via Tech-talk <[email protected]> wrote:

 

If you look at the timestamp .nsec field as an integer can you tell if the difference is always in specific bits (low order 8-bits or 16-bits for example)?

 

-- 
Eric Norum
[email protected]



 

References:
Problem with TSE="-2" records William Norum via Tech-talk
RE: Problem with TSE="-2" records Mark Rivers via Tech-talk
Re: Problem with TSE="-2" records Eric Norum via Tech-talk
Navigate by Date:
Prev: Re: Problem with TSE="-2" records Eric Norum via Tech-talk
Next: trying to find information on mvme5100 battery Maren Purves 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: Problem with TSE="-2" records Eric Norum via Tech-talk
Next: trying to find information on mvme5100 battery Maren Purves 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, 07 Feb 2019 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·