Re: [Question] Rs232c in EPICS

[ahoney@keck.hawaii.edu (Allan Honey)]

> From noboru.yamamoto@kek.jp Fri Oct 11 01:14:57 1996
> Date: Fri, 11 Oct 1996 20:15:11 +0900
> To: tech-talk@aps.anl.gov
> From: noboru.yamamoto@kek.jp (Noboru Yamamoto)
> X-Sender: yamamoto@kekvax.kek.jp (Unverified)
> Subject: [Question] Rs232c in EPICS
> Mime-Version: 1.0
> Content-Type> : > text/plain> ; > charset=iso-2022-jp> 
> X-Mailer: Eudora-J(1.3.7-J12)
> Content-Length: 558
> 
> Dear Friends,
> 
>  Some of EPICS users in KEKB project want to control their device through
> RS232 serial link via EPICS. I'm looking at base/src and found that 
> drvRs232.c/drvMsg.c pair support Rs232c link based on messaging scheme 
> similar to GP-IB support. 
>  Is it the best (existing) way to support a device which speaks rs232c in EPICS?
> Or do you suggest a better way? 
> 
> Noboru Yamamoto
> KEKB accelerator Control Group
> KEK, JAPAN
> $B9b%(%M%k%.!<J*M}3X8&5f=j(B
> $B2CB.4o8&5fIt(B
> $B;3K\>:(B
> Fax:0298-64-0321
> Tel:0298-64-5309
> e-mail:noboru.yamamoto@kek.jp
> 
> 

We have a body of code that Jeff Hill wrote for us. He was aware of the 
drvRs232.c/drvMsg.c stuff and decided not to use it. I forget what the 
technical issues are here.

Instead, Jeff wrote a generic layer of software called drvSerial, which
uses the standard vxWorks driver interface and can therefore use any serial
port for which a vxWorks driver exists (given it supports all the standard
ioctl()s). 

We have also created device/driver support, which we call drvAscii, that 
is layered on top of drvSerial. drvAscii provides device and driver 
support for ao, ai, bo, bi, mbbo, mbbi, longin, logout, stringin and
stringout records (the stringin and out processing probably requires more 
testing yet). This driver is useful for remote devices which communicate in 
printable ascii streams (only leading non-printable chars can be handled 
via a kill/discard syntax, explained below).

The comms specification is defined in the PARM field:
	<serial stream name><command format><command response format>
			    <readback prompt format><readback response format>

	where the readback specs are relevant to outputs for which an 
	initial value can be obtained, that is, where the remote device
	can be queried for previously set output values (useful for
	bumpless reboots).

One example is an analog output record for a Keithley Metrabyte serial->
discrete i/o device:
	@/tyFs2/0/1 <$1DO%02x><%k*>

	- the /tyFs2/0/1 is the name for a serial port on a Force Sio-2
	board for which a Vxworks driver is installed.
	- the output command string to the device is '$1DO' followed by
	2 hex bytes. The analog value is sprintfed into this string
	which is then transmitted (I know everyone is going to ask how
	the analog double is converted to hex, a detail I will not 
	explain here).
	- the device eventually responds with 2 bytes: a NULL and an
	asterisk. As a NULL byte causes havoc when using sscanf, said 
	byte is ignored by the '%k' syntax, which effectively means 
	kill 1 character before processing the string. The kill syntax 
	is actually '%nk' where 'n' can be any integer. However kill can 
	only be used for leading characters.

Another example is an analog input record for a Daytronic Data acquisition 
system: 
	@/tyFs2/0/3 <CHN13><013,%f>

	- the device is prompted with 'CHN13', which tells the remote
	device to return the current value of its channel 13.
	- the device eventually responds with the channel number, a comma
	and the value of that channel.

All record processing is asynchronous thus there must be a timeout value
associated with the command/response cycle. The timeout has a default
which can be modified via a record with the special PARM field string
<timeout>.

All commands have a termination string which defaults to CRLF, as do all
responses. These can be modified, again with special PARM field strings
<writeCmt> and <readCmt>. Note that, currently, the termination strings
affect all strings on a given serial port (eventually I will modify this
so one can specify <writeCmt> and <readCmt> on a record by record basis,
similarly for <timeout>). Unfortunately, I discovered yesterday that 
dynamic modification of the termination strings was not completed - I
found that one cannot embed " or \ in the PARM field as they are stripped
off, so it is not simple to specify control characters such as CR or LF
thus, unless someone has a better idea, hex notation (0x) will be 
required (I will do this ASAP) such that a PARM field might be
'@/tyFs2/0/3 <writeCmt><0xa>'. 

Okay, I will mention the double->hex->double conversion mechanism: you 
guessed it, another special PARM field string which affects all analog 
conversions on the given serial port (again I will change this for record
by record specification). The string is <slope>, which is probably
misnamed, the driver multiplies a received analog input by the 'slope'
to generate an integer which is returned to device support which, in 
turn, sets RVAL to that value. For instance the Daytronics DAQ, from 
the previous example, returns floating point strings with two decimal
places so, in the associated data base, there is another record whose
PARM field is '@/tyFs2/0/3 <slope>' and whose VAL field is set to 100.
Thus RVAL for an input channel whose remote value is 1.23 would be 123
or 0x7b. I did not make the string <precision> as it could be used in
other ways.
 
I alluded to the fact that stringin and stringout need more testing because
there is the possibility that a prompt to a device may return multiple
strings and/or a very long string (ie. longer than can be stored in a
stringin record). The driver currently would not properly handle this
situation. This may be a case for a remote device specific device/driver
support layered on top of drvAscii, that is, this driver cannot handle
all ascii devices but a simple device specific layer on top may be readily
developed.

Allan