Experimental Physics and
Industrial Control System

Allan Honey <[email protected]> · Wed, 15 Oct 2003 09:00:39 -1000 (HST)

> -----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

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System