EPICS Home

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

Replies:
RE: Problem with TSE="-2" records Mark Rivers via Tech-talk
References:
Problem with TSE="-2" records William Norum via Tech-talk
RE: Problem with TSE="-2" records Mark Rivers via Tech-talk
Navigate by Date:
Prev: RE: Problem with TSE="-2" records Mark Rivers via Tech-talk
Next: RE: Problem with TSE="-2" records Mark Rivers 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 Mark Rivers via Tech-talk
Next: RE: Problem with TSE="-2" records Mark Rivers 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