VI Server from RT PXI

[.avi file]

Greetings!

      I am working with Kevin (SR 7133458) and recommended to check ini file settings update after enabling VI server. Send link1 and link2.
He mentioned that he has dual cards, which might be causing the issue. He will let us know once he runs the tests with one network card.

Thanks much
Avi Harjani

[kehander]

Here is an update. I have done some experiments with two Windows PCs.

When they are connected to each other through the building's Ethernet (which in turn is connected to the rest of the world), once they are properly configured I can open an Application Reference on one PC from the other PC without any problems.

When they are connected directly to each other through my Ethernet crossover cable and their IPs reassigned to 192.168.0.1 and 192.168.0.2 (and the security settings altered accordingly), I get Error 66 when I attempt to open an Application Reference.

There has never been anything before to suggest that the crossover cable is faulty; I've done all kinds of things with it.

The other possibility that comes to mind is that there is something on the building's Ethernet that VI Server requires to function properly, like a DHCP server or a domain name server. (Both of the Windows PCs can be accessed by name, though the references I was opening used their IP addresses.)

Either way, this suggests to me that if I connect my RT PXI to the building's Ethernet rather than by a crossover cable to the Host PC, I should be able to open a reference with a VI running on it. I'd rather not do that due to security concerns, though.

[Chris_Cilino]

kehander,

I found a KB called How Do I Connect to a LabVIEW Real-Time (RT) Controller with a Crossover Cable?. If you've followed these directions, verify that you can ping the target using the DOS ping command. Also, make sure you have no firewalls turned on. Let us know what you find. Thanks!

Chris C

[kehander]

I GOT IT!

I added two lines to my Windows Hosts file (that's C:\Windows\System32\Drivers\Etc\Hosts):

192.168.0.1 hostpc
192.168.0.2 rtpxi

For good measure I then added "hostpc" and "rtpxi" to the Machine Access list in the VI Server configuration for the Host PC.

And now everything works fine, even the exact same code that gave me Error 66 before! I can finally open a reference on the Host PC from my RT PXI! (FYI, the Host PC has always had a fixed IP address and does not use DHCP.)

If you are not familiar with the Hosts file, it is a means of allowing Windows to associate a name with a particular IP address without using a DNS server. (See Wikipedia.) It would seem that since there is a DNS server supplying my two Windows PCs with names when they connect to each other through the building's Ethernet, it would explain why I did not have this problem when I was not using the crossover cable.

I think this qualifies as a bug in VI Server; as I said, I did not seem to have such problems with LabVIEW 7.1.

Message Edited by kehander on 10-24-2006 11:43 AM

[.avi file]

Hi Kevin:

   That is definitely great news.  VI server is tested to work with cross over cables and static IP. It uses TCP / IP underneath. A spare router might be good to try. In any case if you are able to see the problem with another cross over cable / another router and your fix seems to fix the problem, we would like to know. It would be great if we have a clear, small and narrowed down problem that i can reproduce here in house. If it turns out to be an issue we see in house we make sure that we file a bug report to R&D and fix as needed.

Thanks much
Avi Harjani

[kehander]

After all that messing around with LabVIEW 8.2, I'm now trying to do the same thing with LabVIEW 7.1.1.

...And once again, it isn't working.

Copying emb.llb from that other example to the PXI hard drive and calling it with "call emb.vi" from the Host PC works fine.  If I try to do it the other way around, by opening "call emb.vi" after selecting the RT Target as the Execution Target and trying to access emb.llb on the Host PC hard drive, nothing happens: there's no error message, but the iteration counter does not appear to increase.

It actually looks like when "call emb.vi" tries to use a Call By Reference Node that is actually downloading the VI to the RT target and trying to run it there, which will of course never work.  There's no indication that emb.vi itself ever starts running from the Invoke Node.

LabVIEW 7.1.1 is also supposed to be able to do this, isn't it?

[kehander]

Any ideas? If I reboot the PXI into Windows XP, "call emb.vi" works fine either way.

This is probably just a matter of procedure. For instance, if I start running "call emb.vi" targeted to the RT target, then use the Operate menu to switch the execution target back to LabVIEW for Windows, and then switch the execution target back once again to the RT target, the front panel for "call emb.vi" appears (but stopped), along with the front panel for fglobal1.vi (which is in the "SubVI Waiting to Run" status).

Is this the way it is supposed to work? If not, what am I doing wrong?

[Chris_Cilino]

Kehander,

Did you copy the exact same settings for vi server into 7.1.1? Also, I was under the impression from your earlier posts that this worked in 7.1. What happened? Since it works in 8.2 why are you trying to revert? Why not just upgrade?

Chris C

[kehander]

(Aie, all my E-mail messages from the last week got sucked into a hole I just uncovered...)

In my earlier posts, I meant to say that I could open an application reference between my PXI and Host PC over a crossover cable when both were running LabVIEW 7.1.1 in Windows XP, which is something I could not do with LabVIEW 8.2 without modifying my Hosts file.  But I am now encountering the problem again in attempting to open an application reference on the Host PC from LabVIEW RT (running on the PXI).  As far as I know the settings are indeed the same.  (It could be the "strict checking" option, perhaps, but I think I tried changing that already.)

I'm not really using any of LabVIEW 8.2's features at this point, and the long start-up time is getting on my nerves.  Specifically, when I try to connect to the RT target in a project, it takes a long time before the connection window appears, probably because I am trying to run a very large VI with many dependencies.  If I'm not mistaken, there's no easy way around that short of compiling the VI into an RT executable, which I am relcutant to do as I am still making changes to it.  (Dragging and dropping the contents of the project's Dependencies tree to a new "Dependencies" folder under the RT target in the project only speeds things up a little.)  Perhaps I should start a new thread about this?

[Chris_Cilino]

hey Kehander,

It's probably a good idea to start a new thread on that issue.

Chris C