Experimental Physics and
Industrial Control System

Hey Dirk,

thanks for the detailed explanation.

Thx for the advice with the eomReason, I changed my driver accordingly.
My protocol and record now look like this:

Terminator = '';
recv {
  MaxInput = 4;
  in  0x07 $1 "%r";
}

record( longin, "CAN${N}:TEST:R" ) {
  field( DTYP, "stream" )
  field( SCAN, "I/O Intr" )
  field( INP,  "@can.proto recv(0x00) ${port}" )
}

Here is the complete log from Stream:

epics> dbpf CAN0:TEST:W 21

DBF_LONG:           21 = 0x15

2023/07/04 11:03:07.130 can0: wrote 4 bytes to can0, return asynSuccess

2023/07/04 11:03:07.484 can1: read 5 bytes from can1, return asynSuccess

Cheres,
Florian


On 7/4/23 10:45, Zimoch Dirk wrote:

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

--
Ruhr-Universität Bochum
AG der Experimentalphysik I
Dr. Florian Feldbauer
NB 2/131 / Fach 125
Universitätsstr. 150
D-44801 Bochum

Office: NB 2/134
Phone:  (+49)234 / 32-23563
Fax:    (+49)234 / 32-14170
https://paluma.ruhr-uni-bochum.de

Replies:

Re: Issue with streamdevice and I/o Intr Zimoch Dirk via Tech-talk

References:

Issue with streamdevice and I/o Intr Florian Feldbauer via Tech-talk

Re: Issue with streamdevice and I/o Intr Zimoch Dirk via Tech-talk

Navigate by Date:

Prev: Re: Issue with streamdevice and I/o Intr Zimoch Dirk via Tech-talk

Next: RE : VME configuration : mrfioc2-master version in the new vme-evg-300, vme-evr-300 environment 이민균 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: Issue with streamdevice and I/o Intr Zimoch Dirk via Tech-talk

Next: Re: Issue with streamdevice and I/o Intr Zimoch Dirk 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