AnsweredAssumed Answered

VRf-A_BINBLOCK

Question asked by VRFuser on Jul 20, 1996
send q VRf-#A_BINBLOCK vrf mccrory@esmsun.gtri.gatech.edu ww

from: Greg Goebel / HP-MXD
      gvg@lvld.hp.com / 970-679-3030 / FAX 970-679-5971
to:   Russ McCrory / VRf
date: Sunday, 21 July 1996 1358 MDT

RM:

The 8720 calibration demo program does not work for me.  When I run it an
error occurs on the following Direct I/O box:

   WRITE TEXT "OUTPUTCALC01;" EOL
   READ BINBLOCK X REAL64

dialog box is then shown with the following error message (note the
misspelling of "elemen"):

"Int32 value is out of range for number of bytes to allocate.  This data
container is limited to 26843455 elemen"

Any advice on how to get this to work would be most appreciated.

GVG:

Useful information to know would be:

% What kind of HPIB card is being used.
% Firmware revision of the 8720C and options (if applicable).
% Revcode on 8720C VEE driver.
% A bus trace of a program run up to the failure.

RM:

00000  *  0x55   U    ! MTA
00001  *  0x3f   ?    ! UNL
00002  *  0x30   0    ! LISTEN 16
00003  >  0x2a   *  =20
00004  >  0x52   R  =20
00005  >  0x53   S  =20
00006  >  0x54   T  =20
00007  >  0x0a  <LF>=20
00008  *  0x55   U    ! MTA
00009  *  0x3f   ?    ! UNL
00010  *  0x30   0    ! LISTEN 16
00011  >  0x52   R  =20
00012  >  0x45   E  =20
00013  >  0x43   C  =20
00014  >  0x41   A  =20
00015  >  0x34   4  =20
00016  >  0x0a  <LF>=20
00017  *  0x55   U    ! MTA
00018  *  0x3f   ?    ! UNL
00019  *  0x30   0    ! LISTEN 16
00020  >  0x4f   O  =20
00021  >  0x55   U  =20
00022  >  0x54   T  =20
00023  >  0x50   P  =20
00024  >  0x43   C  =20
00025  >  0x41   A  =20
***********************
00027  >  0x43   C  =20
00028  >  0x30   0  =20
00029  >  0x31   1  =20
00030  >  0x3b   ;  =20
00031  >  0x0a  <LF>=20
00032  *  0x3f   ?    ! UNL
00033  *  0x35   5    ! MLA
00034  *  0x50   P    ! TALK 16
00035  <  0x23   #  =20
00036  <  0x41   A  =20
00037  <  0x04  <EOT>
00038  <  0xb6   =B6  =20

GVG:

Goran's right, this is the old IEEE-768 block-transfer problem (#A) problem
(about the third resurrection of it ... me and the lab don't seem to connect
on this one very well, hopefully this time we nail it).

Anyway, I have a Measurement Coprocessor program that I use to generate a
#A block, which has the format:

  #A<16-bit-integer><byte><byte> ... <byte>

I tried it with VEE 3.2 on Win95 and READ BINBLOCK blew up in my face with
the error as above.  So then I created a workaround:

   +----------------------------------------------+
   |                 Direct I/O                   |
   +------------------------------------------+---+
   | READ TEXT w CHAR:2                       | W |  Get "#A".
   | READ BINARY x INT16                      | X |  Get number of bytes.
   | READ BINARY y REAL64 ARRAY: IntPart(X/8) | Y |  Get array.
   | READ BINARY x BYTE ARRAY: 2              | Z |  Get trailing bytes.
   +------------------------------------------+---+

Now this is only a first-pass workaround, because I have some uncertainties
about how the IEEE-768 block is formatted ... I presume the 16-bit integer
that gives the length is MSB first, and gives the number of bytes -- however,
it's returning a value (0x04b6) that isn't a multiple of 8 (as I would expect
for a REAL array, where each value is 8 bytes), leaving a remainder of 6, and
the only thing I can think of is that the value includes both the 4-byte
header and a 2-byte EOL sequence (CR-LF maybe?).

Anyway, it would be nice to know where that excess count is coming from, and
pulling the last few bytes into a byte array and then examining them would do
the trick.  (Actually, you might need to adjust the byte-array count to 4 or
6 to keep from getting timeout errors.)  A little quick probing will get us
the exact and proper answer.

Please stay in touch.

[<>] regards -- gvg

Outcomes