VISA TCPIP is difficult to be established

[weitong]

I am writing a program to set and read an Oxford iTC instrument through ehthernet interface.

The problem is, once I stopped the program and run it again, I get timeout errors.  Every time, I have to try several times Run/Stop to get it work again.

In the program, I have VISA clear and VISA clean (TCPIP) in the beginning,  and then VISA Open.

I checked the TCPIP connections in cmd window by "netstat -n". If runs correctly, I got status "Established", otherwise "TIME_WAIT" or "CLOSE_WAIT".

How to solve this problem?

Thanks.

WT

LabVIEW 2013 sp1

[Blokk]

In the program, I have VISA clear and VISA clean (TCPIP) in the beginning,  and then VISA Open.

Do you close the resources (VISA ref) properly when you stop your VI running? If you attach your VI (or a snippet, not a screenshot!) people could have a look and comment what is wrong...

[weitong]

Attached please find the VIs. Thanks.

[Blokk · Accepted solution]

Not commenting (yet) on other possible problems with your VI, first please fix up the stopping mechanism of your VI! What you use now is totally silly: You set the while loop to run forever, and I guess you use the red "Abort Execution" button on the VI's toolbar at the top to stop your VI. This is not good. In this way your code (VISA Close function) outside of your while loop will not run at all, since you just abort the execution. Therefore, your VISA resources are not freed! Delete that False boolean connected to the stop condition of the While loop, and put a Stop button there. Do NOT use the red Abort button any more!

[weitong]

Yes, that is a silly mistake. I have corrected this with a boolean control button. Now it seems OK with Run/Stop.

But I have a new problem with this program. In this program, I am Reading and Configuring iTC repeatedly. After a couple of times,  error "timeout" happens. If I disable the configuring (in 4th frame), the program runs smoothly.

I don't know whether it is a program problem or the iTC instrument defect?

Thanks.

WT

LabVIEW2013sp1

[Blokk]

Well, you should report errors in your VI, or at least put an error indicator somewhere. When error happens, you can see the description and the source of it. Maybe you try to set "too fast" the device? As I see you also started to modify the driver VIs? This is not related to your timeout error problem, but for example why you limit the precision for the PID parameters to 1 digit after the dot (see the snippet below)? I also do not understand what you try to do with this VI, why you repeateadly change the P and I parameters using random numbers??? If you have a PID control, you should tune the system, and usually you use fixed PID parameters. Do you know what you are doing?

Could you provide a link for this instrument, so we could see the "official" drivers if there is any, maybe they show some example code how to communicate properly with the instrument?

[weitong]

I wrote all the subVIs myself. ( In the beginning, I used 4 digits fot PID parameters. Because of the frequent timeout errors, I limit the precision to 1 digit to see whether the digits caused this toruble.  )

During the test, I used the "Probe" tools to track the errors.

This Oxford iTC instrument is a temperature controller. In the real program,  there is a user-defined PID table for different temperature setpoints. Here the random P is just for testing this problem.

This is the official support web for this instrument (One has to register for downloading. I have attached the driver below.)

http://mymercurysupport.com/

Product information

https://www.oxford-instruments.com/products/cryogenic-environments/measurement-mercury-electronics/p...

**Attached is the official driver. (Their driver is not easy to use for our applications. That's why I give up using their driver after a few days trying)

WT

LabVIEW2013sp1

[Blokk]

I do not understand why you say you find their driver difficult to use? I downloaded the driver, unzipped it and copied under my LabVIEW's instr.lib folder to get the palette set with driver VIs. This driver looks pretty nice and structured in a logical way, even using polymorphic VIs. You should really use this official driver before trying to hack together an own driver... There are even examples!

[weitong]

They are not good for comlex readings. For example, in the above my program, I need to monitor many parameters. By using their driver, it will be a very long VI chain and the reading speed is getting very slow per cycle.

[Blokk]

---

@weitong wrote:

They are not good for comlex readings. For example, in the above my program, I need to monitor many parameters. By using their driver, it will be a very long VI chain and the reading speed is getting very slow per cycle.

---

And, what is the problem using the driver VI? If you use the driver properly, it should not take more execution time than your "home made" code I feel... Besides I repeat, setting the PID parameters in a while loop is just silly, no idea why it is a way for timeout error testing? You are not supposed to change PID parameters with the same rate as data readings... If you need to change parameters during runtime, you should use a State Machine to separate different configuration steps from the pure data acquisition code part...

What kind of parameters do you need to read? What is the required sampling frequency? Could you test the following VI (does it give you all parameters)?