server does not support remote front panels

[jeepers52004]

Hi.  Hope someone has some insight on this.  After updating host computer and cDAQ 9139 from LabView 2013 SP1 to LabView 2014 from dev suite software shipped by NI, I get the "server does not support remote panels" error when attempting to view my remote front panel.  Prior to update, this was working normally.

I've gone through everything in the list at this document, http://digital.ni.com/public.nsf/allkb/C23EF1551D8C52ED86256B140073EE2E, and can't find anything that will resolve the issue.

I've rebuilt the application in LabView 2014 (I've even tried a new simple project with a single loop, one temp, and a remote panel), rebuilt the build spec, and get same error. 

I've republished the web page and verified in the html that it's referencing "CODEBASE="ftp://ftp.ni.com/support/labview/runtime/windows/2014/LVRTE2014min.exe" and that I have, according to MAX, LabView runtime 14.0.1 installed on the host machine.

Has something changed related to LabView 2014 that would cause some new firewall issue as this remote front panel functioned fine with 2013 installed?  I've already added LabView 2014 and all other related apps through the firewall including the web server.  I'm also on a machine that does not have Bluecoat, our company's network/internet security suite installed on it.

Thanks

Michael

[TheCaptain]

Michael,

That first link you posted didn't work--were you referencing this KB? 

If not, I'd give that a try.

[jeepers52004]

Hi,

That is the article I was referencing and I've worked through everything on it.  So I'm missing something or something needs added to the list 🙂

As I mentioned, I verified the HTML file created from the web publishing tool refers to LabView runtime 14 min, I couldn't find an entry in Max for labview runtime version on the cDAQ.  I did see that the remote panel server was version 14.0.0 and not 14.0.1 as the runtime version lists on the host computer.  Could this be the issue?  If so, I was unable to find a LabView runtime engine of 14.0.0 for download for the host nor a 14.0.1 version for the cDAQ.  

I've check communcations with other devices that are typically blocked by IS security policies and I'm having no issues with those devices.  Also as mentioned, I had no problems accessing the 2013 SP1 version of the remote panel prior to upgrading to 2014.  So this leads me to believe either something changed in 2014 that's now blocked somehow or maybe there's a version mismatch that I can't find or can't find a solution to.

Thanks and keep helping, please.  I need to get this working again.

Michael 

[RoboFABIO]

HI,

right now  I've the same problem with a sbrio 9631 (but also with a crio)

I just passed from LV2010 to LV2014 (with a working app).

In explorer I've the errer "Server does not support remote panels"......WTF?

I checked in the "software intallation tab" and I've seen that to use Remote Panels I need a downgrade to LV2010 (see the attached image)...I cant make this downgrade!!!

I already :

1) formatted and reinstalled all on the sbrio

2) Regenerate the webpage with the web application tool

3) Checked if Webserver if working thank to the Original "index.htm" file that is in the sbrio web folder

4) tried to change the web server port (moving to 8081 to be sure that nobody uses this port)

all the above tests was made...with success....but the message continue to appear "Server does not support remote panels"

I need a quick solution....The customer can work with the machine JUST with the webserver!

Regards

Fabio

[ToeTickler]

Have you guys looked at this document: http://ae.natinst.com/public.nsf/web/searchinternal/c23ef1551d8c52ed86256b140073ee2e?OpenDocument

You could try these steps and see if that solves your issue.

[jeepers52004]

The link you copied in doesn't work (probably for the same unknown reason the link I tried to paste in didn't work.)  Is the link you're referencing the same page as the link Kirk L posted above?  If so, I've been through every step in the document without change.  As Fabio posted, I'm also coming from a working app and have been through the setup of the previous software and remote panel without issue.  I've also tried working through my issues on a computer with none of our internal IS software installed and the firewall disabled without success.  

Some of the possibilities I see are that something is different in 2014, maybe something gets altered or corrupted with the 2014 upgrade from an older version install, installation order when installing from shipped media isn't correct, or there is another cause that should be added to the troubleshooting document that Kirk L linked to.

