VisaNS Session.Dispose() does not release the comport

[Moss]

I have a program which uses VisaNS to prepare a device to receive a program from an EPROM burner.

It opens the port and sends and receives commands to/from the device just fine. Then when it is ready it calls session.Dispose() to close the port and launches the burner to program it.

The problem is that it works one or two times ok, but then I get messages from the launched program that it cannot open the com port.

I substituted the Microsoft SerialPort object for VisaNS and the problem goes away, but the performance is not as good and I get more errors using System.IO.Ports.SerialPort.

With VisaNS I can open and close the serialport as many times as I like within my program.

I'm stumped. The target system is Windows XP. I'm hoping someone has dealt with a similar problem and could help me understand what I can do.

Thanks.

-Moss

[Dayna]

Hi Moss,

What version of the driver are you using?  Are you using Visual Studio?  What version?  Thanks!

Regards,

Dayna P.

Applications Engineer

National Instruments

[Moss]

Visual Studio 2008

DaqMx 9.5.1f2

Again, this problem occurs when I Session.Dispose() the com port and launch a process which tries to open the com port I just closed.

The external program says it cannot open the comport about half the time.

Thanks,

Moss

[Dayna]

Hi Moss,

Are you using VISA or DAQmx?  Session.Dispose() is a VISA call, and you mentioned that you were using VISAns.

Thanks!

Dayna P.

Applications Engineer

National Instruments

[jmoss2]

Yes, sorry NI-VISA5.2

Thanks,

-Moss

[Dayna]

Hi Jmoss2,

What command are you calling when you recieve the exception?  Would you be able to include a screenshot of the exception you recieve?  Additionally, are you using multithreading in your program?  

Thanks!

Dayna P.

Applications Engineer

National Instruments

[jmoss2]

There is no exception being thrown, and there is no multithreading.

Here's what's happening:

My program (written in C#, Visual Studio 2008, dotnet3) opens COM1 and sends and receives certain commands.

When it is ready it closes COM1 using Session.Dispose() which, as far as I know is the only way to close the port. (Correct me here if I'm wrong.)

Now with COM1 closed I start a process (an external C program) which attempts to open COM1. This works around half the time, but the other half of the time the external process returns with a failure code. When I capture stderr from that process I see the error message "Unable to open COM1."

If I try this with System.IO.Ports.SerialPort it works every time.

Thanks,

-Moss

[Curt_C]

Hi Moss,

I had a similar problem with a Visa serial session. I don't know if it will help but...

I created a class that used VisaNS to communicate with an Omega temperature controller.

I got an error when I used  m_session.Dispose().  I tried this instead and haven't had a problem.

//dispose the object
        ~ClassCN3251()
        {
            Dispose();
        }

        public virtual void Dispose()
        {
            if (!this.disposed)
            {
                try
                {

                }
                finally
                {
                    //m_session.Dispose();
                    this.disposed = true;
                    GC.SuppressFinalize(this);
                }
            }
        }

Curt

[Moss]

Thanks for the responses, I was able to solve this problem. I was able to find an additional instance in this legacy software where the port was being opened.

I would expect that if you open a serial port which is already open, one of two things would occur:

1. The attempt would be ignored because the port is already open

2. The attempt would fail. After all the port is already in use.

With VisaNS however neither of these occurs. Instead it accepts the call and opens the port an additional time, as if it pushes the first open and uses the second.

Now when you close the port the second instance is thrown away and the first one "returns."

Anyway, I found the extra open and closed it and the problem is fixed.

I'm not going to lose any sleep over the behavior of VisaNS in this regard--maybe it is intentional.

Thanks,

-Moss