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 Index 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <2017
<== Date ==> <== Thread ==>

Subject: Re: Improved simulation mode prototype
From: Ralph Lange <ralph.lange@gmx.de>
To: Andrew Johnson <anj@aps.anl.gov>
Cc: EPICS Core Talk <core-talk@aps.anl.gov>
Date: Fri, 15 Sep 2017 22:03:23 +0200
Hi Andrew,

On Fri, Sep 15, 2017 at 8:56 PM, Andrew Johnson <anj@aps.anl.gov> wrote:

I still have a fundamental dislike of using info items to configure
simulations, because these settings can't be modified at runtime, and
because of all the extra code needed for parsing the info string values.
I discussed this with you in a private email reply on August 18th ("Re:
Q: Access to into fields") but you didn't respond.

I have three statements (four including me) for info items against yours for fields, that's why I kept the approach. But I do not care too much.

Did you look at making the two info items into fields instead? I don't
like all the extra complexity involved in using a combination of info
items and members of simpvt for storing state that you are doing.

The info fields carry only configuration. All state in is the simpvt structure.
I will probably still need the simpvt structure to store state.
Or are you suggesting to completely remove the private structure and store everything (configuration and state) in fields?
 
I would like to see a comparison of the two approaches, as I'm not
convinced that the extra code complexity is worth the memory saved by
not using regular fields.

I am not against adding fields. All my users said they don't need the settings to be run-time configurable, but it does not hurt if they are. I will try to avoid making them special(), as that would add more code.

If a new simmSCAN field is of type menuScan, to what do I have to set the default value (in the dbd) to detect the field not having been set?
I need this to not swap the SCAN periods if simmSCAN has not been set.

At least one change in recGbl.c seems to be undoing a link support
change (explicitly testing a plink->type value should be avoided in new
code to be compatible with new link types):

> -    if (!dbLinkIsConstant(plink)) {
> +    if (plink->type != CONSTANT) {
>          struct pv_link *ppv_link = &plink->value.pv_link;

However it looks like the line immediately following the changed one
hasn't been properly converted for link support anyway (it could crash
if someone makes TSEL a JSON link type). There are other similar tests
of plink->type fields which should be using the dbLink*() equivalent
routine in recGblGetTimeStampSimm() and recGblInitSimm().

Sorry. I didn't check the documentation and thought I was using the new style constructs. Will fix this.

Does the SIMPVT field always point to a struct xsimm? If so the extra()
line in the .dbd files should define it as such instead of as a void *
(I've been trying to remove void * pointer casts by introducing those
kinds of changes for several years now).

Fine. I was looking at the other ...pvt pointers and tried to be consistent. I prefer to be explicit at this point.
 
I'm getting a build failure on cross-building for MinGW (and this will
probably fail likewise on other Windows DLL builds) which doesn't occur
on the master branch:

> iocInit.obj:iocInit.c:(.text+0x198): undefined reference to `__imp_callbackInit'
> iocInit.obj:iocInit.c:(.text+0xefa): undefined reference to `__imp_callbackStop'
> iocInit.obj:iocInit.c:(.text+0xf0a): undefined reference to `__imp_callbackCleanup'
> collect2: error: ld returned 1 exit status
> ../../../configure/RULES_BUILD:288: recipe for target 'dbCore.dll' failed
> make[1]: *** [dbCore.dll] Error 1

This is triggered by the new inclusion of callback.h in recSup.h but the
fundamental problem is in src/ioc/misc/iocInit.c where dbBase.h is being
included before epicsExport.h (as well as after it, so just delete the
first copy to fix this problem).

Will do.
 
My RTEMS build fails in src/std/rec/test:

> epicsRunRecordTests.o: In function `epicsRunRecordTests':
> /local/anj/base-3.16/src/std/rec/test/O.RTEMS-uC5282/../epicsRunRecordTests.c:45: undefined reference to `simmTest'

The rec/test/Makefile is missing these two lines:

testHarness_SRCS += simmTest.c
testHarness_SRCS += simmTest_registerRecordDeviceDriver.cpp

I'm guessing you copied the regressTest example immediately above, which
is also missing those two equivalent lines and a call from the
epicsRunRecordTests.c file.

Yup, correct.
As I have neither RTEMS nor vxWorks available, I am copy-pasting and hoping for the best.
 
I think that's all for now, I haven't actually looked at or tested the
simulations at all.

Thanks a lot for the review. I will wait for your comment on the field vs. simpvt issue and do the changes.
These will not affect the simulation mode run time behavior.

Cheers,
~Ralph


Replies:
Re: Improved simulation mode prototype Andrew Johnson
References:
Improved simulation mode prototype Ralph Lange
Re: Improved simulation mode prototype Ralph Lange
Re: Improved simulation mode prototype Andrew Johnson

Navigate by Date:
Prev: Re: Improved simulation mode prototype Andrew Johnson
Next: Re: Improved simulation mode prototype Andrew Johnson
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <2017
Navigate by Thread:
Prev: Re: Improved simulation mode prototype Andrew Johnson
Next: Re: Improved simulation mode prototype Andrew Johnson
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <2017
ANJ, 15 Sep 2017 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·