Re: Streamdevice reads weird 1 byte null data

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

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