Experimental Physics and
Industrial Control System

Thanks Andrew and Michael,

Yes the ASYN_INFO was replaced by _STATE here:
<https://github.com/epics-modules/asyn/pull/67/commits/ffb84abc46679a6e1d0479674f0dd3e2e662a4cc>

And then the thing got stuck somewhat.

The discussion about .TPRO, .DDBG has not fully settled yet,
so for the moment I will continue to use the ".SPAM" field,
until a better solution is found.

I will address the other comments, thanks Andrew.

BR
/Torsten
PS: Sorry for the spam yesterday, mailman did the trick.




On 05/02/20 18:54, Andrew Johnson via Core-talk wrote:

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 inAsyn#63 <https://github.com/epics-modules/asyn/pull/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.

References:

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

Re: Using asynPrint() from motorRecord ? Andrew Johnson via Core-talk

Navigate by Date:

Prev: My Jenkins builds fail checking out. Why? Zimoch Dirk (PSI) via Core-talk

Next: Re: My Jenkins builds fail checking out. Why? 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 

Navigate by Thread:

Prev: Re: Using asynPrint() from motorRecord ? Andrew Johnson 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