| 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: RE: A question on asyn application |
| From: | Ralph Lange via Tech-talk <tech-talk at aps.anl.gov> |
| To: | EPICS Tech Talk <tech-talk at aps.anl.gov> |
| Date: | Wed, 24 Jan 2024 17:46:45 +0100 |
- If your device is interfaced through messages over a byte-stream connection (like TCP) and the communication follows a request/response model - your test looks like exactly that - you should not code your own asyn driver, but use StreamDevice.
I agree with that statement in most cases. However, there are important exceptions:
- When using non-standard EPICS records, such as the motor record, scaler record, mca record, etc. StreamDevice cannot be used for these. Since the driver name in this case is ct08, this might be a counter using the scaler record.
- When dealing with complex devices where the “state” of the device is important for the communications. It is more difficult keep the state information in the database and act on it appropriately than it is in the driver.
- When dealing with request/response protocols that can be much more efficient when processing multiple records when not using StreamDevice. For example, a single Modbus transaction can update the state of 2000 bi records. It is much simpler and more efficient to use the optimized Modbus driver rather than StreamDevice.