------------------------------------------------------------------------------
vxi11_1.03 - 29/01/2007

Some bug-fixes (thanks to Manfred S.), and extra awareness of the
possibility that instruments could time out after receiving a query WITHOUT
causing an error condition. In some cases (prior to these changes) this 
could have resulted in a segmentation fault.

Specifically:

(1) removed call to ANSI free() fn in vxi11_receive, which according to
    Manfred S. "is not necessary and wrong (crashes)".

(2) added extra check in vxi11_receive() to see if read_resp==NULL.
    read_resp can apparently be NULL if (eg) you send an instrument a
    query, but the instrument is so busy with something else for so long
    that it forgets the original query. So this extra check is for that
    situation, and vxi11_receive returns -VXI11_NULL_READ_RESP to the
    calling function.

(3) vxi11_send_and_receive() is now aware of the possibility of being
    returned -VXI11_NULL_READ_RESP. If so, it re-sends the query, until
    either getting a "regular" read error (read_resp->error!=0) or a
    successful read.

(4) Similar to (2)... added extra check in vxi11_send() to see if
    write_resp==NULL. If so, return -VXI11_NULL_WRITE_RESP. As with (3),
    send_and_receive() is now aware of this possibility.

------------------------------------------------------------------------------
vxi11_1.02 - 25/08/2006

Important changes to the core vxi11_send() function, which should be
invisible to the user.

For those interested, the function now takes note of the value of
link->maxRecvSize, which is the maximum number of bytes that the vxi11
intrument you're talking to can receive in one go. For many instruments
this may be a few kB, which isn't a problem for sending short commands;
however, sending large chunks of data (for example sending waveforms
to instruments) may exceed this maxRecvSize. The core vxi11_send() function
has been re-written to ensure that only a maximum of [maxRecvSize] bytes are
written in one go... the function sits in a loop until all the message/
data is written.

Also tidied up some of the return values (specifically with regard to
vxi11_send() and vxi11_send_data_block() ).

------------------------------------------------------------------------------
vxi11_1.01 - 06/07/2006

Fair few changes since v1.00, all in vxi11_user.c and vxi11_user.h

Found I was having problems talking to multiple links on the same
client, if I created a different client for each one. So introduced
a few global variables to keep track of all the ip addresses of
clients that the library is asked to create, and only creating new
clients if the ip address is different. This puts a limit of how
many unique ip addresses (clients) a single process can connect to.
Set this value at 256 (should hopefully be enough!).

Next I found that talking to different clients on different ip
addresses didn't work. It turns out that create_link_1() creates
a static structure. This this link is associated with a given
client (and hence a given IP address), then the only way I could
think of making things work was to add a call to an
vxi11_open_link() function before each send command (no idea what
this adds to overheads and it's very messy!) - at least I was
able to get this to only happen when we are using more than one
client/ip address.

Also, while I was at it, I re-ordered the functions a little -
starts with core user functions, extra user functions, then core
library functions at the end. Added a few more comments. Tidied
up. Left some debugging info in, but commented out.

------------------------------------------------------------------------------
vxi11_1.00 - 23/06/2006

Initial release.

------------------------------------------------------------------------------