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: Streamdevice reads weird 1 byte null data
From: Hyung Jin Kim via Tech-talk <tech-talk at aps.anl.gov>
To: Freddie Akeroyd - STFC UKRI <freddie.akeroyd at stfc.ac.uk>, "ralph.lange at gmx.de" <ralph.lange at gmx.de>, "tech-talk at aps.anl.gov" <tech-talk at aps.anl.gov>
Date: Mon, 18 Sep 2023 07:55:37 +0900
Thank you for your comments.
After applying an @mismatch handler as mentioned, the error message is suppressed temporarily.
And now I am looking at the asyn interpose function.

Thanks,
Hyung Jin Kim

On 9/17/23 22:29, Freddie Akeroyd - STFC UKRI wrote:

Hi,

 

I suspect the Stream device regex pseudo converter https://paulscherrerinstitute.github.io/StreamDevice/formats.html#regsub may not work with an embedded null byte, but not tested myself. Other options might be:

 

If the issue doesn’t happen too often, you could define an @mismatch handler that re-parses with the leading null as part of the pattern  https://paulscherrerinstitute.github.io/StreamDevice/protocol.html#except however you will still see the record temporarily go into alarm when this happens

 

To fully resolve you may need to create an asyn interpose function to pre-process the input and remove an initial null byte (if it exists) before stream device begins parsing – examples of interpose functions are at  https://github.com/epics-modules/asyn/tree/master/asyn/miscellaneous and you could use the readIt() function to call the normal octet read interface and then adjust the data array and nbytesTransfered as needed

 

Regards,

 

Freddie

 

From: Tech-talk <tech-talk-bounces at aps.anl.gov> On Behalf Of Hyung Jin Kim via Tech-talk
Sent: 17 September 2023 06:36
To: ralph.lange <ralph.lange at gmx.de>
Cc: EPICS Tech Talk <tech-talk at aps.anl.gov>
Subject: Re: Streamdevice reads weird 1 byte null data

 

Thanks for your comment.

It seems that MaxInput does not solve the mentioned issue.

After changing debugging options, I look at iocshell console message.

asynSetTraceMask  ("PHWRB41", 0, -1)
asynSetTraceIOMask("PHWRB41", 0, -1)

 

It seems that asynDriver sometimes reads 15 bytes, sometimes reads 16 bytes, and sometimes reads 17 bytes. 

However, it's not clear whether the actual device sends data like that.

If there is a way to remove the leading \x00 or prevent it from being read, I think the problem can be solved somehow.

Detailed debugging message(blue lines are asynDriver read, and red line is error) is attached.

 

Thanks,

Hyung Jin Kim

 

=====================================================

 

2023/09/17 13:41:12.593 PHWRB41 set Eos 0

2023/09/17 13:41:14.287 PHWRB41 addr -1 queueRequest priority 0 not lockHolder
2023/09/17 13:41:14.287 PHWRB41 schedule queueRequest timeout in 30.000000 seconds
2023/09/17 13:41:14.287 asynManager::portThread port=PHWRB41 callback
2023/09/17 13:41:14.287 PHWRB41 addr -1 queueRequest priority 0 not lockHolder
2023/09/17 13:41:14.287 PHWRB41 schedule queueRequest timeout in 1.000000 seconds
2023/09/17 13:41:14.288 asynManager::portThread port=PHWRB41 callback
2023/09/17 13:41:14.288 192.168.85.191:4001 read.
2023/09/17 13:41:14.289 PHWRB41 read from low-level driver returned 1
2023/09/17 13:41:14.290 PHWRB41 get Eos 0

2023/09/17 13:41:14.290 PHWRB41 set Eos 0

2023/09/17 13:41:14.290 192.168.85.191:4001 write.
2023/09/17 13:41:14.291 192.168.85.191:4001 write 7
■■
\x16\x16\x80\x00\x00\x80\x1a

16 16 80 00 00 80 1a
2023/09/17 13:41:14.292 wrote 7 to 192.168.85.191:4001, return asynSuccess.
2023/09/17 13:41:14.293 PHWRB41 set Eos 0

