Experimental Physics and
Industrial Control System

2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 <2020> 2021 2022 2023 2024	Index	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: Using asynPrint() from motorRecord ?
From:	Andrew Johnson via Core-talk <core-talk at aps.anl.gov>
To:	<core-talk at aps.anl.gov>
Date:	Wed, 5 Feb 2020 11:54:42 -0600

Hi Torsten,

I'm not sure whether all the motor guys read core-talk, just saying...

On 2/5/20 9:02 AM, Torsten Bögershausen via Core-talk wrote:

While debugging this and that, I find more and more that
asynPrint() is a very useful feature.

Timestamps can be printed, file/line and/or the thread, all
is configurable in runtime.

Now to my question:
Is it a good idea to use it during record processing ?

Since the motorRecord does not have access to asyn directly,
all prints are fiddled through device support, which has
asyn.

In other words, this nice print works only for asynMotors
(But that restriction is OK).

This seems reasonable as long as the API added is generic and the motor app doesn't become dependent on Asyn to compile, since I believe there are still motor drivers that don't need Asyn. Your code seems to be fine with that, but I haven't tested it. Other drivers should be free to implement their own logging interface method (which is what I think this API really is) to provide similar functionality if they wish.

I have done a prototype here:
<https://github.com/tboegi/motor/commit/9aebabdf551a24bd138d483808130af57888a9e0>

Specific comments on your prototype:

I thought the flag name ASYN_TRACE_INFO was discussed and rejected in Asyn#63 back in December 2017. If I'm right introducing it through a change to the motor app doesn't seem right to me.

The method name devVprintSource() in struct motor_dset emphasizes more how it's implemented using Asyn, not what it's used for. I would recommend thinking about names more like log_vprintf(). I admit the name is mostly used inside a wrapper function inside motorRecord.cc but the name is visible to anyone writing a new motor driver.

Your change in motorDevSup.c appears to be only tangentially related to this topic, should it be extracted and applied separately?

The non-Asyn implementation of debugPrint() will no longer display the filename and line number of the message source, which used to be explicitly listed in the Debug() format string arguments. I'm not saying they necessarily need to appear, but I'm pointing out the change for those who work more closely with the motor record so they recognize and can comment on it.

Requiring a __LINE__ argument to debugPrint() without __FILE__ looks a bit strange, I might consider using a macro to hide both arguments from all those calls.

HTH,

- Andrew

-- 
Complexity comes for free, Simplicity you have to work for.

Replies:: Re: Using asynPrint() from motorRecord ? Torsten Bögershausen via Core-talk

References:: Using asynPrint() from motorRecord ? Torsten Bögershausen via Core-talk

Navigate by Date:: Prev: Re: Using asynPrint() from motorRecord ? Michael Davidsaver via Core-talk; Next: Build failed: epics-base base-integration-392 AppVeyor via Core-talk; Index: 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: Using asynPrint() from motorRecord ? Michael Davidsaver via Core-talk; Next: Re: Using asynPrint() from motorRecord ? Torsten Bögershausen via Core-talk; Index: 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 <2020> 2021 2022 2023 2024

ANJ, 06 Feb 2020

· Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System