Why am I getting an intermittent error code 2?

[trosier]

I have a program that is programming a spectrum anlalyzer. It runs ok without error 99% of the time. Occassionally I will get an error code 2 and the program will prompt for stop or continue. The error code is basically stating that there was not a listener at the specified address when a GPIB perform write was trying to write. It is always this error with the same VI and with this instrument. Is there something I am not doing correctly with the GPIB write. Basically what I did was I used the instrument assistant and created a vi that will write to the spec an. I then converted the VI so I could send commands to it that I wanted written externally by wiring the fromt panel with a write string. So basically what I would up with is a GPIB write with the required inputs on the block diagram. Is there something I am missing here? Thanks in advance for any help. Also the analyzer is connected to the PC via a NI GPIB-ENET/100.

[JLS]

Hello,

The NI-488.2 User Manual has the following synopsis and suggestions:

ENOL usually occurs when a write operation is attempted with no
Listeners addressed. For a device write, ENOL indicates that the GPIB
address configured for that device in the software does not match the GPIB
address of any device connected to the bus, that the GPIB cable is not
connected to the device, or that the device is not powered on.
ENOL can occur in situations where the GPIB interface is not the CIC and
the Controller asserts ATN before the write call in progress has ended.

Solutions
Possible solutions for this error are as follows:
• Make sure that the GPIB address of your device matches the GPIB
address of the device to which you want to write data.
• Use the appropriate hex code in ibcmd to address your device.
• Check your cable connections and make sure at least two-thirds of
your devices are powered on.
• Call ibpad (or ibsad, if necessary) to match the configured address
to the device switch settings.

Are any of the above suggestions relevant for you? Just as a note, your ENET\100 is the controller in charge correct? Another question would be is the analyzer a fairly old instrument? If so (and this is a long shot) if you use a delay just before the write operation does this solve the problem? I am hypothesizing that the instrument is perhaps delayed relative to the controller for some reason, but again, I think this is a "long shot." Also, I presume that this write (the string/command) does in fact work correctly some of the time... but you seemed to indicate that it was always this VI with this instrument... were you implying the same write string causes it every time as well?

Repost if you still have this problem and we'll explore some other ideas!

Thanks and looking forward to your repost!

Best Regards,

JLS

[trosier]

JLS - First of all I want to thank you for the time you took to reply to me about this situation. I will answer all of your questions that you have posted. None of the suggestions you have mentioned are relevant to my setup. The GPIB device and address match in my VI. I am not sure about the hexcode in ibcmd being that I have never used/seen that before. I have to assume it is correct because the routine works 99% of the time. I have 3 devices connected to my controller and they are all on. The one thing I can say and maybe this is part of my problem is that I do have another GPIB-ENET/100 that I have setup on another bench that is on the same subnet as the one I am using. It also has a spectrum analyzer connected that is using the same address as the one on my controller. The one I am talking about though is labeled as GPIB0 and the one on the other bench is labeled as GPIB1. Do you think that may cause some intermittent problems? Maybe I should put the other controller on a different subnet just for the sake of getting rid of a variable. Maybe this has something to do with your question about my controller being the controller in charge. The analyzer is a 8560E so it is not an older instrument issue. Anytime this happens it when I am writing to the spec an itself. Again though it is very intermittent and the test runs fine most of the time. The frustrating part is the test that I am running can be quite long and when this problem does happen it forces me to restart the test. Thanks for the suggestions so far.

[JLS]

Hello,

The problem should not be having more than one ENET connected to different instruments. The instrument can have a legal address as long as it doesn't conflict with the board address (ie. index) which for GPIB0 would be 0 and for GPIB1 would be 1, or with the address of another instrument connected to the same GPIB bus. Actually, getting the flash error code 2 on the ENET itself intermittently with a high traffic network was a problem some time ago. If you may be working with an old firmware version, you may be able to update to Revision A.5 and solve that problem, however I don't think this is what you are describing!

Just in case, here is a link to a document noting the problem, which includes a link to download the new firmware:

http://digital.ni.com/public.nsf/websearch/08665F29ED57A929862561CF00575132?OpenDocument

If this is not, indeed, the issue, can you obtain an NI-Spy capture capturing this behavior? This should show us a command by command list so we can see more closely what is happening just before the error! In the event you have not performed an NI-Spy capture, directions for obtaining one are at the following link:

http://digital.ni.com/public.nsf/websearch/8D890EC09B15C05A86256E6F007E3E86?OpenDocument

Note that you can save the capture by choosing File -> Save As... in NI-Spy.

I look forward to your repost!

Thank you,

JLS

[KAW_in_STL]

Hello,

Did you ever resolve this issue? I am having a similar problem now.

Thanks,

Kristopher

[JLS]

Hello,

What problem are you referring to? What behavior are you seeing that is similar? Can you describe your setup, and perhaps get an NI-Spy capture as suggested in the previous posts? If so, I will do my best to help you!

Looking forward to your repost!

Thank you,

JLS

[trosier]

To be honest I have not had the problem for a while. I will admit this, some of my VIs I went back to the traditional GPIB communications instead of using the express VI's and I have not seen the problem there at all. I am not saying that the express VIs are the problem I just have not seen it using the traditional method. Could just be a coincidence.

[JLS]

Hello,

That is interesting. There is certainly nothing wrong with using the GPIB functions directly! If anyone is still having this problem definitely repost!

Thank you,

JLS

[SimonKob]

Hello,

I have the same problem.

I am German and my eng. is not the best. plz wirte in simple words 😎

I also get the code 2 at the gpib interface, but i have that problem since Labview 8.2

When i comunicate the gpib with MAX, it works all the time. After i used the max i tryed it with my VI and it works also. But when I tryed it instead the VI with the EXE is works not all the time.

What could be the problem here?

[trosier]

One thing I have changed since writing this post was in every instance of my Instrument I/O Assistant I make sure that the Code generation type is set to VISA Code Generation and the Termination character to \n. From investigating this problem I found that I did not have all of my Instrument I/O Assistant instances set up the same way. After correcting that problem I have not had the error.