2023/09/17 13:41:14.588 PHWRB41 addr -1 queueRequest priority 0 from lockHolder
2023/09/17 13:41:14.588 PHWRB41 schedule queueRequest timeout in 1.000000 seconds
2023/09/17 13:41:14.589 asynManager::portThread port=PHWRB41 callback
2023/09/17 13:41:14.589 PHWRB41 get Eos 0

2023/09/17 13:41:14.589 PHWRB41 set Eos 1

\x1a

1a
2023/09/17 13:41:14.590 192.168.85.191:4001 read.
2023/09/17 13:41:14.590 192.168.85.191:4001 read 15
■■

\x16\x16\x80\x00\b\x00\x80\"C\x00\x00\xc0@m\x1a


16 16 80 00 08 00 80 22 43 00 00 c0 40 6d 1a
2023/09/17 13:41:14.593 PHWRB41 read 15 bytes eom=0
■■
\x16\x16\x80\x00\b\x00\x80\"C\x00\x00\xc0@m\x1a

16 16 80 00 08 00 80 22 43 00 00 c0 40 6d 1a
2023/09/17 13:41:14.596 PHWRB41 set Eos 0

 

...

 

2023/09/17 13:42:26.287 PHWRB41 addr -1 queueRequest priority 0 not lockHolder
2023/09/17 13:42:26.287 PHWRB41 schedule queueRequest timeout in 30.000000 seconds
2023/09/17 13:42:26.287 asynManager::portThread port=PHWRB41 callback
2023/09/17 13:42:26.287 PHWRB41 addr -1 queueRequest priority 0 not lockHolder
2023/09/17 13:42:26.287 PHWRB41 schedule queueRequest timeout in 1.000000 seconds
2023/09/17 13:42:26.288 asynManager::portThread port=PHWRB41 callback
2023/09/17 13:42:26.288 192.168.85.191:4001 read.
2023/09/17 13:42:26.289 PHWRB41 read from low-level driver returned 1
2023/09/17 13:42:26.289 PHWRB41 get Eos 0

2023/09/17 13:42:26.289 PHWRB41 set Eos 0

2023/09/17 13:42:26.289 192.168.85.191:4001 write.
2023/09/17 13:42:26.290 192.168.85.191:4001 write 7
■■
\x16\x16\x80\x00\x00\x80\x1a

16 16 80 00 00 80 1a
2023/09/17 13:42:26.290 wrote 7 to 192.168.85.191:4001, return asynSuccess.
2023/09/17 13:42:26.290 PHWRB41 set Eos 0

2023/09/17 13:42:26.586 PHWRB41 addr -1 queueRequest priority 0 from lockHolder
2023/09/17 13:42:26.586 PHWRB41 schedule queueRequest timeout in 1.000000 seconds
2023/09/17 13:42:26.586 asynManager::portThread port=PHWRB41 callback
2023/09/17 13:42:26.586 PHWRB41 get Eos 0

2023/09/17 13:42:26.586 PHWRB41 set Eos 1

\x1a

1a
2023/09/17 13:42:26.587 192.168.85.191:4001 read.
2023/09/17 13:42:26.587 192.168.85.191:4001 read 16
■■

\x16\x16\x80\x00\b\x00\x80\"C\x00\x00\xc0@m\x1a\x00


16 16 80 00 08 00 80 22 43 00 00 c0 40 6d 1a 00
2023/09/17 13:42:26.588 PHWRB41 read 16 bytes eom=0
■■
\x16\x16\x80\x00\b\x00\x80\"C\x00\x00\xc0@m\x1a\x00

16 16 80 00 08 00 80 22 43 00 00 c0 40 6d 1a 00
2023/09/17 13:42:26.590 PHWRB41 set Eos 0

