embedded web browser viewing remote front panel

[jwkelly]

I just tried running everything locally on a Windows XP 32-bit computer and the problem still occurred. So I'm starting to run out of ideas as to what the problem could be other than it being something with our copy of LabVIEW (maybe we're missing an update or something). I don't know what else could be common between all 3 computers that I've tried this on.

[Logan_H.]

Yeah,

Seems a bit baffling. Whatever your 3 machines have in common, mine does not share as I have run a clean install of LabVIEW 2009 (No SP1 in sight), hosted the Web Server, Published the Test.vi HTML and everything runs fine. I'm beginning to think it is an ActiveX Version problem, which patches (if any) do you have installed on your LabVIEW 2009 builds?

Logan H

[jwkelly]

I just installed the f3 patch on my computer, but I'm not sure if the other 2 computers have any patches. My computer, which is running Windows 7 x64, is showing LabVIEW 9.0f3 (32-bit). Is there a way I can update the ActiveX components? I've tried searching for that and haven't found anything. The other common thing is that Firefox is the primary browser on all 3 computers. I've tried making IE the primary browser and playing with all the IE settings, but with no success. Once, it showed the "Setting Up Plug-in Window" that Blore mentioned, but I wasn't able to get it to do that again and am still getting the ATL 9.00. I've also installed a Mozilla ActiveX control and tried using it in LabVIEW but the control doesn't seem to be compatible with LabVIEW because I can't navigate to any page.

[Blore]

I think NI LabVIEW R&D team should get involved to solve the problem. I am damm sure we need a fix for labVIEW2009 ActiveX. We have already wasted one week.

[Logan_H.]

The ATL 9.00 error code is not present on any of the systems I have tested this issue on here. Without it being reproducible with consistency, there is no way for R&D to look into it.

Let's step away from the trees to see the forest, why is it that you need to use a Web Container in a LabVIEW Front Panel to interface with a Remote Front Panel of a VI? It seems a bit like you are converting from one interface to another and then back again. There are 3 other solutions I can think of that eliminate this 2nd layer of abstraction:

1)Use VI Server to call the VI that you are wanting to control Locally,

2)Use Network Published Shared Variables to read values from the VI and write values to control it.

3)Use SubPanels to view the front panel in a container without using Remote Front Panels

[jwkelly]

We have a main interface that controls different parts of the system all from the front panel by embedding multiple VIs. These VIs can be individually switched out depending on how the system is set up at any given time, and some of the VIs might need to execute on a remote computer.

We are currently using a combination of 1) and 2) to accomplish this. VI Server is used to call a remote VI, and then bound shared variables are used to control the remote VI via a local "dummy control" VI that's sole purpose is to control the shared variables which in turn control the front panel of the remote VI. This set up works, but it increases the complexity of the system (vs. being able to view the remote front panel on an embedded browser via the web server) tremendously. It is an enormous pain every time we add something to our system to have to develop 2 VIs to do the job of 1, and set up all the controls to be programatically bound to shared variables at run time since the host of any of the VIs or of the main interface itself might change. We are also trying to avoid the use of shared variables as we have already experienced latency issues with them that are unacceptable in our system.

3) would be the optimal solution if it were possible to embed remote VIs on a subpanel, but this can't be done (honestly I don't see why not, but unfortunately it can't).

So as far as I know the embedded web browser viewing a remote front panel is the only good solution for our system. If there are any other solutions I'm open to ideas, but I thought I had explored my options pretty thoroughly before arriving at the web server. Do you not know of any way ActiveX Components can be updated?

[Blore]

Somehow we are also in position as jwkelly for not be able to accept the three suggested option as solution. First two are the solution which will be tedious and cumbersome. and the third option is not meant for remote panel viewing. It will just load a VI from a remote PC harddisk and runs it locally where as we need to view the remote instance of the VI on the local machine and we should be able to directly control it. Web browser is the best solution. The question is why it work with labVIEW 8.5 and not with LabVIEW2009? Obviously there is a bug in LabVIEW2009. If the problem is not reproducible doesn't mean we are not facing the problem or we don't want to make use of the best solution instead of workarounds. We are with the problem for more than a week and no solution so far. I have attached a snapshot of the problem.

[jwkelly]

What Blore posted is the same problem I'm experiencing.  I would also like to add that I just tested the Web Browser ActiveX object in Visual Studio, and was able to view a LabVIEW remote panel through the ActiveX object in Visual Studio just fine.  So it seems that it's not a problem with the ActiveX object itself, but with how LabVIEW communicates with the ActiveX object.  As far as other things that are common amongst all 3 computers I've tested it on, though, I guess installations of Visual Studio, Matlab, and Code Gear would be on the list.

[Logan_H.]

I was just made aware from a colleague that one of our NI branches has also reported this problem. I have spoken with the developers for LabVIEWs ActiveX controls in R&D and am filing a Corrective Action Report (CAR) for this bug.

I would appreciate speaking to either of you directly via email or phone. Would it be alright to either post your email addresses or if you would like a bit more discretion, can I have approval to look up your contact info internally? There are quite a few more eyes on this issue now.

Logan H

[jwkelly]

That sounds great.  Feel free to look up any of my info that you need.  My e-mail should be in there, and if you'd like I could give you my phone number over e-mail.

Thanks