Experimental Physics and
Industrial Control System

[email protected] (Noboru Yamamoto) · Mon, 14 Oct 1996 10:31:53 +0900

Dear Fiends,

In Message-Id: <[email protected]>
I asked the question on RS232 support in EPICS.
> 
>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? 
> 

In the responce to my question, Mark([email protected]) and Tim (
[email protected]) suggested to use Idustry Pack RS232c module and HiDEOS
to control the module. 

This solution is quite general and promissing. 
Unfortunately, we runs EPICS on Force CPU40, on which HiDEOS may not run,
and we do not use much RS232c devices on a IOC. One IOC will
control a couple of RS232c devices. So we prefer to use serial ports on IOC.

Jeff([email protected]) and Allan ([email protected]) informed me
"drvSerial.c" written by Jeff and used in KECK observatory.

Allan wrote:
> 
>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
> 
>

Nick ([email protected]) also reported the possibilty to
use a terminal server and TCP socket to control RS232c devices. He didn't
mensiond device support/driver support routined to use this approach
in EPICS. I think it shold be possible to integrate this approach into
drvSerial.c/drvAscii.c, or am I wrong?

Nick wrote:
>Whilst on this subject, we have a piece of code written by Bret
>Goodrich at Gemini, that lurks behind a pty driver and enables you to
>connect to any serial line on any terminal server anywhere on the
>ethernet. The bit at the top of the source code says:
> 
>"This program acts as a VxWorks client for a remote terminal server.  The
>remote host may be identified by either name or IP address.  The port must
>be greater than the reserved IP port numbers (currently 1024).  A TCP socket
>is connected to the remote host and a task spawned to monitor the socket.
>A pseudo-terminal device is created to buffer input and output through
>the socket to the user.  A typical application might look like:
> 
>        hostAdd ("sim2ioc", "140.252.15.83");
>        tnetDevCreate ("/pty/tmp.", "sim2ioc", 3301);
>        fd = open ("/pty/tmp.M", O_RDWR, 0);
>        write (fd, "i\n", 2);
>        n = read (fd, buf, 1024);    "
> 
>I must admit it isn't fully tested yet, but in principle it is very
>useful for those (like us) who have a load of stupid serial devices
>distributed around the place and whose nearest ethernet is closer to
>them than their nearest IOC.
> 
>Nick
>

 That is a summary of the reponces today.  I would like express my gratefulness
to Mark, Tim, Jeff, Allan and Nick.  

 Regards,

PS:
 I unintensionally included my name coded in Japanse in the last email.
I hope it did not cause any confusion in  your mail system. Please
accept my apology.
Noboru Yamamoto
KEKB Accelerator Control Group
KEK, JAPAN
Fax:+81-298-64-0321
Tel:+81-298-64-5309
e-mail:[email protected]

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System