EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

<19941995  1996  1997  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 <19941995  1996  1997  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: Re: sending strings to subrecords/device layer
From: [email protected]
Date: Thu, 30 Jun 94 15:04:58 -0500
hill>You could write new device support for the string out record.
hill>I have heard that John Winans at APS is working on raw string
hill>to GPIB support. I dont know if this has been done as string
hill>out rec device support. Also, if you havent looked in the share/src/devOpt
hill>directory then this is the place to start if you are adding a new GPIB
hill>device. Hopefully this is present in your source.

There has been an interest expressed in doing something like this, but
it got twisted in a few off-line meetings I have had with a few people.

At this moment, I am doing nothing of this sort.  We have higher
priority things in the bitbus area that need fixing.  If and when I
start writing this string-oriented GPIB support it will probably come
out like Mark Rivers described at the June EPICS meeting.  That is, it
will end up being a new record that looks like a stringin/out record
with a few extra fields that hold the device and link addresses so that
they can be set/changed at run time.  If we had writable links, I
expect the regular string records would serve his purpose.

As far as raw strings and GPIB stand RIGHT NOW, you may create a
stringout record and write a simple device support module for it using
the GPIB library that simply sends the string value to the device
specified in the link field... perhaps I will write it myself and add
it to the devOpt directory as an example since the only ones in there
now are comparably quite complicated... no promises when, but it sure
sounds like a reasonable thing for me to do circa 3.12.

--John

Navigate by Date:
Prev: Re: Channel access Jeff Hill
Next: Solaris and EPICS mcgehee
Index: <19941995  1996  1997  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: Channel access Jeff Hill
Next: Solaris and EPICS mcgehee
Index: <19941995  1996  1997  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 ·