Subversion Repositories f9daq

Rev

Details | Last modification | View Log | RSS feed

Rev Author Line No. Line
146 f9daq 1
------------------------------------------------------------------------------
2
vxi11_1.10 - 9/09/2010
3
 
4
Bug fix (thanks to Stephan Mahr): in vxi11_close(), remove the IP address
5
from the global array that keeps track of them so that if the same device
6
is opened again, then a new client is created, rather than it attempting 
7
to use the old one (which was destroyed on the previous close).
8
 
9
------------------------------------------------------------------------------
10
vxi11_1.09 - 7/06/2010
11
 
12
Moved over to bazaar VCS (from RCS).
13
 
14
Makefile cleanups. Fixed signed/unsigned comparisons. Use consistent (and 
15
sane) struct separator spacing in code.
16
 
17
Fix int casting on printf statements to fix new compiler warnings/errors 
18
(thanks to Shouri Chatterjee for pointing this out).
19
 
20
------------------------------------------------------------------------------
21
vxi11_1.08 - 3/09/2009
22
 
23
Added a sanity check for link->maxRecvSize to make sure it's >0. This gets 
24
around a bug in some versions of the Agilent Infiniium scope software.
25
 
26
Changed the erroneous strncpy() to memcpy() in vxi11_send, as we could be
27
sending binary data (not just strings).
28
 
29
Changed a lot of char *'s to const char *'s in an attempt to get rid of
30
pedantic gcc compiler warnings.
31
 
32
------------------------------------------------------------------------------
33
vxi11_1.07 - 9/10/2007
34
 
35
Minor change to vxi11_receive_data_block(), this fn now copes with instruments
36
that return just "#0" (for whatever reason). Suggestion by Jarek Sadowski,
37
gratefully received.
38
 
39
------------------------------------------------------------------------------
40
vxi11_1.06 - 31/08/2007
41
 
42
Bug fix in vxi11_receive(), to ensure that no more than "len" bytes are ever 
43
received (and so avoiding a segmentation fault). This was a bug introduced in 
44
release 1.04 whilst making some other changes to the vxi11_receive() fn.
45
 
46
Many thanks to Rob Penny for spotting the bug and providing a patch.
47
 
48
------------------------------------------------------------------------------
49
vxi11_1.05 - 11/07/2007
50
 
51
Added the ability to specify a "device name" when calling vxi11_open_device().
52
For regular VXI11-based instruments, such as scopes and AFGs, the device name
53
is usually "hard wired" to be "inst0", and up to now this has been hard wired
54
into the vxi11_user code. However, devices such as LAN to GPIB gateways need
55
some way of distinguishing between different devices... they are a single
56
client (one IP address), with multiple devices.
57
 
58
The vxi11_user fn, vxi11_open_device(), now takes a third argument
59
(char *device).
60
This gets passed to the core vxi11_open_device() fn (the one that deals with
61
separate clients and links), and the core vxi11_open_link() fn; these two
62
core functions have also had an extra parameter added accordingly. In order
63
to not break the API, a wrapper function is provided in the form of the
64
original vxi11_open_device() fn, that just takes 2 arguments
65
(char *ip, CLINK *clink), this then passes "inst0" as the device argument.
66
Backwards-compatible wrappers for the core functions have NOT been provided.
67
These are generally not used from userland anyway. Hopefully this won't
68
upset anyone!
69
 
70
vxi11_cmd, the simple test utility, has also been updated. You can now,
71
optionally, pass the device_name as a second argument (after the ip
72
address). The source has been renamed to vxi11_cmd.cc (from vxi11_cmd.c), as
73
it is C++ code not C.
74
 
75
Some minor tidying up in vxi11_user.h
76
 
77
With thanks to Oliver Schulz for bringing LAN to GPIB gateways to my
78
attention, for suggesting changes to the vxi11_user library to allow them to
79
be accommodated, and for tidying some things up.
80
 
81
------------------------------------------------------------------------------
82
vxi11_1.04 - 10/07/2007
83
 
84
Patch applied, which was kindly provided by Robert Larice. This sorts out
85
the confusion (on my part) about the structures returned by the rpcgen
86
generated *_1() functions... these are statically allocated temporary structs,
87
apparently. In the words of Robert Larice:
88
 
89
******
90
Hello Dr. Sharples,
91
 
92
  I'm sending some patches for your nice gem "vxi11_1.03"
93
 
94
  In the source code there were some strange comments, concerning
95
   a commented free() around ... Manfred S. ...
96
  and some notes, suggesting you had trouble to get more than one link
97
    working.
98
 
99
  I think thats caused by some misuse of the rpcgen generated subroutines.
100
  1) those rpcgen generated *_1 functions returned pointers to
101
       statically allocated temporary structs.
102
     those where meant to be instantly copied to the user's space,
103
       which wasn't done
104
     thus instead of
105
       Device_ReadResp  *read_resp;
