EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  <20022003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  <20022003  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: waveform record question
From: Marty Kraimer <[email protected]>
To: Pedro Gigoux <[email protected]>
Cc: Kay-Uwe Kasemir <[email protected]>, EPICS Tech-Talk <[email protected]>
Date: Wed, 10 Apr 2002 10:17:10 -0500
I think BUSY should just be ignored for any new device support. RARM may be useful.

My guess is that both of these fields were created to support a transient recorder (TR). By TR I mean a device that when armed and triggered: samples data from an ADC, stores that values in memory residing in the TR, and after a specified number of samples generates an interrupt. Typical device support for a TR will read the TR memory when the interrupt occurs. The RARM field can be used by device support to decide if the recorder should be automatically rearmed.

I looked at the existing device support in 3.13 base that uses the busy field: devWfComet, devWfJoergerVtr1, and devWfXy566Sc. In each case it looks to me like they could have been written so that they did not need the busy field. Each of these records were written before PACT even existed so BUSY may be a evolutionary artifact.

Marty Kraimer


Pedro Gigoux wrote:


Hi Kay,

Thanks for the input. I was looking at the waveform record process()
routine and found that BUSY is used there. The following is the relevant
part of the code:

if ( pact && pwf->busy ) return(0);

status=readValue(pwf); /* read the new value */

        /* check if device support set pact */
        if ( !pact && pwf->pact ) return(0);

pwf->pact = TRUE;

[do housekeeping stuff]

	pwf->pact = FALSE;
	return (0);

Suppose that we have asynchronous device support. The first time the
record processes PACT is FALSE and readValue() is called. If the device
is not ready to send data the device support routine sets PACT=TRUE and
sets a watchdog timer to call process() in the future. Now, if for any
reason BUSY=TRUE as well, the next time process() is called it won't
call readValue(), and PACT and BUSY will remain TRUE forever. Since
readValue() is not called, no timer is set to call process again. Thus,
the record will remain in active state, but not executing. This is
exactly what I saw when I set BUSY=TRUE in my device support routine.

Regards,
Pedro.

Kay-Uwe Kasemir wrote:

Hi:

They are both "private" for your device support routine.
As far as I know, there is no predefined meaning.

You can e.g. use "busy" so that your device support
can indicate to users that it's armed, waiting for a trigger
but hasn't received one, yet.

RARM = re-arm can be used to tell your device support
that it should re-arm (wait for another trigger)
once it got data.

If you don't use them because it doesn't make
sense for your device: fine.

Thanks,
-Kay

At 03:05 PM 4/9/2002, pedro wrote:

Hi,

Could someone give me an explanation on how to use the RARM and BUSY
fields in the waveform record? Why do we need a BUSY field if we already
have PACT? I'm writing a device support routine to read a serial port
using the waveform record and I'm not sure how to use these fields. I
found that about half of the device support routines in the EPICS
distribution doesn't use them at all. The documentation doesn't say much
either.




References:
Re: waveform record question Pedro Gigoux

Navigate by Date:
Prev: Re: waveform record question Pedro Gigoux
Next: RE: ca_test bus error on solaris-sparc-gnu + fix Jeff Hill
Index: 1994  1995  1996  1997  1998  1999  2000  2001  <20022003  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: waveform record question Pedro Gigoux
Next: NAN and INF Marty Kraimer
Index: 1994  1995  1996  1997  1998  1999  2000  2001  <20022003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 10 Aug 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·