Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017 
<== Date ==> <== Thread ==>

Subject: Re: A couple of drvAsyn/devGpib questions
From: Marty Kraimer <mrk@aps.anl.gov>
To: "LYNCH, Damien" <dly@ansto.gov.au>
Cc: tech-talk@aps.anl.gov
Date: Fri, 06 Jan 2006 07:46:27 -0600
LYNCH, Damien wrote:

Hi,

I have a serial device that I need to communicate with but I am not sure if I can use drvAsyn/devGpib to handle it. I am running EPICS v3.14.5 on Linux.

The device is a PC that runs a 3rd party program that controls a sample wheel that forms part of an ion source.

If possible get the third party to change their protocal.

Sending a command from the IOC to the ion source PC commonly produces 4 responses.

For example say the IOC sends the following command to the ion source PC:
"LOAD06"
The IOC can expect the following 4 responses when the command is handled successfully:
"LOAD06"
"VALIDC" # The first two responses return almost immediately.
"SAMPLE" # We may have to wait up to 30 secs for this to come in.
"OKDONE" # Then we have to wait up to 30 secs again for this last response to arrive.


Most of the commands we send to the ion source PC will produce responses similar to this example, except the times we can expect to wait for the responses are different. In some cases all 4 will come in within 2 seconds. Sometimes we may have to wait around 4 seconds for the responses to arrive.

If the above load command could not successfully complete we may receive 2 responses or 4 responses (depending on the problem).

Eric alresy answered this.

Another command will produce a large amount of textual information.
For example if we send:
"INFSAM"
Then we can expect the following responses:
"VALIDC"
Then 7 lines of information (each terminated by "\r\n"):
Up to 6 chars
Up to 30 chars
Up to 20 chars
1 char
2 chars
1 char
2 chars
Then to finish off:
"OKDONE"

1. Can I use drvAsyn/devGpib to handle this device? If I write my own device support should I look to use drvAsyn underneath it?

2. What record type could I use to handle the last example command?


I will describe two possibilities: 1) a devGpib implementation and 2) a devEpics implementation.
I would suggest the devEpics for reasons given below.


But first the devGpib implementation

Have your port Driver implement interface asynGpibPort. It does the following

When a write command for "INFSAM" is sent it reads until it gets the OKDONE.
It keeps all the data sent to it until the next INFSAM command arrives.

It expects the next command to be a read. It just returns everything it read uninterpeted.
In addition it declares srqHappened.


For each item of info in the message assign a name. For example "getPressure".
When a write request is received it is matched against the list of names. The next read returns the info associated with the name.


Your devGpib support consists of the following

For a waveform record thhat contains the raw message obtained from the device.

{&DSET_WF, GPIBREAD, IB_Q_LOW, "INFSAM",0,0,2000,0,0,0,0,0,0}

The srq handler

{&DSET_LI, GPIBSRQHANDLER, IB_Q_HIGH, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0},

For each data item a comandd like

{&DSET_??,GPIBREAD,IB_Q_LOW,"<name>", ... }

The details depend on the type of the data item. Some analog, Some binary, Some string.

Then create a database the has a record for each command.

The longin record for GPIBSRQHANDLER has a FLNK to a set of fanout records that link to eacg of the records associated with each data item.

When the waveform record is processed the following happens

1) The INFSAM command is sent. The reaponse is read, returned to the waveform record, and kept internally by the port driver.
2) The longin record associated with the GPIBSRQHANDLER command is processed. It causes all linked records to process
3) Each linked record issues a write to the port driver. It determines if this is a command it handles and when the next read occurs it returns the response.


This could also be done using devEpics support. In this case your asynDriver would implement some combination of interfaces aasynDrvUser, synInt32,
asynFloat64, and asynUInt32Digital.


In this case you only have to implement a port driver and a database. You will be using stardard devEpics support. You waveform record will have

field(INP,"@asyn($(PORT),$(ADDR)) INFSAM)

When you port driver receives a write with INFSAM it uses the asynDriver interrupt mechanism to cause all the associated records to process.
Each of of the associated records has SCAN set to "I/O Intr".


Each associated record has an INP field

field(INP,"@asyn($(PORT),$(ADDR)) <name>)

where name specified the data item to retrieve.


The devEpics implementation should not be much more complicated than the devGpib and has the following features



1) The mapping from cmdName to data can be done once at initialization. With the devGpib implementation above it has to look up the name everytoime a write command is received.
2) ALL device specific code is contained in a single module.
3) The record instance syntax is more descriptive. e.g.


field(INP,"@asyn($(PORT),$(ADDR)) INFSAM)

rather than

field(INP,"#$(PORT) A$(A) @0")

I hope this helps.

Marty Kraimer


Thanks,
Damien



References:
A couple of drvAsyn/devGpib questions LYNCH, Damien

Navigate by Date:
Prev: Re: A couple of drvAsyn/devGpib questions Eric Norum
Next: EPICS Base R3.14.8.2 is now available Andrew Johnson
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017 
Navigate by Thread:
Prev: Re: A couple of drvAsyn/devGpib questions Eric Norum
Next: EPICS Base R3.14.8.2 is now available Andrew Johnson
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017 
ANJ, 02 Sep 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·