Experimental Physics and
Industrial Control System

Hi Dirk,

it is a TCP/IP device so there is no EOI send by the device. The size of
the data block is known beforehand since it depends on the device
settings. It can be a block of up to 4 x 2048 x 32 Bit raw values. The
device even sends a terminator (this is unfortunately not aways the case
with all the devices I encountered so far), but in this case it's
useless since the pattern ('\n') might be part of the raw data block.

Since the size of the data block is variable depending on the settings,
using the MaxInput setting was also not possible. A possibility to set
this dynamically from an epics record would be really helpful and
appreciated!

Using timeouts is the way I did it before and it worked fine with
certain settings. Unfortunately another application required faster
readouts and I had data loss with harder timeouts. This might either be
the fault of our network or the device itself. I observed TCP issues
with wireshark connecting in directly to my workstation and wanted to
eliminate the timeout to make sure it's not my fault.

I just found another method to solve this for now:
I read the header with streamdevice as before. The header information is
then used to configure the NRRD field of an asyn record. The record is
processed after that and reads the raw data block including the
terminator through it's asynOctet interface. The IFMT field is
configured to Binary, so the readout stops immediately after the
expected number of bytes is read. The raw data is then processed with an
aSub record as I did before. This seems to work fine.


Thanks and best regards,
Christoph


On 07/18/2018 10:46 AM, Dirk Zimoch wrote:

Hi Christoph,

No, StreamDevice cannot (yet) dynamically change the number of
expected bytes. But don't worry.

In such cases, I wait for the read timeout. That means InTerminator
empty, MaxInput not set, ReadTimeout set to something reasonable (e.g.
the smallest value that does not cause data loss x2).

Also if the device sets EOI on the last byte (most GPIB devices do),
input will terminate immediately on the last byte, even before
ReadTimeout expires.

Often I know the number of bytes because the array size is fixed. In
that case I can set MaxInput accordingly and simply expect a fixed
header.

At least most devices always use the same number of digits for the
length, regardless of the actual length. Thus the first number after
the # is always the same and the header has always the same size. Thus
I can read header and array for example like this (assuming digit
length and 2 byte big endian unsigned integer array data):

in "#8%*8d%02r";

I have planned to add dynamic change of variables for future versions,
but I don't know if it will help. Even if I could do something like this:

in[2] "#%(L)d";
in[L] "%(L)d";
in[L] "%02r";

It would call asynOctett->read 3 times which would (for those asyn
GPIP implementations I have seen) each time address the device as a
talker, read the bytes and un-address the device. The device would not
like that. It would need: address the device as a talker, read 2
bytes, read some more bytes, read the rest, un-address. I think asyn
cannot do that at the moment.

Best regards,
Dirk

(bb|[^b]{2})

"To be or two not be?" What's the question? The answer is (..) ;-)


On 17.07.2018 18:26, Christoph Schroeder wrote:

Hi all,

I have a device which uses common SCPI commands. The measurement data
uses the "DEFINITE LENGTH ARBITRARY BLOCK RESPONSE DATA" format
described in IEEE 488.2-1992 (section 8.7.9). This format contains a
header followed by an arbitrary number of bytes. The number of bytes is
part of the header.
Is StreamDevice able to handle this format or rather is StreamDevice in
general able to dynamically parse input data resp. react on the content
of the header for further parsing as necessary  in this example?

Best regards,
Christoph


--
(bb|[^b]{2})


________________________________

Helmholtz-Zentrum Berlin für Materialien und Energie GmbH

Mitglied der Hermann von Helmholtz-Gemeinschaft Deutscher
Forschungszentren e.V.

Aufsichtsrat: Vorsitzender Dr. Karl Eugen Huthmacher, stv.
Vorsitzende Dr. Jutta Koch-Unterseher
Geschäftsführung: Prof. Dr. Bernd Rech (kommissarisch), Thomas
Frederking

Sitz Berlin, AG Charlottenburg, 89 HRB 5583

Postadresse:
Hahn-Meitner-Platz 1
D-14109 Berlin

https://www.helmholtz-berlin.de

--
(bb|[^b]{2})


________________________________

Helmholtz-Zentrum Berlin für Materialien und Energie GmbH

Mitglied der Hermann von Helmholtz-Gemeinschaft Deutscher Forschungszentren e.V.

Aufsichtsrat: Vorsitzender Dr. Karl Eugen Huthmacher, stv. Vorsitzende Dr. Jutta Koch-Unterseher
Geschäftsführung: Prof. Dr. Bernd Rech (kommissarisch), Thomas Frederking

Sitz Berlin, AG Charlottenburg, 89 HRB 5583

Postadresse:
Hahn-Meitner-Platz 1
D-14109 Berlin

https://www.helmholtz-berlin.de

Abonnieren Sie unseren monatlichen Newsletter!<https://www.helmholtz-berlin.de/aktuell/pm/newsletter/>
Subscribe to our monthly newsletter!<https://www.helmholtz-berlin.de/aktuell/pm/newsletter/index_en.html>

References:

Parse IEEE 488.2-1992 Block format with StreamDevice? Christoph Schroeder

Navigate by Date:

Prev: Compiler error on Debian Stretch arm Florian Feldbauer

Next: Re: Compiler error on Debian Stretch arm Ralph Lange

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: Parse IEEE 488.2-1992 Block format with StreamDevice? Christoph Schroeder

Next: Rotating Image in NDPluginPva plugin Shen, Guobao

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