06-12-2018 11:12 AM
I am using a fresh GPIB/ENET 1000 for communicating with my instruments using a measurement system called Labber based on python.
Also note that there are other instruments connected via USB and serial and controlled by Labber as well.
There are two types of problems that occur intermittently after a measurement run.
1) GPIB/ENET 1000 becomes unreachable. When this happens, on the cmd prompt, I run: ping 10.9.1.122. This would give the reply Reply from 10.69.1.1: Destination host unreachable. When it is working fine, it would normally show the transmission times (time<1ms TTL=62). In NI-MAX, it shows the red cross on the GPIB/ENET and all the options such as self-test, refresh do not work.
The only way to get it back to working state is either wait for about 40mins or simply turn on/off its power. After this, it starts to work right away. I have also noticed that this problem occurs only after a measurement is made. When left with the ping command indefinitely (ping 10.9.1.122 -t), it never hangs up like that.
It gives this error in Labber: VI_ERROR_RSRC_NFOUND (-1073807343): Insufficient location information or the requested device or resource is not present in the system, which makes sense if the GPIB/ENET is unresponsive
2) The instruments which are controlled by the GPIB go into some type of locked state. It gives the following error:
VI_ERROR_INV_RSRC_NAME (-1073807342): Invalid resource reference specified. Parsing error.
This error occurs intermittently, but always right after a successful measurement when I am giving the next run. After this I have to reconnect with the instrument in the instrument server of Labber, and I will be able to start this experiment. This error when occurs, occurs for all the instruments in the GPIB. Other instruments in USB work fine.
I tried a few options that were there in the Labber communication. When I used something termination character CR (carriage return) for all the GPIB instruments, it seemed to have cut down the frequency of this significantly although it is still there. But the problem (1) persists.
Any suggestions?
Thanks for reading through it.
07-11-2018 08:20 AM
I also use a fresh GPIB/ENET 1000 for communicating with my instruments and have exactly the SAME problem in 2).
I have tested the communication with a USB / GPIB converter and it works fine. I don't have find an other solution for the moment.
07-11-2018 08:31 AM
@chris_anthem: Are you also using a python based communications?
07-13-2018 02:33 AM
No, I simply use the Labview VISA communication blocks. I don't think that Phython is the problem. Are you using old GPIB equipement ? It's my case (they don't know the basic command *IDN?) and I think that GPIB-ENET/1000 gateway doesn't really support them. I typically use 4 instruments (maximum 7), so the number of equipements should not be a problem (GPIB buses support 32 equipements maximum). In addition, I only use the Write VISA function to send 4 parameters to each equipement with a large interval of time (2 seconds beetween 2 equipements and more than 2 minutes beetween 2 cycles). So the communication is extremly low, it can't be a problem of commuication density.
07-13-2018 03:19 AM
I see. I am also using old (but refurbished) instruments, and they work for all the commands I give including "*IDN?" on the VISA panel and my programs. I so far have only tested it with Labber, which is python based and have not used any Labview program yet.
Thanks for the input. Let us share the solution when any of us have it.