All,
we also have a device that doesn't 'digest' commands correctly if they
are sent too soon after the previous one.
The Lakeshore LS208 needs at least 2-3 seconds to switch channels and then
get a readout for that channel, however, it is perfectly well able to
process another command.
If the database isn't set up to wait (we use sequence records with delays
set) until the device is done settling, the readout is a string of hyphens
rather than a number (just like what it says on its fron panel at the time
it gets the command).
The suggestions from Rodney and from Pete Owen may work in their cases, but
they wouldn't in ours - and they may not in Damien's, I have no experience
with the power supply he was asking about.
Concerning alarms: for all I know alarms are transient. We never set fields
back after alarms occur. We use the alarm handler to send email, and don't
usually acknowledge the alarms on its user interface either - it sits
somewhere in a corner, started silenced, and is used as an engine to
generate emails.
Aloha,
Maren Purves
Porter, Rodney R. wrote:
I use drvAscii extensively, and have found that if you set up your
database with a different record for each command that the timeout
setting in devAscii handles most of the timing issues you are seeing.
(If the timeout is 10 seconds, then it will wait for up to 10 seconds
for a response before sending the next command in the buffer. No
synchronization issues because it is not the same record sending the
next command.) It also has the benefit that you can get the last value
at any time. If you set the scan rate for each of the 8 records to 10
second, you will be getting about the same scan rate as one command per
second. (I sometimes wish for 30 & 60 second scans, but haven't ever
gotten around to making the mod.)
I see very few alarms unless the device is unplugged, so haven't done
much work in that area yet. I look forward to seeing the responses to
that part of your question.
Rodney Porter
Scientific Associate - Data Acquisition
Intense Pulsed Neutron Source Division
Argonne National Laboratory
Bldg. 360, Rm. C-209
9700 S. Cass Ave.
Argonne, IL 60439
(630) 252 - 7151
(630) 252 - 4163 fax
-----Original Message-----
From: LYNCH, Damien [mailto:[email protected]]
Sent: Tuesday, October 14, 2003 7:11 PM
To: '[email protected]'
Subject: Ascii SIO and alarms questions
Hi,
I am seeking a bit of advice about using Ascii SIO
(devAscii/drvAscii/drvSerial) and also alarm acknowledgement.
This is the first time I've done a job using Ascii SIO and am kinda new
to EPICS anyway so I would like to know if there is any "accpeted
wisdom" regarding the task I want to do.
I am using Ascii SIO to handle the serial comms with a magnet power
supply. There are 8 commands that I send to the power supply which
expect a response.
Originally I had set up my database so that a different command was
being sent (via stringin records) every second. It turns out that the
power supply can't be tusted to reply within one second. Occasionally a
response from the power supply was arriving
late resulting in synchronisation being lost between the IOC and the
power supply. So what I need to do is be able to recognise when I am in
a late response situation.
Would it be a good idea to write a sequence program to implement the
sending a command every second bit, and also use it to check for Read
alarms on the stringin records to recognise late responses?
Can I easily ack alarms from a sequence program? Or, would it be a
better idea to set the ACKT fields to No for my stringin records?
Also:
- Is there a way of ack'ing alarms from the ioc shell?
- Is there a list of which alarms are transient?
I am using EPICS base 3.14.2 and snc version 2.0.4.
Thanks, Damien.
- References:
- RE: Ascii SIO and alarms questions Porter, Rodney R.
- Navigate by Date:
- Prev:
RE: Ascii SIO and alarms questions Porter, Rodney R.
- Next:
Ascii SIO and late response/synchronization faults Allan Honey
- Index:
1994
1995
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: Ascii SIO and alarms questions Porter, Rodney R.
- Next:
RE: Ascii SIO and alarms questions Owens, PH (Peter)
- Index:
1994
1995
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
|