EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  <20202021  2022  2023  2024  Index 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  <20202021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: RE: Error (511,511)
From: Mark Rivers via Core-talk <core-talk at aps.anl.gov>
To: 'Michael Davidsaver' <mdavidsaver at gmail.com>
Cc: EPICS core-talk <core-talk at aps.anl.gov>
Date: Sun, 22 Mar 2020 18:42:52 +0000
I've solved this problem.

The issue was that when ADSpinnaker called the vendor library function EndAcquisition() that call never returned.  It did not throw an exception, it just hung.  I have seen this before, and even opened an issue with the vendor, but never received a satisfactory answer.  The recurrence of the problem may be due to changing the message queue receive with timeout logic to sending a special message.  

However, I was able to work around the problem by changing the order in which I call EndAcquisition versus shutting down my image consuming thread when stopping acquisition.  It is working fine now.

I think the error message from base was a side effect of the asyn port driver thread being hung because the vendor library function not returning.

Thanks,
Mark


-----Original Message-----
From: Michael Davidsaver <mdavidsaver at gmail.com> 
Sent: Sunday, March 22, 2020 10:59 AM
To: Mark Rivers <rivers at cars.uchicago.edu>
Cc: EPICS core-talk <core-talk at aps.anl.gov>
Subject: Re: Error (511,511)

On 3/22/20 8:53 AM, Mark Rivers wrote:
> Hi Michael,
> 
> 
> Before I got your message I got as far as figuring out that the message was from this line in errSymLib.c::errRawCopy.
> 
> 
> epicsSnprintf(pBuf, bufLength, "Error (%u,%u)", modnum, errnum);
> 
> 
> And this line in errMdef.h defines 511 to be the module Database access:
> 
> 
> #define M_dbAccess      (511 << 16) /* Database Access Routines */
> 
> How did you determine that it is recGblRecordError, and how do I track it down?

The string "PV: " doesn't appear in Base nearly as often as you might think.


> It is not an error I ever recall seeing before.

recGblRecordError() isn't often used.  The unique part is the trailing "ReadOut".
That's not in Base.


> Thanks,
> Mark
> 
> 
> 
> 
> 
> ________________________________
> From: Core-talk <core-talk-bounces at aps.anl.gov> on behalf of Michael Davidsaver via Core-talk <core-talk at aps.anl.gov>
> Sent: Sunday, March 22, 2020 10:44 AM
> To: core-talk at aps.anl.gov
> Subject: Re: Error (511,511)
> 
> On 3/22/20 8:42 AM, Michael Davidsaver wrote:
>> On 3/22/20 8:37 AM, Mark Rivers via Core-talk wrote:
>>> Error (511,511) PV: 13BMDPG1:cam1:TriggerOverlap ReadOut
>>
>> Looks like recGblDbaddrError() in Base 7.0.  Maybe called with status==-1 ?
>>
> 
> Make that recGblRecordError(), I copied the wrong name...
> 


References:
Error (511,511) Mark Rivers via Core-talk
Re: Error (511,511) Michael Davidsaver via Core-talk
Re: Error (511,511) Michael Davidsaver via Core-talk
Re: Error (511,511) Michael Davidsaver via Core-talk

Navigate by Date:
Prev: Re: C++ question (Bug in epicsMessageQueue) Michael Davidsaver via Core-talk
Next: Re: write to a single element of an array field Ben Franksen via Core-talk
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  <20202021  2022  2023  2024 
Navigate by Thread:
Prev: Re: Error (511,511) Mark Rivers via Core-talk
Next: [Bug 1868486] [NEW] epicsMessageQueue lost messages mdavidsaver via Core-talk
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  <20202021  2022  2023  2024 
ANJ, 22 Mar 2020 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·