EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

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

Subject: EPICS 3.13
From: Ric Claus <[email protected]>
To: [email protected]
Cc: [email protected]
Date: Tue, 08 Oct 1996 15:49:25 -0700
I've just moved my stuff from R3.12.2 to R3.13.0Alpha5 (nobody's had the 
time to install the latest beta version yet).  In modifying my 3.12 gdct 
generated databases with the latest free_gdct under 3.13, I see that my 
forward links get some varying number of 'P's appened to them:

grecord(p2RfGvf,"rf:gvf")
{
        field(FLNK,"rf:gvf:intState.PROCPPPPPPPPPPPPPPPP")
                                        ---------------- <-- doesn't
belong
        field(OUT,"#V0 C3 S0 @(null)")
        field(IMSK,"0xff")
        field(DSPE,"/rf/opi/dsp1600/gvf/dsp")
        field(AMP,"32000")
        field(E0CF,"/rf/opi/tbl/gvfEqCoefs0.tbl")
        field(E1CF,"/rf/opi/tbl/gvfEqCoefs1.tbl")
        field(FO,"483.968")
        field(RFIL,"/dat/gvfRcrdMem.dat")
        field(PFIL,"/rf/opi/tbl/gvfPlayMem.tbl")
}

I'm not sure what action causes this, but the number of 'P's appended
grows with time.

Additionally, gdct and free_gdct produce numerous seemingly random 
segmentation faults.

In the past, while not being entirely clear on the concept I used dm 
message buttons to trigger bo record processing by writing one of the
two enumerated type values to the record .VAL field with the "press 
message" (e.g., 1 or 0, in this case).  This worked fine before I went 
to 3.13.  With 3.13 this fails and dm emits the message:

CA Exception was: Could not perform a database value put for that
channel
CA Channel was rf:gvf:getRcrdBuf
Context was: detected by: PEPIIRF10.SLAC.Stanford.EDU for:
rf:gvf:getRcrdBuf
When op=1 type=0 count=1

which doesn't mean anything to me.  Steph and I found we could fix the 
problem by using the enumerated type name (e.g., "On" or "Off", in this 
case) as the press message and things would work again.  However, if the 
enumerated type name has blanks in it, things don't work.  As far as I
can tell, there is nothing to prevent defining enumerated type names 
with blanks in them.  Is this an intended change in behavior?

	Thanks,
		Ric

-- 

	Ric Claus	([email protected], (415) 926-2697)


Navigate by Date:
Prev: Re: A multiway switch record for the new switchable links. Ned Arnold
Next: Re: A multiway switch record for the new switchable links. Nick Rees
Index: 1994  1995  <19961997  1998  1999  2000  2001  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: A multiway switch record for the new switchable links. Tim Mooney
Next: Should ai, ao records have RAWH, RAWL? Marty Kraimer
Index: 1994  1995  <19961997  1998  1999  2000  2001  2002  2003  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 ·