Port 0 configuration error number 37

[GP]

Hello,

I'm running a Labview routine which talks to two instruments, one via serial RS232 and the other through
GPIB. It logs back values from these instruments about once a minute over several days.

The routine uses frames to sequentially address these instruments and read back values to graph and file. It was written with standard Serial and GPIB write and read modules (in each frame), basically sending the appropriate instrument command.

The problem I have is that it can work flawlessly for days logging data and then it will throw up an error (Port 0 configuration error number 37). If the prompt box (asking whether to continue), comes up when there is noone there, the routine will hang (and data lost).

Does anyone know
why this might be happening (doesn't always happen) and any work round? Is there a way of stopping promt boxes from appearing and just re-trying the connection again if it occurs?

A similar problem of occasional GPIB read error (EABO 6) was cured by increasing the timeout settings slightly. This may not be relevant.

PC running Labview 5.1 and OS =Win95
Standard GPIB write and Read vi,s,
Standard Serial write and read vi,s

Any help gratefully received.

GP

[Stuart_R]

Hi GP,

Have you read this forum thread?

http://exchange.ni.com/servlet/ProcessRequest?RHIVEID=101&RNAME=ViewQuestion&HOID=50650000000800000068370000&ECategory=LabVIEW.LabVIEW+General

Does this help at all?

Is it possible to post your code?

Kind Regards

StuartR

[Brian_Powell]

I'm not sure this is relevant. That other thread was talking about getting the serial ports to work at all. In this case, "GP"'s serial ports are working; they just don't stay working.

The part about GPIB is interesting. Is your application slowing down over time? I wonder if you've got a slow memory leak that eventually slows the machine to a crawl.

The error dialog is probably coming from somewhere in your program. You could remove this dialog and just trap the error 37 yourself. (E.g., you could try closing and reopening the serial port when this happens.)

Finally, you might consider a more robust operating system. Windows 95 is not the best choice for programs that need to run over long periods of time.

I hope this helps. Let us kn
ow what you find.

Brian

PS: The other thread was interesting reading for history's sake. The "Save our Serpdrv Foundation" did not succeed. 😉

[GP]

Hello,

Thank you for both your replies.

Yes, the serial ports are working OK and you're right its just that the problem occurs occasionally. I might run the routine over a weekend (say ~3 days) and it will work fine, no errors and all data safely to file. I'll run it again another time and find I got an error (usually in the middle of the night!).

The slowing down question is interesting. Sometimes I do think the computer is slower after running the application e.g. loading data in to Excel etc. takes ages. A restart usually sorts this out. There was a strange problem running Labview routines on another platform (HP Brio, Win 98), which resulted in a time lag (the computer clock slowed down). This appeared to be a hardware thing though (tried different operating systems) as it doesn't do it on the Win 95 Dell machine (current platform).

No, the routine appears to work OK on the Dell except for this error.

The routine was one of the first I wrote so it is quite intuitive in structure. Frame cell to write to instruments followed by frame cell to read back etc. There are frames for each instrument. The frame sequences run in a loop which executes after every minute. Logging is to file and screen chart with elapsed time and instrument values.

I'm interested in the closing and reopening of the serial port if this happens. How would you implement this simply in Labview? Would you need some sort of conditional linked to the error codes of the serial module? Is there a good text on this. I must admit I haven't delved too deeply into the detail of managing errors properly in Labview.

The serial instrument in this set up is an environmental chamber. So its reading back values from I think a Eurotherm module. I don't know whether there could be an error with this?

Its a bit of a problem to test a solution to this as it takes several days to run it and I guess we'd just need to keep repeating it and just see if the problem no longer occurs.

Let me know your thoughts. I appreciate all your replies.

Best Wishes

Geoff (GP)

[Brian_Powell]

To implement the close and reopen, you first have to find the place where the error is happening. This should be reported in the error dialog that comes up. You might also search your code for the use of either the "Simple Error Handler" or the "General Error Handler".

You want to replace this error handler with code that does a close, an open, and then tries the last command (that got the error) again.

You need to code this somewhat carefully; you probably do want to report any other errors (besides 37) that occur, and you probably don't want to get into an infinite loop if the close, open or retry don't work.

You'll probably want to wrap all of your serial reads and writes into new read and write subVIs that do this extra ch
ecking.

I'll also encourage you again to try to confirm that you aren't running out of memory, and I'll encourage you again to use a more up-to-date operating system such as Windows 2000 or XP.

Good luck.

Brian