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  2013  2014  <20152016  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  2013  2014  <20152016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: RE: Streamdevice initialization sequence
From: Mark Rivers <[email protected]>
To: "'Christian Pauly'" <[email protected]>, EPICS Tech Talk <[email protected]>
Date: Wed, 2 Dec 2015 19:02:22 +0000
One solution would be to add the following commands to your startup script before iocInit:

asynOctetConnect("myDevice", "myPort", 0)
asynOctetWrite("myDevice", "*RST")

where "myPort" is the name of the asynIP or asynSerial port, and "myDevice" is an arbitrary name you chose.

That way you will reset the device before the @init sections are run, which happens as part of iocInit.

Mark


-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Christian Pauly
Sent: Wednesday, December 02, 2015 12:52 PM
To: EPICS Tech Talk
Subject: Streamdevice initialization sequence

Hi
I have a question regarding Streamdevice and the initialization of the 
hardware on ioc startup.
I would liko to control an Agilent 33250A Pulse generator using stream 
device.
In order to put the device in a well defined ground state on startup of 
the IOC, i would like to send a RESET command ("*RST") first.
Afterwards i would like to put the device in a well-defined initial 
configuration (which might be different then the reset state) by using 
the @init directive in different protocol functions (as described in the 
streamdevice docu).


The best would be, to have a separate protocoll function with @init 
section, which is only used for initial reset+configuration, and which 
is for sure processed before all others.

However, after some trying and reading the manual, i understand that the 
individual @init sections from different protocol functions are 
processed in a more or less random, non-defined order.

How can i make sure, that a "*RST" command is executed first, before 
later the individual protocol routines @init sections are used to read 
the device status into the control records
(here i dont care any more about the sequence)?

I dont want to shift all initialization into the db record definition 
using a initialization record ("PINI 1"), since then the individual 
@init sections, used to fill the records with the actual device status 
at startup, would be processed before the *RST command, and the records 
would not reflect the real device status at startup.


Is there any standard concept for this problem ?

Thanks for any advice,

Christian


References:
Streamdevice initialization sequence Christian Pauly

Navigate by Date:
Prev: Streamdevice initialization sequence Christian Pauly
Next: problem building msi with base-3.15.3 Jemian, Pete R.
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  <20152016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Streamdevice initialization sequence Christian Pauly
Next: problem building msi with base-3.15.3 Jemian, Pete R.
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  <20152016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 16 Dec 2015 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·