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 | 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 |
<== Date ==> | <== Thread ==> |
---|
Subject: | RE: Is it possible for an Asyn output record to be, also, an (I/OIntr - driven) input? |
From: | "Heesterman, Peter J" <[email protected]> |
To: | "Ralph Lange" <[email protected]>, "EPICS Tech-Talk" <[email protected]>, <[email protected]> |
Date: | Mon, 1 Dec 2014 14:04:11 -0000 |
Hi Ralph, Nick, Thank you for your responses. I took a look at http://www-csr.bessy.de/control/SoftDist/OPCsupport/ and downloaded 3.8.0.1. Unfortunately, there seem to be files missing from the install, so I am unable to exercise it. The readme is informative, I am struck by the comments: For out-records the SCAN field is ignored by the device support and should be set to "Passive". Out records: The value written by EPICS is ignored by the PLC. I have been working with this definition: record(bo, "$(P)StartStop") { field(DESC, "StartStop") field(DTYP, "asynInt32") field(OUT, "@asyn($(PORT),0,1)STARTSTOP") field(SCAN, "I/O Intr") field(ZNAM, "OFF") field(ONAM, "ON") } Can you tell me whether this is valid, for what I’m trying to do? To my knowledge, Asyn will not process input changes without setting the scan type in this way. What I find is that, while this works as an input, driven by its SCAN specification, it fails to work correctly as an output. A value that is output by a caput enters the database (and can be read back with a caget), but isn’t applied to the device layer. I was able to determine why this is. The execution path to output the new value is blocked by the condition in dbPutField in base\src\ioc\db\dbaccess.c: if (paddr->pfield == (void *)&precord->proc || (pfldDes->process_passive && precord->scan == 0 && dbrType < DBR_PUT_ACKT)) As an experiment, I commented out the highlighted clause. Having done so, my (AsynPortDriver) code worked perfectly, in just the manner that I had been expecting, for both input and output. Is the above condition clause necessary? Many thanks, Peter. From: [email protected] [mailto:[email protected]] On Behalf Of Ralph Lange On 28/11/2014 14:09, [email protected] wrote: This is possible (the motor record is a good example), but it needs the record type to support it. Most record types don’t support two way communication with device support.
|