03-28-2014 01:33 PM
Shinton,
I am in the process of escalating this issue to our R&D resources. The fact that this solution works for around 2 minutes and then stops makes it a little different than the original issue. Can we verify that we have all the patches and updates installed for 2012? Additionally, can you navigate to the address localhost:3580/dumpinfo and attach a copy of the resulting webpage or text file?
Thank you.
03-28-2014 03:03 PM
Thanks again for the help. You're right, this has turned out to be a somewhat different issue.
As for the patches and updates, I don't have everything possible installed but I think I do have everything relevant. When I run the NI Update Service it says that I need NI-488.2 3.1.2, NI-SCOPE 3.8.x, or NI-Sync 3.3.6, but I haven't downloaded them because I never use these tools. There are also many "upgrades and service packs" that I don't have because honestly my hard drive can't spare the 30GB needed. Also let me say again that I'm not using SP1. Just plain LV2012.
Out of curiosity I am upgrading the NI System Configuration to 5.6 and NI-Serial to 4.0 on one of the two PCs since I do use the Serial functions and the System Configuration sounds like it might have some bearing on the problem at hand. I'll post again if it changes the situation at all.
Unfortunately I don't think that attaching a copy of http://localhost:3580/dumpinfo would be much help because it can't find the webpage. This is the same problem as before.
03-28-2014 03:51 PM
I mentioned in my previous post that I was going to update a few LV modules. This effort failed. Remember I mentioned in my original post (on 03-25-2014 03:36 PM) that the NI System Web Server service wouldn't stop? On my very fast computer it will usually stop, but on my slower one it never succeeds unless I set the service to not start on boot and I restart the system. That is how I was able to remove the NIAuth files the first time. Well these components are reporting that they can't update on my slow PC because that service (niSvcLoc) can't be stopped. So I guess that idea was a dud. Any suggestions?
03-28-2014 05:02 PM
I found a KB that indicates the niSvcLoc service is integrated into the NI System Web Server as of LabVIEW 2010.
What Is the NI Service Locator and How Do I Troubleshoot It?
As you have older versions of LabVIEW installed I am not sure how these play together. Can you attach a screen shot of the NI services on the afflicted machine(s)? The more info I have to escalate with the more like we are to return with relevant suggestions.
03-31-2014 01:20 PM
Hi again,
Here is a screenshot of the services running on the machine I didn't attempt to update:
Here is a screenshot of the services running on the machine I did attempt to update:
you will notice that the NI System Web Server doesn't even exist any more! I'm not sure what happened to it, it appears that the NI updates have helped me just as much as the Win7 updates...but at least if I try to run more updates then I won't have trouble with the service not stopping 🙂
However, the original problem of the compile server not being reachable (either by the compile worker or via internet browser) is still present on both PCs.
04-01-2014 12:37 PM
Thank you for the additional information. We will get this escalated as quickly as we can. In the mean time, I ran across a similar forum post this morning in which a customer upgraded from .NET 4.0 to .NET 4.5 to make a similar issue go away. What version of .NET are you using on your machines? It may not be related and may not have an impact but it is something to look at while we escalate.
04-01-2014 01:51 PM
Hi Jeff,
I have plenty of .NET versions:
2.0...
3.0
3.5
4
4.0
4.5
hopefully one of those works 🙂
04-01-2014 01:56 PM - edited 04-01-2014 01:57 PM
You may remember that the trigger for all this was a Windows 7 update, so I just checked the Windows update history and among the long list of updates there are several security updates to .NET 3.5.1 and 4.5.1, but no other .NET references in the log on that date. So I guess it could be .NET related, but I don't see an apparent smoking gun on this one.
04-02-2014 12:25 PM
the MAX instalation logs indicate that the last instalation of Xilinx tools installed were version 13.2 where we would expect 13.4.
Can you start the compile worker by going to Start >> Programs >> National Instruments >> FPGA Compile Tools >> Compile worker. Once started and in the system tray can you right click the icon, select Open, and list all of the versions under Registered Capabilities.
04-02-2014 12:36 PM
Hi again Jeff,
When the compile worker can't connect to the compile farm then it doesn't list the registered capabilities. It just has a blank text box.
But I don't think this is of concern. I installed the Xilinx 13.2 tools specifically for a special FPGA target that we are using. Other development PC's that I configured identically to the two that were Win7-updated (and therefore broken) list the following registered capabilities:
('Xilinx 10.1' 'Xilinx 13.2' 'Xilinx 13.2 (64-bit)' 'Xilinx 13.4' 'Xilinx 13.4 (64-bit)')
And the registered capabilities shouldn't have anything to do with the ability to connect to the compile farm, should it?