> -----Original Message-----
> From: "LYNCH, Damien" <[email protected]>
> To: "'[email protected]'" <[email protected]>
> Subject: Ascii SIO and alarms questions
> Date: Wed, 15 Oct 2003 10:11:18 +1000
> MIME-Version: 1.0
> List-Help: <http://www.aps.anl.gov/epics/tech-talk/index.php>
>
> 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.
>
As Rodney Porter stated, altering the timeout value may be all that is
required to alleviate the late response situation. The timeout can be
altered via a 'special' longout drvAscii record of the form:
field(OUT,"@your-link-spec-here <timeout>")
What is the pedigree of the drvAscii code you are using?
If the code is version 2.0 (august 2002) or more recent then it has
been modified such that loss of synchronization will cause the late
data to be 'dropped on the floor', hence, the next record to process
will NOT get the old data. That is, data stream synchronization will
not be lost but semaphore synchronization will be lost, albeit,
semaphore sychronization will be re-established on the next write
(and at the same time any late data will be discarded).
If you are using an older version of drvAscii then data stream
synchronization can be lost indefinitely!
To obtain a new version of drvAscii set your URL to:
ftp://ftp.keck.hawaii.edu/
the folders to descend into are pub, epics, drivers, drvAscii
I recommend v2.2 (as it has a few bug fixes)
========================================================================
What follows is a dscription of how to generate output from within
drvAscii for assisting in trouble-shooting.
To examine the streams of data to/from the remote device you can use
the 'special' debug record. Again a longout drvAscii record of the form:
field(OUT,"@your-link-spec-here <debug>")
If you set the debug record to a non-zero value then all data sent by
the putFrame routine and all data received by the getFrame routine will
be printed to the Vxworks shell. An example, requesting the current
position from a Compumotor controller, follows:
field(OUT,"@/tyFs2/0/2 <debug>")
field(INP,"@/tyFs2/0/2 <1PR><%2t1PR%d>")
caput k1:dcs:sec:ax:debug 1
drvAscii(4) => 1PR[13]
drvAscii(16) <= 1PR[13]+0000176280[13]
Note that all non-ascii bytes will be displayed as integers enclosed
in brackets.
The debug flag is a bit mask but only uses 0x1 and 0x8. When the flag
has been OR'd with 0x8 a dump of the internal details of the
stream formats is displayed. This is essentially only useful to someone
who is very familiar with the code, however the 'parsed' prompt and
response format strings are displayed
field(INP,"@/tyFs2/0/2 <4IS><%2t4IS%9b%*d>")
caput k1:dcs:sec:ax:debug 8
cmndPrompt=4IS
cmndFormat=%2t4IS%9b%*d
<and a whole lot more output follows>
Note that a 'debug' record can exist for each link connected to a
remote device and, hence, can be used to generate info for a
specific link/device.
In addition, the global variable drvAsciiDebugLevel can be used to
generate more details from within the drvAscii code. If that variable
is set to 64 (the variable functions as a bit mask) then a trace of all
functions calls will be displayed in realtime.
Unforutunately, if drvAscii is used for multiple remote devices
then the drvAsciiDebugLevel will affect all connected links
(i.e. the output could get confusing if multiple remote devices are
in use).
cheers,
Allan
- Navigate by Date:
- Prev:
Re: Ascii SIO and alarms questions Maren Purves
- 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
- Navigate by Thread:
- Prev:
Re: ChannelArchiver build problem with g++ 2.9.5 on Linux Kay-Uwe Kasemir
- Next:
JCA2.0.1 Available Eric Boucher
- 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
|