sohail chatoor

Should we not make the read_terminator default to terminator? I think we should always call recv until the read terminator has been seen.

Other things I am concerned about: 1) How do we prevent getting stuck in an infinite loop? Maybe we should have a timeout? 2) How do we know the terminator...

I think we should be careful and not assume we are reading before another command is send. As is done in the example code I linked to: 1) We should...

I agree! We do not want to duplicate efforts

Well I still don't like the way partial messages are treated. I think there is a more robust way to do this and one which does not throw away anything....

Jens wrote: "If we ever read more than one reply it is likely due to a non empty output buffer even before whatever write command we did." I'm sorry Jens,...

I have not tested my particular implementation with any instruments. I was trying to explain that there should be more robust ways of dealing with instrument replies. I am sure...

You know what, I think you are right. The case that a reply is send in two chucks is already taken care of in this PR. I am approving this...

Also, I am not raising issues dealing with multiprocessing/threading, but technically I think our solution might be thread unsafe (right?). I am not objecting because for now QCoDeS is single...

After a through review of the Keysight N52xx driver I came to the conclusion that a significant modification and improvement is necessary. The following issues need to be addressed in...