EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  <20052006  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  2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: RE: record/device support general style question
From: "Liyu, Andrei" <[email protected]>
To: Jens Rekow <[email protected]>, [email protected]
Date: Thu, 17 Nov 2005 11:06:54 -0500
Hi, Jens

	I don't understand clearly your system (LoCuM4). Sorry.

	I use dbGetField()/dbPutField() in similar way and don't use
Epics' device/driver support. You can meet one small problem - Timestamp
if your machine (accelerator) has special timing subsystem. Also you
will not meet any problem to co-exist with other device/driver in your
system.
	I suppose it is non-Epics way. Fortunately, software layer is
described in Application guide.

Good luck,
Andrei.

P.s. 	I went a little far. I haven't any device/driver support. I
start another system by separate thread(s) in st.cmd (vxWorks) and in
initHook (Windows). The system works and gets/puts data to records.
Epics doesn't know anything about the system and is responsible to move
data to clients.

-----Original Message-----
From: Jens Rekow [mailto:[email protected]] 
Sent: Thursday, November 17, 2005 10:38 AM
To: [email protected]
Subject: record/device support general style question

Hi All,

it is rather an architectural/style question that I ran into working on
the device support for a message based serial/ethernet device (yes, it
is
the LoCuM4).
Imagine there is a command that retrieves various status values binary
encoded in a string (bytes, shifted to printable characters...). I would
like to serve several PV's out of that. (It wouldn't make sense to put
so
much information in just one record, mbbi, whatsoever)!

As always there are different ways to deal with that:
Worst case that I can think of is to have AsynDriver device support for
each record, so EACH time ONE of them is processed there would be I/O
transaction at the interface for retrieving the whole status string and
the tiny bit (literally!) of interest will be extracted.

My way so far is another: There is one AsynDriver-powered record
(stringin) which retrieves and holds the status string. That value is
read
by a longin record via dbGetField() in a standard device support, which
extracts the information and distributes to all the other relevant
records
via dbPutField(). Thus these other records don't need any device/record
support implementation themselves but are set remotely. Unfortunately
this
complicates handling the alarm/invalid states of these records.

So the question is:
Would it be better to have already my AsynDriver-powered record, which
reads the status bytes, distributing the values to the different records
via dbPutField()?
Alternatively I like the idea of only one device support implementation
for several records which is flexible using the INP field as a
parameter...


Any suggestions?
What could be more 'stylish'?

Thanks in advance,
Jens



Navigate by Date:
Prev: RE: record/device support general style question Rees, NP (Nick)
Next: Re: record/device support general style question Marty Kraimer
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: RE: record/device support general style question Rees, NP (Nick)
Next: RE: record/device support general style question Owens, PH (Peter)
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 02 Sep 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·