VI Server Problem - Upgrading 5.0 to 6.1

[Thompsonta]

Hello everyone,

I'm a few rusty months out of my Basics I/II course, so I may be over my head. I've come to work with some proprietary VIs on a Labview 5.0 testbed, and have had problems attempting to upgrade to LV 6.1.

The old testbed involved computer A running hardware-controlling VB code. It ran Labview 5.0 remotely from Computer B. Computer B ran the DAQ suite, and the top-level VI from Computer B called an ActiveX-handling VI onto Computer A, which manages communication.

My problem is running the VI remotely, though it looks fairly standard, as described in help files. Open Application Ref -> Open VI Ref -> Invoke Node/Run VI. My problem with the 6.1 system is that the remote system (my new "A") gives me an Err
or 97, telling me that a null Refnum is being passed. I may misunderstand the related help topics, but nothing I've seen solves my problem.

I see two avenues right now, and there may be more yet:

1. Running Labview 6.1 remotely is not valid - I need a separate LV license for the separate PC. The only thing that strikes is that MAX cannot open a VISA connection between my new computers, though I didn't know that a TCP/IP VI server required it.

2. There may have been some inadvertent changes migrating from 5.0 to 6.1 that I'm not aware of.

Any help that you could give would be greatly appreciated. Thanks for your time.


Trevor Thompson

[JRA]

You're correct about the VIs to call. And this does work in LabVIEW 6.1. I run it quite often myself. Now, I have heard of a similar situation like yours. A developer was receiving "Error 97. LabVIEW: Null refnum was passed in as input." It was occuring because of a problem with his OCX file. It turned out he had inadvertently put two versions of the OCX file on his machine and Windows was getting them confused.

This may not be your issue, but it could offer you a clue. Also, make sure that your settings under Tools>>Properties are correctly configured to run the remote VI. Let me know if you find anything else out.

[Thompsonta]

Thanks very much for the help. It was a heck of a lot closer than I was aiming myself.

I think my hardware simulators are causing other problems, but I think this problem in particular is solved. There were .ocx duplicates (same version) initially, but removing them didn't help. Removing the registry entries for the VB-registered .oca files didn't help either.

It turns out that the Null refnum problem was the ActiveX control, like you were pointing out. Reading some other discussions, I noticed that ActiveX creatables require the refnum to be generated through Automation Open. That lead to a Err 3005 problem which kept telling me that my creatable object wasn't in fact creatable, which hung me up for a few days.

I went through and unregiste
red/reg-cleaned everything and re-registered my .ocx/.dll suite. As with so many other things, simply blowing it all up and putting it back together worked. I'm too far behind to try to duplicate the problem to really drive at what was going wrong.

Thanks again for the help.

[JRA]

Now that's some impressive troubleshootin! I'm glad you got it up and working. Good luck with your application.