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: EPICS on ESP32 |
From: | Eric Norum via Tech-talk <tech-talk at aps.anl.gov> |
To: | Florian Feldbauer <florian at ep1.ruhr-uni-bochum.de> |
Cc: | "tech-talk at aps.anl.gov" <tech-talk at aps.anl.gov> |
Date: | Wed, 31 Aug 2022 11:53:56 -0700 |
I should have included the code in the instrument corresponding to the IOC code sent in my original message. It’s important to note that all commands and replies include a unique identifier. The IOC ignores reply packets that have identifiers different from the outstanding command and the instrument does the following:
This simple approach would have to be expanded if the IOC and instrument were separated by a bunch of network hops resulting in the possibility of a packet arriving far out of order, but when they’re on the same network segment or with just a single router in between it works well and ensures that retries don’t result in commands being acted upon multiple times. The most important reason that UDP is more appropriate for basic command/reply operations is that it puts you in control of the retries. You can keep track of how many times they are required and you can tune the retry timeouts as you wish. For example, many of my ’network attached device’ UDP ASYN drivers work as follows: |