I'm trying to use Network Streams. I had no problem on my Windows 7/LabVIEW 2011 system at work. However, when I tried the same code on my laptop or home desktop (both Windows 7/LabVIEW 2011), I got an Error 42 on trying to create the Reader Endpoint.
I'm very puzzled! The code is similar to that in the examples, it works on one PC, but fails on two others. I figure it's something to do with either the LabVIEW setup or a Windows configuration. I thought they were all set up similarly, however.
Does anyone have an insight into this error? This is the code that fails ...
Solved! Go to Solution.
Hi, I tried to search the error 42 in the list of "Network Streams Error Codes" but I think is too generic to show up there. I was looking at the article "Lossless Communication with Network Streams: Components, Architecture, and Performance" and I can't tell from here but It seems like you are wiring an empty string constant at the writer url terminal, if that's the case I would advise to wire a constant of the expected datatype to the data type terminal and eliminate the empty string constant.
Plus, make sure that nothing is affecting the communication like the antivirus or the firewall. Disable them and check if that's the cause of the error, here is another helpful article: Recommended Firewall Settings When Using Network Streams.
Yes, I am wiring an empty string to the "data type" input, but that's perfectly legal (it works on the "system that works"). I agree that it is probably a "Firewall thing", but figuring out how the firewall is configured is not easy ...
I've done more experimentation, and it continues to be a puzzle. First, there is some Firewall information in NI KB 5BCF43RY: Recommended Firewall Settings when using Network Streams. Second, there appears to be significant distinctions in the Firewall rules for the following two classes: Windows 7 (64-bit) PCs vs Windows XP PCs, and Windows 7 PCs in a domain vs Windows 7 PCs on a home network. Here are some findings.
1) The KB article notes that the PSP locator, lkads.exe, needs a Firewall Exception. Indeed, I "fixed" a problem where a remote reader (executable) on an XP machine could not be contacted, even though the application had a Firewall exception, because the lkads exception was missing -- adding it allowed the connection to be established.
2) On my Windows 7 system at work (short-hand for "connected to a domain"), I am able to use Network Streams with no problems (in particular, I never get an Error 42 when trying to create a Reader Endpoint). However, this system does not have a Firewall exception for lkads.exe (I even searched the Registry to be sure I didn't miss it), though it is installed.
3) All of the machines in question (whether they "work" with Network Streams or not) have the same LabVIEW 2011 VI Server options, namely TCP/IP enabled with the standard port of 3363, the local host (and, for some, the local subnet) on the Machine Access list, and "everything" on the exported VIs list, with the User and Group Access list blank. All the machines have a Firewall Exception registered for LabVIEW 2011 (done automatically when LabVIEW had TCP/IP enabled, and asked if I wanted to unblock the Firewall, I think).
So what is the difference between a Windows 7 machine at work ("on the domain") and one at home (on a local network, no domain controller, no Active Directory)? It doesn't seem likely to be the program Firewall exceptions, since LabVIEW 2011 is present in both, and lkads is absent in both. Maybe it's specific ports? [Yike -- it was hard enough figuring out the program exceptions -- where do I go to find, and save in a list, the Port exceptions?].
I would recommend talking to IT, there could be a network restriction at your work. The computers can be properly setup but if the network administrator is not allowing the communications then you'll be stuck in a wild goose chase. Like I mentioned before, disable all security and run the vi if you get the same error that would confirm the my theory. Now, for the port exceptions check the next article: Open a port in Windows Firewall.
Good suggestion (about talking to IT), but it is precisely at work where this works! When I'm home, on my laptop or desktop, connected to a "local" area network, I get this problem! Note that the stream being opened is to a blank (LocalHost) machine, so you wouldn't think "network errors" would be a problem. And why such an "unhelpful" error message?
I did try, at home, to examine my Windows 7 Firewall settings, and even turned the firewall off. I'm continuing to play around with this, but I'm very surprised that noone else has responded with "I got it to work" or "I've seen the same thing". I know Network Streams are "new", but would think that someone out there has tried them and been successful.
Another thought which I'll try tonight is to simply run the NI Example code at home. It would be much more of a "wakeup call" if the Examples do not run, either ...
P.S. -- There is something really "magical" about Network Streams. I just submitted a little piece of code to NI that has a Create Network Stream Reader Endpoint. If you open and edit this VI on Windows 7 using LabVIEW 2010, it does what you expect (namely you can add wires, take them away, clean them up, etc.). If you try exactly the same thing using LabVIEW 2011, and just edit the code (forget about trying to execute it), LabVIEW will crash, giving the "We're sorry for the Inconvenience" message. The NI Engineer who has been helping me has verified that the crashing behavior is robust and unexpected -- a CAR may be in the offing.
OK, I'm now home, and doing some "experiments". Here's the situation:
Home PC, Windows 7 (64-bit), fully patched. LabVIEW 2010 and 2011, latest patches. Ethernet adapters configured as "Home".
Work PC, Windows 7 (64-bit), fully patched. LabVIEW 2010 and 2011, latest patches. Ethernet adapters configured as "Domain" (PC authenticates to the domain).
Because I've discovered some quirky "features" in the implementation of Network Streams for LabVIEW 2011 (reported to NI), I'm going to test using LabVIEW 2010, using the Host Fullness and Target Fullness example code that ships with LabVIEW.
On the Work PC, code runs flawlessly. On the Home PC, each Create Network Stream Endpoint VI causes an Error 42, and the program does not run.
I examine the Firewall settings (using Windows Firewall with Advanced Security applet). On Work PC, there are 4 LabVIEW 2010 exceptions, two each for Domain and Public profiles, two each for TCP and UDP protocols. All are "Allow everything".
On Home PC, there is a single exception (which I just created -- didn't seem to be auto-created when I installed LabVIEW and enabled TCP in "Options"). This exception is for all profiles, all protocols, all ports, "Allow everything".
Note that what would seem to be the "more restrictive" setting, namely the Work PC that may have restrictions imposed by the Domain Controller, works, while the Home PC, which I think I control completely, fails. And the code that fails is the example code shipping with LabVIEW!
Anyone have any suggestions? Has anyone tried to run this example and not gotten an Error 42 failure? If so, what can you tell me about the firewall settings? [Note -- I asked an NI Support Engineer who was helping me with the above-mentioned LabVIEW 2011 Network Streams "bug" if he'd heard of this particular error. He hadn't, and reasonably suggested that either (a) it was something peculiar to my home installations, or (b) not enough people had tried Network Streams for the error to have been noticed ...].
One variable I didn't test was the Operating System. I have LabVIEW 2010 installed on a Win XP machine at work, and have LabVIEW 2011 installed in an XP VM running on my home Win 7 system (the one on which the LabVIEW example code throws Error 42 on trying to create the Network Stream Endpoints).
I just successfully ran the example code on my work (on the domain) XP machine (I connected via Remote Desktop). I then fired up the VM at home (VMWare Desktop), and successfully ran the same example code (but on LabVIEW 2011, as that is what is installed on the VM) here. Note that I didn't do anything special with the Firewall on this XP system -- I just installed LabVIEW and enabled TCP on the VI Server Option tab. [It's not as easy to examine the Firewall settings in XP -- I don't seem to have the Administrator Tool applet that shows me the ports, protocols, etc.].
So the Fatal Combination under which Network Streams appear to fail in both LabVIEW 2010 and LabVIEW 2011 are (a) running on a Windows 7 (64-bit) system [incidently, I forgot to say that I'm running the 32-bit versions of LabVIEW], and (b) running on a Home network (instead of on a Domain network). I'm beginning to think this is a real bug (and not something silly that I'm doing) because (a) it is robust and repeatable, and (b) noone has responded saying they've gotten things to work. Maybe next week I'll call NI ...
Well, thanks to some hard work, I now know what is happening, but not yet why it is happening.
From my Home PC (Windows 7 PC/LV 2010 and 2011 system that throws Error 42 when executing the NI Example Target Fullness code) I can Remote Desktop in to my Work PC (similar system, but this one can execute the Example code without errors). Some observations:
1) Viewing all the TCP connections when the system is idle, the Work PC shows four connections to lkads.exe, one of which is marked "Listening", while the Home PC shows none. I think this is precisely the problem ...
2) There does not seem to be an explicit Firewall rule for lkads on the Work PC. I made such a rule for the Home PC, but it had no effect (and there still is no active TCP/UDP port associated with it).
3) The Work PC is in a more "active" LabVIEW environment. For example, there's a camera on the Network and NI Vision routines are installed (IMAQdx), but I don't recall "actively" doing anything special to enable ports or services.
4) This problem seems to only affect my home Windows 7 system(s). If I try to run the Network Stream examples on these home PCs, but in a Windows XP VM, they run fine (so it's not the hardware, per se).
5) Something that would be "interesting" to try (but I'm not sure I want to waste any more time blundering around in the dark, trying to fix this problem) would be to see what would happen to a Windows 7 in a VM on both the Home and Work PCs.
Here's a question whose answer I do not know, but which I think is at the heart of this difficulty. When setting up LabVIEW 2010 or LabVIEW 2011 on a Windows 7 PC, what steps need to be taken so that lkads is automatically started at a service.
I should say that when I set (all of) these systems up, I did a "standard" Install of LabVIEW 2010/2011, also installing LabVIEW RealTime. In the Options, I enabled TCP/IP in VI Server, and accepted the default 3363 port. I installed the OpenG software, which needs to have TCP established, and have also been able to use VI Server on both Home and Work machines.
Well, in the hope that someone is listening, I have another "interesting difference" between my Home PC (where Network Streams throw Error 42) and my Work PC (where the example code runs fine).
If one opens the Administrative Tools and looks at Services, the Work PC shows the NI PSP Locator service (lkads.exe); the Home PC does not. In addition, the Registry of the Work PC has a Value entry under Services called LkClassAds; there is no Data entry LkClassAds in the Registry of the Home PC.
In the installation and configuration of LabVIEW on a Windows 7 PC, some step, or some setting, results in the PSP Locator Service being started on my PC at work, but not on the PCs at home. Any hint on what to do to get the NI PSP Locator Service to automatically start? Is there some LabVIEW .ini setting (oooh, I forgot to look at that!) that needs to be set? If so, why is it set on some PCs but not others (particularly since I thought I set them up similarly)?