| 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: | AW: [EXTERNAL] Experiences using RS-485 Multi-Drop with StreamDevice? |
| From: | "Zimoch Dirk \(PSI\) via Tech-talk" <tech-talk at aps.anl.gov> |
| To: | Ralph Lange <ralph.lange at gmx.de> |
| Cc: | EPICS Tech Talk <tech-talk at aps.anl.gov> |
| Date: | Tue, 3 Nov 2020 16:23:14 +0000 |
|
StreamDevice is locking only for the duration of one protocol. So If you have protocols which send only the commands and do not wait for a reply but read the replies with separate I/O Int records, locking would not apply. StreamDevice has the %=... feature to compare incoming data with a given value. Thus if you have the unique ID in some record, you could do something like { in "%(unique_ID_record)=d %f"; } (assuming decimal ID) in the I/O Intr records
which should filter the reply with the matching ID. I am not sure about performance though. Dirk Von: Tech-talk <tech-talk-bounces at aps.anl.gov>
Im Auftrag von Ralph Lange via Tech-talk Thanks a lot Matt, That unique ID is in addition to the RS-485 address, like a transaction counter. It looks like any single controller can cope with multiple commands being received at high speed, and will send the responses in some (any) order, using the unique ID from the respective command in the replies for the master to tell them
apart. This "parallel" mode probably does not apply as StreamDevice/Asyn is serializing the protocols and waits for the response before sending the next request. Thanks again, ~Ralph |