Experimental Physics and Industrial Control System
|
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:- Wait for command
- If identifier in the command packet matches that of the previous reply, then just send that reply again and go back to step 1.
- Otherwise act on the command, put the identifier from the command packet into the reply packet, fill in any reply data, send the reply and then go back to step 1.
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:- Send a command
- if a reply is not received in 100 ms then send the command again
- if a reply is not received in 1 second then send the command again — after 5 attempts report an error
Some other UDP advantages: - UDP is much simpler — direct implementation in FPGA firmware is quite feasible.
- UDP has lower network overhead — in the absence of errors the only packets on the wire are the commands and replies.
- UDP is connectionless — there’s no overhead in setting up communication nor the possibility of dangling resources on unexpected loss of an IOC (e.g. the IOC host crashes without closing all the TCP streams).
Although TCP is ‘reliable’ you still have to check the success of every I/O request so there’s really not much programming overhead needed when using UDP.
If you’re transferring very large amounts of data then TCP is likely easier to implement to provide high bandwidth, but in pretty much all other cases I’d recommend UDP.
Thanks for all the feedback, I have to admit I did not properly checked the memory of the chip compared to the requirements for an IOC. And I also might have mixed up RTEMS with RTOS 😅 I guess I either stay with my current design (TCP socket on the module using StreamDevice + Asyn for communication with an external IOC) or I'll switch to ModbusTCP. Btw Eric, why do you think UDP would be more appropriate than TCP?
Cheers, Florian
|
- References:
- EPICS on ESP32 Florian Feldbauer via Tech-talk
- Re: EPICS on ESP32 Eric Norum via Tech-talk
- Re: EPICS on ESP32 Florian Feldbauer via Tech-talk
- Navigate by Date:
- Prev:
Re: EPICS on ESP32 Joel Sherrill via Tech-talk
- Next:
asyn build fail Siddons, David via Tech-talk
- 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: EPICS on ESP32 Joel Sherrill via Tech-talk
- Next:
Re: EPICS on ESP32 Davis, Mark via Tech-talk
- 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
|
ANJ, 14 Sep 2022 |
·
Home
·
News
·
About
·
Base
·
Modules
·
Extensions
·
Distributions
·
Download
·
·
Search
·
EPICS V4
·
IRMIS
·
Talk
·
Bugs
·
Documents
·
Links
·
Licensing
·
|