Experimental Physics and Industrial Control System

Hi Guys,

On 07/28/2017 05:11 AM, Benjamin Franksen wrote:
> On 28.07.2017 11:44, Ralph Lange wrote:
>>    1. Records that have SCAN="I/O Intr" are never processed, so simulation
>>    mode does not work. Setting SIMM=YES and writing to SVAL does update the
>>    fields, but does not process the record.
>>    2. Records that have TSE=-2 (timestamp from device) will always have
>>    invalid timestamps, which do not allow using X/T graphs, archiving etc.
> 
> IIRC, there is a third issue: records that are asynchronously processed
> behave quite differently in simulation mode, in which processing is no
> longer asynchronous. I never found a way to work around this one.

>> Does anyone have an idea how to solve this, preferably in a generic way in
>> base?

I'm pretty sure the solution is going to involve device support, since
the record type can't know enough about how the device type behaves to
be able to simulate it properly. However the fixes will be different for
different record types — the aai record calls pdset->read_aai() even
when SIMM==YES at the moment, with this comment which Dirk added in 2010
(although he didn't change the behaviour):

    if (prec->simm == menuYesNoYES){
        /* Device suport is responsible for buffer
           which might be read-only so we may not be
           allowed to call dbGetLink on it.
           Maybe also device support has an advanced
           simulation mode.
           Thus call device now.
        */
        recGblSetSevr(prec, SIMM_ALARM, prec->sims);
        return pdset->read_aai(prec);
    }

This seems to be a better model to follow than the other record types,
but just making that change isn't safe since it would require all
external device support to know about it.

I briefly considered introducing a new SIMM value: It currently has
values YES/NO and the ai+bi/mbb+mbbiDirect types also support RAW. We
could add DEVICE, but that requires the user to know whether a
particular device support can handle this, and if it doesn't they will
end up talking to their hardware when they didn't mean to. No good.

Therefore we need to have the device support tell the record type that
it supports simulation, so readValue() can use that supported flag to
tell it whether to call the device in simulation mode.

Question: Might a device support want to give different values for that
supported flag for different record instances, or can we make the flag
generic to the device support? The answer to that tells me where the
flag needs to live, either in the record instance or somewhere in the
devSup (probably in the dsxt, which we can safely extend).

Actually making Base's Soft Channel device supports handle simulation of
all the missing behaviours is a different problem, but one which should
be solvable once the record type properly delegates operations to the
right level.

- Andrew

-- 
Arguing for surveillance because you have nothing to hide is no
different than making the claim, "I don't care about freedom of
speech because I have nothing to say." -- Edward Snowdon

References:

Q: Simulation mode issues Ralph Lange

Re: Q: Simulation mode issues Benjamin Franksen

Navigate by Date:

Prev: Re: Q: Simulation mode issues Benjamin Franksen

Next: Re: IOC error message on camonitor disconnect Michael Davidsaver

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: Q: Simulation mode issues Benjamin Franksen

Next: Re: IOC error message on camonitor disconnect Michael Davidsaver

Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <2017>  2018  2019  2020  2021  2022  2023  2024