Generic I/O error with ESP301 via GPIB

[johng23]

I am controlling the Newport ESP301 through GPIB and getting error 6: generic I/O error.  It seems to happen at completely random times.  I will run a scan, which goes through a for loop up to 1000 times, and communicates with the instrument during each iteration through a few different subVI's.  Sometimes a scan will complete fine, but other times I will get this error in any of two different subVI's, in either the read or the write operation.  I even tried power cycling the instrument and then performing the exact same actions and starting the exact same scan to see if the problem was repeatable but just complicated.  It is not.

It is also not a bad connection because another instrument is connected in series and has never given me a problem.

Anyone know any secrets about the ESP that can cause this?  Attached is one of the subVI's where the error has occured. 

The only thing that seemed like a potential problem to me was that both the read and write mode are both default, but the instrument actually requires a carriage return (which I include in the strings I write to the instrument).  But I played with other read modes, like carraige return + EOI, or carriage return only, and it didn't seem to help.  And anyway, the fact that the communication is usually working seems to imply that the mode is ok.

Thanks for looking.

[Albert.Geven]

Why not using the error connections in this vi and did you know that a driver is developed by newport?

ftp://download.newport.com/MotionControl/Current/MotionControllers/ESP301/Software/Labview%20drivers...

you can get there via the NI instrument driver network.

And one other remark: both gpib functions are in async mode, try it with sync mode, but first use the error wire to see what happens better.

[johng23]

Thanks for your answer.

To respond to those two points:  The error out terminal only tells me that I have error 6: generic I/O error, and prevents the pop up window from appearing and telling me the same.  Am I missing the point here?

I didn't use the ESP driver because I have used that in the past, and some of the VI's simply don't work, while others give incomprehensible errors sporadically.  So I thought maybe I could understand what I'm doing better if I just write it myself.  The commands are simple enough.

Anyway, I have a feeling this is a more basic GPIB problem.  Here's what happened to me today: I was communicating with the instruments fine and had been collecting data for many hours.  Then I suddenly got the I/O error, this time on an SR830 Lock-In Amplifier.  I tried power cycling the amplifier which sometimes fixes this.  After, using the MAX automation explorer, the lock-in would not respond to an IDN query (on address 8).  When I changed the address to 5, it responded perfectly fine and the program started working again.  But the hardware list still showed an unresponsive and unknown instrument connected to address 8. (Similarly, whenever I turn on the ESP it defaults to GPIB address 1.  I use address 7, and after changing it the hardware list will show an unresponsive instrument connected to address 1 when I rescan for hardware.)

So, how could the instrument no longer respond on one GPIB address which had formerly been working, and then work fine when I change the address?

[Albert.Geven]

The error output is designed to be used as the error input in the next vi. The design is that if an error occurred in a previous vi the state of the program is unknown and first the error should be solved.

Another important aspect especially in IO is that the order of execution is determined by wiring and if it is impossible by wiring you are allowed to use a sequence frame, but in all other cases a sequence frame only limits the parallel execution of a program. LabVIEW can execute a lot in parallel because of this and makes it faster than traditional programming languages.

You don't have to agree but these are the facts.

And the error pop up is something a seous programmer tries to prevent in a program. You should really try to understand why there is a generic IO error instead of looking at a popup.

One possibility is to retry when there is a generic error. But I'm afraid that somewhere you have a race condition in your program.

Anyway I would suggest to add another sequence state to begin with. Wait after you have written to the esp. Instead of doing the wait in parallel with the write.

[johng23]

"You should really try to understand why there is a generic IO error instead of looking at a popup."

Well, what do you think I'm here for?  Whether I should consistently use the error terminals in my code is a separate issue; I'm a novice so I'm sure there are many things I do which are sub-optimal at this point.  I was only saying that the error terminal doesn't seem to help me figure out the reason for the error.  And at this point I still have no idea how to determine the cause.

Anyway I guess I'll try to read about race conditions because I don't really understand those.

Thanks.