This is far from official, but I recall that the SR510 has been giving people fits for 10+ years. Something to do with the GPIB not being well-implemented. I think it anticipates the timing instead of using the proper 3-wire handshake for GPIB so bytes tend to overwrite the previous one unless you send them very slow. On old computers or slower hardware this wasn't much of a problem, but as computers got faster the bytes came faster and invalidated their assumption.
Why can the instrument driver be validated? Because it sends the correct data across the bus based on the user manual of the device. It was probably written a long time ago as well when computers were slow and the commands worked correctly.
Almost all IEEE 488.1 instruments that I have worked with implement the 3-wire handshake protocol correctly. This is one of the few that I think are not correct.
Solutions involve trying to slow down the bus. You can try a few things:
1) Increase the T1 delay from 500ns to 2us. This will slow down each by by about 1500ns. Not the most slow-down in the world, but it can slow it down some.
2) Try a longer cable. This will add more propagation delays. I have heard of 8m cables (yes, they do violate IEEE spec, but so does this instrument) helping the problem as well. Again, this is not a huge delay added, but it can help.
3) Rewrite your application (or the instrument driver) to write the data slower. For example, instead of writing "abcdefg", change this to:
a) Disable EOI
b) Write "a", write "b", write "c", write "d", write "e", "write f"
c) Enable EOI
d) Write "g"
This will add significant delays which should solve the problem if the problem is intrabyte delays. If it is intra-transfer delays, you can just simply add a delay before or after you write the entire string.