106
       read_resp = device_read_1(...)
107
     one should have written someting like:
108
       Device_ReadResp  *read_resp;
109
       read_resp = malloc(...)
110
       memcpy(read_resp, device_read_1(...), ...)
111
  2) but a better fix is to use the rpcgen -M Flag
112
       which allows to pass the memory space as a third argument
113
     so one can write
114
       Device_ReadResp  *read_resp;
115
       read_resp = malloc(...)
116
       device_read_1(..., read_resp, ...)
117
     furthermore this is now automatically thread save
118
  3) the rpcgen function device_read_1
119
       expects a target buffer to be passed via read_resp
120
     which was not done.
121
  4) the return value of vxi11_receive() was computed incorrectly
122
  5) minor,  Makefile typo's
123
      CFLAGS versus
124
      CLFAGS
125
 
126
******
127
 
128
Robert didn't have more than one device to try the patch with, but I've just
129
tried it and everything seems fine. So I've removed all references to the
130
VXI11_ENABLE_MULTIPLE_CLIENTS global variable, and removed the call to
131
vxi11_open_link() from the vxi11_send() fn. There has been an associated
132
tidying of functions, and removal of some comments.
133
 
134
Thanks once again to Robert Larice for the patch and the explanation!
135
 
136
------------------------------------------------------------------------------
137
vxi11_1.03 - 29/01/2007
138
 
139
Some bug-fixes (thanks to Manfred S.), and extra awareness of the
140
possibility that instruments could time out after receiving a query WITHOUT
141
causing an error condition. In some cases (prior to these changes) this
142
could have resulted in a segmentation fault.
143
 
144
Specifically:
145
 
146
(1) removed call to ANSI free() fn in vxi11_receive, which according to
147
    Manfred S. "is not necessary and wrong (crashes)".
148
 
149
(2) added extra check in vxi11_receive() to see if read_resp==NULL.
150
    read_resp can apparently be NULL if (eg) you send an instrument a
151
    query, but the instrument is so busy with something else for so long
152
    that it forgets the original query. So this extra check is for that
153
    situation, and vxi11_receive returns -VXI11_NULL_READ_RESP to the
154
    calling function.
155
 
156
(3) vxi11_send_and_receive() is now aware of the possibility of being
157
    returned -VXI11_NULL_READ_RESP. If so, it re-sends the query, until
158
    either getting a "regular" read error (read_resp->error!=0) or a
159
    successful read.
160
 
161
(4) Similar to (2)... added extra check in vxi11_send() to see if
162
    write_resp==NULL. If so, return -VXI11_NULL_WRITE_RESP. As with (3),
163
    send_and_receive() is now aware of this possibility.
164
 
165
------------------------------------------------------------------------------
166
vxi11_1.02 - 25/08/2006
167
 
168
Important changes to the core vxi11_send() function, which should be
169
invisible to the user.
170
 
171
For those interested, the function now takes note of the value of
172
link->maxRecvSize, which is the maximum number of bytes that the vxi11
173
intrument you're talking to can receive in one go. For many instruments
174
this may be a few kB, which isn't a problem for sending short commands;
175
however, sending large chunks of data (for example sending waveforms
176
to instruments) may exceed this maxRecvSize. The core vxi11_send() function
177
has been re-written to ensure that only a maximum of [maxRecvSize] bytes are
178
written in one go... the function sits in a loop until all the message/
179
data is written.
180
 
181
Also tidied up some of the return values (specifically with regard to
182
vxi11_send() and vxi11_send_data_block() ).
183
 
184
------------------------------------------------------------------------------
185
vxi11_1.01 - 06/07/2006
186
 
187
Fair few changes since v1.00, all in vxi11_user.c and vxi11_user.h
188
 
189
Found I was having problems talking to multiple links on the same
190
client, if I created a different client for each one. So introduced
191
a few global variables to keep track of all the ip addresses of
192
clients that the library is asked to create, and only creating new
193
clients if the ip address is different. This puts a limit of how
194
many unique ip addresses (clients) a single process can connect to.
195
Set this value at 256 (should hopefully be enough!).
196
 
197
Next I found that talking to different clients on different ip
198
addresses didn't work. It turns out that create_link_1() creates
199
a static structure. This this link is associated with a given
200
client (and hence a given IP address), then the only way I could
201
think of making things work was to add a call to an
202
vxi11_open_link() function before each send command (no idea what
203
this adds to overheads and it's very messy!) - at least I was
204
able to get this to only happen when we are using more than one
205
client/ip address.
206
 
207
Also, while I was at it, I re-ordered the functions a little -
208
starts with core user functions, extra user functions, then core
209
library functions at the end. Added a few more comments. Tidied
210
up. Left some debugging info in, but commented out.
211
 
212
------------------------------------------------------------------------------
213
vxi11_1.00 - 23/06/2006
214
 
215
Initial release.
216
 
217
------------------------------------------------------------------------------
218