Re: Streamdevice reads weird 1 byte null data

[Hyung Jin Kim via Tech-talk <tech-talk at aps.anl.gov>]

    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