2023/09/17 13:42:28.287 PHWRB41 addr -1 queueRequest priority 0 not lockHolder
2023/09/17 13:42:28.287 PHWRB41 schedule queueRequest timeout in 30.000000 seconds
2023/09/17 13:42:28.287 asynManager::portThread port=PHWRB41 callback
2023/09/17 13:42:28.287 PHWRB41 addr -1 queueRequest priority 0 not lockHolder
2023/09/17 13:42:28.287 PHWRB41 schedule queueRequest timeout in 1.000000 seconds
2023/09/17 13:42:28.288 asynManager::portThread port=PHWRB41 callback
2023/09/17 13:42:28.288 192.168.85.191:4001 read.
2023/09/17 13:42:28.289 PHWRB41 read from low-level driver returned 1
2023/09/17 13:42:28.289 PHWRB41 get Eos 0

2023/09/17 13:42:28.289 PHWRB41 set Eos 0

2023/09/17 13:42:28.289 192.168.85.191:4001 write.
2023/09/17 13:42:28.290 192.168.85.191:4001 write 7
■■
\x16\x16\x80\x00\x00\x80\x1a

16 16 80 00 00 80 1a
2023/09/17 13:42:28.290 wrote 7 to 192.168.85.191:4001, return asynSuccess.
2023/09/17 13:42:28.290 PHWRB41 set Eos 0

2023/09/17 13:42:28.586 PHWRB41 addr -1 queueRequest priority 0 from lockHolder
2023/09/17 13:42:28.586 PHWRB41 schedule queueRequest timeout in 1.000000 seconds
2023/09/17 13:42:28.586 asynManager::portThread port=PHWRB41 callback
2023/09/17 13:42:28.586 PHWRB41 get Eos 0

2023/09/17 13:42:28.587 PHWRB41 set Eos 1

\x1a

1a
2023/09/17 13:42:28.587 192.168.85.191:4001 read.
2023/09/17 13:42:28.587 192.168.85.191:4001 read 17

\x00\x16\x16\x80\x00\b\x00\x80\"C\x00\x00\xc0@m\x1a\x00


00 16 16 80 00 08 00 80 22 43 00 00 c0 40 6d 1a 00
2023/09/17 13:42:28.588 PHWRB41 read 17 bytes eom=0

\x00\x16\x16\x80\x00\b\x00\x80\"C\x00\x00\xc0@m\x1a\x00

00 16 16 80 00 08 00 80 22 43 00 00 c0 40 6d 1a 00
2023/09/17 13:42:28.589607 PHWRB41 SCL32-RF03:SSPA-B41:#getInfo: Input "<00><16><16><80><00><08><00><80>"C<00><00><c0>@m" does not match format "%=.1r" ("<16>")
2023/09/17 13:42:28.590 PHWRB41 set Eos 0

 

 

On Fri, Sep 15, 2023 at 5:02 PM Ralph Lange via Tech-talk <tech-talk at aps.anl.gov> wrote:

On Fri, 15 Sept 2023 at 09:31, Zimoch Dirk via Tech-talk <tech-talk at aps.anl.gov> wrote:


BTW: For binary protocols (using formats like %r or %R) using
Terminator/InTerminator is problematic because the binary data may contain the
terminator byte. Often, binary protocols have fixed message sizes. I suggest to
use MaxInput in that case.

 

That's crucial.

Even if the data doesn't contain the terminator byte, the checksum may at any time.

 

Cheers,
~Ralph

 



References:
Streamdevice reads weird 1 byte null data Hyung Jin Kim via Tech-talk
Re: Streamdevice reads weird 1 byte null data Zimoch Dirk via Tech-talk
Re: Streamdevice reads weird 1 byte null data Ralph Lange via Tech-talk
Re: Streamdevice reads weird 1 byte null data Hyung Jin Kim via Tech-talk
RE: Streamdevice reads weird 1 byte null data Freddie Akeroyd - STFC UKRI via Tech-talk

Navigate by Date:
Prev: RE: Streamdevice reads weird 1 byte null data Freddie Akeroyd - STFC UKRI via Tech-talk
Next: Re: Streamdevice reads weird 1 byte null data 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  <20232024 
Navigate by Thread:
Prev: RE: Streamdevice reads weird 1 byte null data Freddie Akeroyd - STFC UKRI via Tech-talk
Next: Re: Streamdevice reads weird 1 byte null data 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  <20232024 
ANJ, 18 Sep 2023 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·