EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

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  <20232024  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  <20232024 
<== Date ==> <== Thread ==>

Subject: Re: Issue with streamdevice and I/o Intr
From: Zimoch Dirk via Tech-talk <tech-talk at aps.anl.gov>
To: "florian at ep1.ruhr-uni-bochum.de" <florian at ep1.ruhr-uni-bochum.de>, "tech-talk at aps.anl.gov" <tech-talk at aps.anl.gov>
Date: Tue, 4 Jul 2023 08:45:27 +0000
Hi Florian,

For "I/O Intr" records, StreamDevice uses intrCallbackOctet but still needs to
poll the device, because despite its name, intrCallbackOctet does not deliver
any data asynchronously when nobody reads synchronously. The "I/O Intr" records
receives ALL input, regardless of the active reader, which may be the record
itself, some other StreamDevice Record or even non-StreamDevice records or any
other software calling asynOctet->read on that port.

Thus, to avoid receiving the data twice, in case the intrCallbackOctet receiver
is the polling record, StreamDevice discards the input received with the polled
read and only uses the input received with intrCallbackOctet.

As ALL "I/O Intr" StreamDevice records receive ALL input, they all match the
input against their 'in' commands. Only those records  which could match the
input successfully are processed. All others silently ignore the input!

The intrCallbackOctet input log messages should show up in the logs BEFORE the
message form the polled read (because asyn calls the interrupt callbacks before
returning from read). What do you have in the logs right before the first line
you posted? Anything from AsynDriverInterface::asynReadHandler() and
StreamCore::readCallback()?


As StreamDevice did not receive a termination signal, it assumes there may be
more input and tries to read it. But that results in a timeout, which is then
interpreted as a termination signal, because no InTerminator is used.

This is probably not what you want. If the message never exceeds one CAN frame,
set eomReason to ASYN_EOM_END. This avoids wasting time on another read attempt.
If you may have messages that span multiple frames and have a method to find out
when this is the case in your driver, do that. Otherwise waiting for timeout (or
InTerminator or maxInput) is in fact the only way.

Now the question is why the input is rejected. Hard to say without knowing your
protocol. What do you have in your 'in' command?

Dirk


On Tue, 2023-07-04 at 09:05 +0200, Florian Feldbauer via Tech-talk wrote:
> Hey all,
> 
> we have some devices controlled via CAN bus.
> Since CAN bus is based on the transmission of 1-8 bytes, I wrote an 
> AsynPortDriver with an asynOctet interface as lower level driver.
> 
> I wanted to use StreamDevice as higher level driver defining the actual 
> payload data that is tranmitted between our PC and the devices.
> 
> Sending and receiving messages in principal works, but I have an issue 
> with I/O Interrupts and I don't know why.
> Setting the streamDebug variable to 1, I see the following output from 
> StreamDevice:
> 
> 2023/07/04 08:54:44.301618 can1 AsynDriverInterface.cc:951: 
> AsynDriverInterface::readHandler(CAN1:TEST:R): ioAction=AsyncRead 
> read(63 bytes, timeout=0 sec) returned status asynSuccess: received=4 
> bytes, eomReason=NONE, buffer="<07><00><00><ea>"
> 2023/07/04 08:54:44.301765 can1 AsynDriverInterface.cc:977: 
> AsynDriverInterface::readHandler(CAN1:TEST:R): AsyncRead poll: received 
> 4 of 63 bytes "<07><00><00><ea>" eomReason=NONE [data ignored]
> 2023/07/04 08:54:44.301889 can1 AsynDriverInterface.cc:1123: 
> AsynDriverInterface::readHandler(CAN1:TEST:R) readMore=-1 bytesToRead=63
> 2023/07/04 08:54:44.302015 can1 AsynDriverInterface.cc:951: 
> AsynDriverInterface::readHandler(CAN1:TEST:R): ioAction=AsyncRead 
> read(63 bytes, timeout=0.5 sec) returned status asynTimeout: received=0 
> bytes, eomReason=NONE, buffer=""
> 2023/07/04 08:54:44.302140 can1 AsynDriverInterface.cc:1051: 
> AsynDriverInterface::readHandler(CAN1:TEST:R): ioAction=AsyncRead, 
> timeout [0.5 sec] after 0 of 63 bytes ""
> 2023/07/04 08:54:44.302262 can1 StreamCore.cc:963: 
> StreamCore::readCallback(CAN1:TEST:R, StreamIoTimeout input="", size=0)
> 2023/07/04 08:54:44.302378 can1 StreamCore.cc:1015: 
> StreamCore::readCallback(CAN1:TEST:R) inputBuffer="", size 0
> 2023/07/04 08:54:44.302490 can1 StreamCore.cc:1067: 
> StreamCore::readCallback(CAN1:TEST:R) end flag received
> 2023/07/04 08:54:44.302605 can1 StreamCore.cc:1127: 
> StreamCore::readCallback(CAN1:TEST:R) input line: ""
> 2023/07/04 08:54:44.302726 can1 StreamCore.cc:1151: 
> StreamCore::readCallback(CAN1:TEST:R) async match failure: just restart
> 2023/07/04 08:54:44.302847 can1 AsynDriverInterface.cc:806: 
> AsynDriverInterface::readRequest(CAN1:TEST:R, 500 msec reply, 500 msec 
> read, expect 0 bytes, async=yes)
> 2023/07/04 08:54:44.302964 can1 AsynDriverInterface.cc:831: 
> AsynDriverInterface::readRequest CAN1:TEST:R: queueRequest(..., 
> priority=0, queueTimeout=-1 sec) = asynSuccess [async=true]
> 
> The readHandler reads the message from the bus but ignores it. According 
> to the comments in the code it is ignored because the asyncReadHandler 
> should also receive this message and handle the I/O interrupt, but it 
> seems the Interrupt callback is not executed.
> Any idea why the callbacks don't work?
> 
> I'm using
> base 7.0.6.1
> stream 2.8.24
> asyn (current HEAD on master branch)
> 
> Cheers,
> Florian
> 
> 

Replies:
Re: Issue with streamdevice and I/o Intr Florian Feldbauer via Tech-talk
References:
Issue with streamdevice and I/o Intr Florian Feldbauer via Tech-talk

Navigate by Date:
Prev: Issue with streamdevice and I/o Intr Florian Feldbauer via Tech-talk
Next: Re: Issue with streamdevice and I/o Intr Florian Feldbauer 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  <20232024 
Navigate by Thread:
Prev: Issue with streamdevice and I/o Intr Florian Feldbauer via Tech-talk
Next: Re: Issue with streamdevice and I/o Intr Florian Feldbauer 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  <20232024 
ANJ, 04 Jul 2023 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·