Sort of in the weeds for this topic, but when you install LabView 2014, it creates an entirely new installation including the run time engines without modifying or overwriting the old versions.  DAQmx 14 isn't compatible with the previous version 9.8 but it doesn't install a new version; it overwrites the old version.  So when you update LabView and subsequently DAQmx, you can't just load the old DAQmx drivers along with let's say LabView 2013 SP1 software back onto the cDAQ to troubleshoot or fix an issue.  Any insight on this is appreciated as well as any other troubleshooting ideas for the remote panels issue 🙂

Michael

[ToeTickler]

I found a link for the 2014 Runtime Engine. Download this and see if you still get the same error. 

http://www.ni.com/download/labview-run-time-engine-2014/4887/en/

[jeepers52004]

I already have a higher version installed (2014f3) so this version will not install. 

If nobody else is having this issue, maybe the better questions to ask are who's upgrading from 2013 to 2014 and using remote panels and what processes are being used to update from one version of LabView to another?

NI?  Anybody home there?  This is not a complicated issue.  I'm not asking for you to re-write code for me or add in an obscure feature.  I've upgraded from 2013 to 2014 and using the new version in a new project with a single VI with one data acquisition task outputting to a waveform graph and I can't get a remote panel to display in a web browser.  The only thing that's changed is the upgrade in LabView versions using the official LabView media in the mail.  This hardware worked in this configuration on our networks with a 2013 sp1 application prior to the upgrade.

I've worked through the KB article referenced in the earlier and only post from NI.  It seems there should be some diagnostic tool I could use to determine if packets are being blocked or a report that identifies a mismatch in software versions or something troubleshoot the issue.

[jeepers52004]

Ok.  For the benefit of anyone else who may go through this, here's what I did to resolve my issues and I'm not certain at this point which one (if it was only one) step was really the key step.

I changed the application server port to 80 in the web configuration of the cDAQ 9139.

Even though in the 2013 application I had this port set to 6002, maybe something changed behind the IS scenes here that now had that port blocked.

I I also added the specific VI to the Visible VI list in the web server properties of the cDAQ.

I changed the remote panel server from port 6003 in the 2013 application to port 800.  Again, maybe something changed on our networking side of things.

These changes resolved the issue with accessing the remote panel of the new, ever so basic VI I created in LabView 2014 but would not let me view the VI I was trying to get working from the LabView 2013 app.

Last, even though I could open and save the 2013 VI in LabView 2014 and I mass compiled the old application VIs as recommended by some KB article, I still could not view the real VI.  I copied the block diagram into a new VI in a new LabView 2014 application and at long last, I could access the remote panel via a web browser (IE 11.)

Along the way, I became locked out of the cDAQ because I had added a specific IP address in the web server setup of the cDAQ properties during troubleshooting and even with my IP address set to static and not changing, had to edit the ni-rt.ini file several times to get the changes to stick;  Luckily I was able to still access the cDAQ  via FTP to change that file.  I also received the error "Requested VI is not loaded into memory" intermittently several times throughout the process even though I hadn't done anything aside from reboot the cDAQ.  Even with the new VI created solely in LabView 2014, I also intermittently received the error "VI version is too early to convert to the current LabView version."  Maybe these symptoms point to some other underlying issue with software version mismatches even though all software was installed from NI shipped media or possibly an impending hardware failure on the cDAQ but good luck finding help on the website to pinpoint that.  And if you do find something, be a sport and post it so the rest of us suffering through these issues can benefit 🙂

[jeepers52004 · Accepted solution]

Another possible solution to this issue - operator error.

See one of my other posts here for more detail but I made an assumption about port numbers and what they applied to.  Two key points - the application web server port in the hardware web configuration page is not the port used to access the remote panel - that port is the one assigned in the device properties, remote panel server settings in the project.  And these cannot use the same port; this will also lead to the "server does not support remote panels" error.

Note to NI - you should add this to your kb document on troubleshooting for this error.

Thanks!