EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  <20132014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  <20132014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: RE: Delay within asyn driver (was: epicsThread)
From: Mark Rivers <[email protected]>
To: "'Ralph Lange'" <[email protected]>
Cc: EPICS Tech Talk <[email protected]>
Date: Thu, 5 Sep 2013 14:46:02 +0000
I can't think of a way to do that with the existing asyn device support.  Here is the function that actually calls the driver for an asynFloat64 output record:

static void processCallbackOutput(asynUser *pasynUser)
{
    devPvt *pPvt = (devPvt *)pasynUser->userPvt;
    dbCommon *pr = pPvt->pr;

    pPvt->result.status = pPvt->pfloat64->write(pPvt->float64Pvt, pPvt->pasynUser,pPvt->result.value);
    if(pPvt->result.status == asynSuccess) {
        asynPrint(pasynUser, ASYN_TRACEIO_DEVICE,
            "%s devAsynFloat64 process val %f\n",pr->name,pPvt->result.value);
    } else {
       asynPrint(pasynUser, ASYN_TRACE_ERROR,
           "%s devAsynFloat64 pPvt->result.status=%d, process error %s\n",
           pr->name, pPvt->result.status, pasynUser->errorMessage);
    }
    if(pr->pact) callbackRequestProcessCallback(&pPvt->callback,pr->prio,pr);
}

So it unconditionally calls callbackRequestProcessCallback ().

I guess one could write different device support where the driver modifies some field in pasynUser to indicate that callbackRequestProcessCallback() should not be called.

Could this be done using 2 records instead?  An output record that does return and complete record processing, but also an I/O Intr scanned input record that gets a callback from the driver after the delay, causing that input record to process?

Mark




-----Original Message-----
From: Ralph Lange [mailto:[email protected]] 
Sent: Thursday, September 05, 2013 8:10 AM
To: Mark Rivers
Cc: EPICS Tech Talk
Subject: Delay within asyn driver (was: epicsThread)

Hi Mark,

funny enough, Vishnu Patel (ITER) was just asking me quite exactly the
same thing.

His asyn driver is working with a timing card. He would like to have a
functionality where the first step of asynchronous processing locks the
port (a specific channel on the card), does its operation on the timing
card, and then delays the second pass of asynchronous processing for a
specific time (busy-waiting, reading timestamps from the card), while
releasing the asyn lock on the port during the delay, so that other
records can continue using that channel.

As far as I understand, returning from the asyn driver would unlock the
port, but run the completion processing of the record. Is there a way to
return from the driver (to unlock the port), but tell asyn that it
should not run the process callback of the record?

Functionally this means splitting the operation in two parts: a request
that works with the card and then returns (unlocking the port, but
leaving the record PACT=1), and a completion callback that is triggered
independently (by a separate thread that does the busy-waiting).

How would you do that?

Thanks a lot,
~Ralph


