Question: VisaInstrument or IPInstrument
occoder opened this issue · 2 comments
Hi
I have an oscilloscope that supports SCPI command over LAN connection.
The driver of this device could be either based on IPInstrument or VisaInstrument.
As I read "Use of VisaInstrument is promoted instead of this." in ip.py, I took VisaInstrument as my base class.
However, I found some strange behavior that needs me have to set persistent=False. The VisaInstrument seems not to support this parameter.
So I'm considering to resort to IPInstrument class.
My question is what is the advantage VisaInstrument over IPInstrument ?
Thanks
@occoder Thansk for the question. Visa is an abstraction over many different types of connection so the most obvious advantage of using visa is that the same driver will work if you connect the instrument over USB/Ethernet/GPIB etc.
Other than that the visa instrument is significantly more used so less likely to have issues.
Regarding persistent you may want to check a few other things. There could be a difference between various visa implementations. I would try the ones from Keysight and National instruments.
I would also check that the scope is running the latest version of its firmware if you have not already done so
@jenshnielsen Thanks for the quick response.
It seems that the Visa driver could smartly figure out the conceret connection details (e.g. socket port number) through parsing the resource description string. I don't understand the mechanism behind it though.
But the 'smart' comes with a penalty, I'm facing almost the same difficulty discribed as "When a VisaInstrument has been instantiated before, particularly with TCPIP, sometimes it will complain "VI_ERROR_RSRC_NFOUND: Insufficient location information or the requested device or resource is not present in the system" and not allow you to open the instrument until either the hardware has been power cycled or the network cable disconnected and reconnected."
The only difference is sometimes pure software retry i.e. reconnection could make through. But not every time.
My hunch is that this might have something to do with the default setting of persistent=True. The instrument not relinquishing the previous connection leads no response to the next connection request.
The exact driver I'm working on is from Keysight.