Re: Parse IEEE 488.2-1992 Block format with StreamDevice?

[Christoph Schroeder <christoph.schroeder@helmholtz-berlin.de>]

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>