On Thu Aug 29 2013 15:16:57 GMT+0200 (CEST), Mark Rivers
<[email protected]> wrote:
> When you created your asynPortDriver did you set the ASYN_CAN_BLOCK flag?  If so, your driver will run in its own thread that asynManager created for you.  That means the loop for record 1 is running in thread.  But record 2 also needs to run in that thread, and so it must wait until record 1 is done.  All records using that asyn port driver run in that thread.
>
> If you don't set ASYN_CAN_BLOCK the problem will be much worse.  The loop will run in the thread that executes the channel access request.  This means the not only records for that port driver, but all records in the IOC can be hung up, since the channel access thread is blocked.
>
> I wonder why you are trying to do this delay in the driver?  I think it would be better to do it in the database.  You can use the "seq" record to introduce a delay.  You do a caput to the seq record, and after a delay it writes to your record 1.
>
> Mark
>
>
>
> ________________________________
> From: [email protected] [[email protected]] on behalf of Vikram Bhagat [[email protected]]
> Sent: Thursday, August 29, 2013 7:54 AM
> To: Michael Davidsaver
> Cc: [email protected]
> Subject: Re: epicsThread
>
> Hi,
>    Still i don't understand how i can implement this concept in my application.   As i am using Asyn Driver, i have used 2 different reason  in asynInt32  and for 2 record.
> asyn reason (1) delay    -> i put one loop which  read system time and compare with there time specified by value field of the PV by ->    caput  <PV name>   <value time>        if the system time is greater than <value time>   loop break and record processing complete with return value asynSuccess.
>
> asyn reason (2)  currenttime   -> read current time of the system   -> it is simple scanning  record with SCAN field of 1 second.
>
> If in project i define only one PV with any one case of above, it works fine....
> But if i use 2 PV and using both function same time, when i put delay value with $ caput <PV name> <value time>   and monitor second  PV on other terminal with camonitor    <PV name (PV reading current valu)>   the second PV read out hanged till completion of first PV complete it's delay time.
>
> Means reason (1) delay is keep execution in loop and prevent execution of other PVs   record processing.
>
> So i think i have to run loop in separate thread and kill that thread after completion of delay time and return asynSuccess.    I am using asynDriver and it is necessory to return with asynSuccess.
> Or is there any other way to do this?
>
> from https://pubweb.bnl.gov/~mdavidsaver/epics-doc/epics-devsup.html#_asynchronous_example  example i am not able to get how to do multi threading.
>
> With regards
> Vikram
>
> ________________________________
> From: Michael Davidsaver <[email protected]>
> To: Vikram Bhagat <[email protected]>
> Cc: "[email protected]" <[email protected]>
> Sent: Monday, August 26, 2013 4:22 PM
> Subject: Re: epicsThread
>
> One mechanism for accomplishing what you ask is a delayed callback based on a timer.  When coupled with asynchronous records (what the asyn module is based on) this gives a way to have long delays in record processing without locking everything up.
>
> For an example see
>
> https://pubweb.bnl.gov/~mdavidsaver/epics-doc/epics-devsup.html#_asynchronous_example
>
> Michael
>
> On 08/26/2013 04:18 AM, Vikram Bhagat wrote:
> Dear all,
>       I want to know how to create and handle EPICS thread at run time.
> In my application, i am using serial communication.   I am reading/writing data from serial port.
> I am using Asyn driver.
>
> In my application i have added one more functionality (asyn reason) to wait for user-define  time and then complete record processing.
> In this function caput <PV name> with time in seconds will wait for that much seconds (I put one loop to read system time and check that user-defined time has been reached or not) and then "return asynSuccess".
>
> This is working fine but problem now is->  the system is not processing any other record/PV  till the delay time will complete.  Means if i user requested delay time for 5 minutes--> the system will not process other reading or writing PV till 5 minutes complete.
>
> How i can handle this situation? while system is waiting for time delay other record needs to be processed and have to give values or write to the output.
>
> I think i have to create epicsThread for this delay. so it will run in separate thread and other functions can work independently. But in my case after completion of my delay i have to delete Thread ... How i can delete that Thread and make sure that my asyn driver will return asynSuccess for that delay function?
>
> Thanks & regards
> Vikram
>
>
>
>



Replies:
Re: Delay within asyn driver (was: epicsThread) Vikram Bhagat
References:
epicsThread Vikram Bhagat
Re: epicsThread Michael Davidsaver
Re: epicsThread Vikram Bhagat
RE: epicsThread Mark Rivers
Delay within asyn driver (was: epicsThread) Ralph Lange

Navigate by Date:
Prev: RE: No reply from device within 1000 ms Mark Rivers
Next: RE: assign subArray record value Mooney, Tim M.
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  <20132014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Delay within asyn driver (was: epicsThread) Ralph Lange
Next: Re: Delay within asyn driver (was: epicsThread) Vikram Bhagat
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  <20132014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 20 Apr 2015 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·