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 2025 | 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 2025 |
<== Date ==> | <== Thread ==> |
---|
Subject: | RE: Help beginner with ASYN device support, ai record conversion to EGU |
From: | Mark Rivers <[email protected]> |
To: | "'Eric Norum'" <[email protected]>, "Gomella, Andrew (NIH/NHLBI) [F]" <[email protected]> |
Cc: | epics Techtalk <[email protected]> |
Date: | Mon, 13 May 2013 17:37:06 +0000 |
Hi Andrew, I would second what Eric suggested about using StreamDevice. The only thing you need to write is a protocol file, no C code. asyn now comes with a new document explaining how to do that: asyn-4-21/documentation/HowToDoSerial/HowToDoSerial_StreamDevice.html This document is not on the asyn Web site yet (will fix that), but it is included in the documentation directory in asyn. Mark J:\epics\devel\asyn-4-21\documentation\HowToDoSerial\HowToDoSerial_StreamDevice.html -----Original Message----- 1) LINR should be SLOPE. 2) I recommend that you have a look at StreamDevice -- it's now what I'd recommend as the best place to start to support a message-based device. On May 13, 2013, at 10:07 AM, "Gomella, Andrew (NIH/NHLBI) [F]" <[email protected]> wrote: > Hi, > > I have been following Eric Norum's "How To Do Serial" guide (
http://www.aps.anl.gov/epics/modules/soft/asyn/R4-21/HowToDoSerial/tutorial.pdf) to write an application to control a serial port controller table top x-ray source. > > So far everything works near perfectly (Thanks to Eric for the guide, and the writers of ASYN/EPICS), my only issue is that I am having trouble getting the Analog Input and Output fields to work properly. I can easily read and write
the raw values (0 to 4095 due to it being a 12 bit DAC inside the xray's controller) but when I change the .db record to try and use ASYN's built in functions to convert the value I run in to issues. I'm definitely missing something that is probably obvious
for most techtalk readers. > > Here is one of the commands in the app source file. > > {&DSET_AI, GPIBREAD, IB_Q_LOW, "RD1", NULL, 0, 127, NULL, 0, 0, NULL, NULL, NULL}, > > The controller responds to RD1 with 0000\r with 0000 being from 0000 to 4095. (I tried using the format function, i.e. with "%u\r" but this didn't seem to work, but with NULL it does.) > > Here is the corresponding section of my db file. (which is how I was hoping it would work at first) srxr is the name of my device. > > record(ai, "$(P)$(R):uAStatus") > { > field(DESC, "Read Xray uA Monitor") > field(SCAN, "1 second") > field(DTYP, "srxr") > field(LINR, "LINEAR") > field(ASLO, "0.244") > field(AOFF, "0") > field(EGUF, "900") > field(EGUL, "0") > field(EGU, "uA") > field(INP, "#L$(L) A$(A) @11") > } > > I tried changing DTYP to asynInt32, and then changing INP to the @asyn format, but this did not seem to work. > > I also tried to change several of the fields, such as LINR to SLOPE. So far I only get the field showing as 0 (when it should be reading > an output, or as the raw value. > > Here are relevant portions of st.cmd > > ## Register all support components > dbLoadDatabase "dbd/srxr.dbd" > srxr_registerRecordDeviceDriver pdbbase > > ## Load record instances > dbLoadRecords("db/devsrxr.db","P=srxr,R=,L=0,A=0") > > drvAsynSerialPortConfigure("L0","/dev/ttyS0",0,0,0) > asynSetOption("L0", -1, "baud", "9600") > asynSetOption("L0", -1, "bits", "8") > asynSetOption("L0", -1, "parity", "none") > asynSetOption("L0", -1, "stop", "1") > asynSetOption("L0", -1, "clocal", "Y") > asynSetOption("L0", -1, "crtscts", "N") > > As is, this just reads out the raw values of uA, rather than it being converted to EGU. > > Alternatively someone can point me to example source code that runs a serial device, but is more complex > than the filter wheel in the "How To Do Serial" guide (uses more record types like ai etc). > > I couldn't find any that helped me with this issue. > > Thanks, > Andrew > -- Eric Norum |