Hi Rod,
In addition to what Eric said, here are a couple of more benefits of specifying the terminators in the asyn layer:
- It allows the asyn record to be used for I/O to the device for debugging and testing. If the terminators are only defined on the protocol file then this is not possible.
- Many devices allow the terminators to be defined using the front panel, i.e. they are not fixed. They thus are not really part of the protocol, they are a configuration parameter of the device, and as such I believe they should be set in the startup script, not in the protocol file.
Mark
________________________________
From: [email protected] [[email protected]] on behalf of Eric Norum [[email protected]]
Sent: Tuesday, July 22, 2014 5:56 PM
To: Rod Nussbaumer
Cc: [email protected]
Subject: Re: StreamDevice, asynDriver or some other solution?
Specifying the terminators in the startup script rather then the protocol file is useful when an instrument has both a serial or ‘raw TCP’ interface (which require terminators) and a GPIB or USB-TMC interface (which often do not require terminators since they have another ‘end of message’ mechanism). Omitting the terminator information from the protocol file allows the same protocol file to be used in both cases.
If the instrument in question has only an interface or interfaces needing terminators, then specifying the terminators in the protocol file is probably the best way to go.
YMMV
On Jul 22, 2014, at 3:45 PM, Rod Nussbaumer <[email protected]<mailto:[email protected]>> wrote:
Bryan:
I completely concur with Mark's assessment that StreamDevice is the optimal approach for an EPICS interface to your device.
I do have a question for Mark, however. In my use of SteamDevice, I typically do not use asynOctetSetInputEos to terminate lines in the asyn driver. Is there some tangible benefit that I am missing by using StreamDevice to specify line terminators? As a developer, it feels more natural to specify the terminator character in the protocol file, where everything else related to the data communication with a device is specified. If there is a good reason to do it int he asyn layer, I will consider doing that way in future systems.
--
Eric Norum
[email protected]<mailto:[email protected]>
- References:
- StreamDevice, asynDriver or some other solution? Bryan J. Boardman / Aware Electronics Corp.
- RE: StreamDevice, asynDriver or some other solution? Mark Rivers
- Re: StreamDevice, asynDriver or some other solution? Rod Nussbaumer
- Re: StreamDevice, asynDriver or some other solution? Eric Norum
- Navigate by Date:
- Prev:
Re: StreamDevice, asynDriver or some other solution? Eric Norum
- Next:
Tabbed Container Ability Patard Charles-Henri
- 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
- Navigate by Thread:
- Prev:
Re: StreamDevice, asynDriver or some other solution? Eric Norum
- Next:
Re: StreamDevice, asynDriver or some other solution? Dirk Zimoch
- 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
|