EG&G 5207 VISA control problem

[UndueCause]

I am currently tasked with writing a number of drivers for fairly old machines. At current, I am working with an EG&G 5207 Lock-in amplifier. My attempts to communicate are via a Smart 488 USB to IEEE 488 cable plugged into the device. As I have done on all previous occasions, I attempted my initial contact through MAX. After fiddling with some GPIB parameters (page 65 of the attached PDF, setting 3 was finally used, although I'm not sure I really understand why that choice helped when compared to having no echo), I found myself encountering a rather unusual problem. The machine will read and write as expected, so long as the power cycle takes place after the VI session is opened. Attached are two NI I/O trace captures to illustrate this as best as possible. 

In both cases, the test string sent is a simple request command (so as to test both read and write). The expected result is two integers separated by the delimiter, set as a comma. 

In Trace1 the machine is initially on. MAX is opened and VISA test panel is opened for the corresponding device. O \n is queried at 10:53:33.625 and 10:53:37.328, with the response being a timeout. Upon sending the request the machine shows error 2 (invalid command) on the display. The machine is then turned on and then off. The following two queries give the expected response, with the machine display showing no errors.

Trace2 has the machine initially off and being turned on just before the first sending of the string, with no resulting problems.

Other strings respond similarly, including read-only strings and write-only strings. 

My only thought is that the syntax for the visa open is confusing the machine. The open can still take place with the machine off since I believe the session is actually being opened with the cable.

I have only been using labview for a couple of weeks, and VISA for even less, so my knowledge is pretty limited. I can build a workaround into my driver, since some initial experiments with a VI seem to show that the same holds true with VISA open/write/read/close. I would much rather find the source of the problem though, both to make the driver better and for my understanding of VISA. Any help would be greatly appreciated. If more information is required, I can obviously oblige.

[Albert.Geven]

Check wat happend at visa open, probably à break is sent over the serial line. À cheap interface has its own problems.

[UndueCause]

Thanks for the reply. I am not entirely sure what you mean by "check what happened at VISA open". Is there a way beyond NI I/O trace to view the line? I am not sure what I would even be looking for. Also, does IEEE 488 have a serial line?

Unfortunately, the cheap interface is all I am likely to be given. I would much rather be working with a more reputable brand, but to be fair I haven't encountered any real problems with it so far (mainly working with HP and Keithley machines though). I guess for now I will build the VI with the workaround, and if a solution comes up I will implement that.

[Albert.Geven]

If you look at the IOtrace you see aslr4 as the io address, this is a serial line.

Your cheap interface is a serial line that is converted in the "wire" into 488.

So Labview only speaks serial and the convertor translates this into gpib. more or less.

one possibility is to wait say one second after initialising the interface and then start the communication.

send the sourcecode to see what happens.