LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Remote Panel ComboBox Problem...

I've got a compiled app I've created that, on startup, reads a text file and uses it's contents to populate some ComboBoxes.  This works just great on the computer running the App, but I also need the app to be viewed/operated as a Remote Panel too, and here's where the problems occur...

On the system running the App I see:

New Bitmap Image.jpg

 

while viewing the App as a Remote Panel I get:

New Bitmap Image.jpg

Which are my defaults if I can't open the text file.

 

So, I'm trying to figure out if the problem is with ComboBoxes and Remote Panels, or because the Remote Panel version doesn't have the text file (I'd thought it would 'inherit' the contents from the original VI)?

 

Anyone with any ideas to enlighten me???

 

0 Kudos
Message 1 of 7
(3,710 Views)

What version of LV are you using?

 

Where is the text file located?  Is it on the PC that is hosting the VI?

 

Is this the way the two front panels look at the same instant in time?

 

Is the remote panel being accessed through the LabVIEW menus or is it through a webpublished HTML link?

 

When is the text file populating the comboboxes in relation to when the remote panel is opened?

 

Since the text strings that are a part of the combo box are populated by way of a property node (and I believe this would be associated with the UI thread, but I may be wrong), I'm wondering if the update of the remote front panel's properties are not occurring when the local front panel's properties are updated.  If you can find a way to "refresh" the remote front panel, does the problem fix itself?

0 Kudos
Message 2 of 7
(3,700 Views)

Sorry for leaving out the details, I'll try and fill you in...

 

The application is compiled in LV 8.5.1. Full package.

The text file containing the wording that is used to populate the ComboBox is located on the host computer in the same folder as the compiled app.

Yes, the two front panel views are from essentially the same time, with the Remote Panel being operated through an HTML link in Internet Explorer.

The ComboBox is populated when the hosted VI is started up.  After it's started up, I then open the Remote Panel and see the 'default' items.  Hitting the refresh button in Internet Explorer or closing it and re-opening it results in the same items being displayed -- it's not fixed.

If I take control of the Remote Panel, and select a different item from one of the ComboBoxes, it still shows the default text in the Remote Panel version, and the correct text in the Hosted version.

 

I'd thought that anything I did on the hosted VI would show up the same on the Remote Panel, but obviously not...is there somewhere a good explanation of how Remote Panels actually work?

0 Kudos
Message 3 of 7
(3,689 Views)

Hey Steve,

 

What you are describing is certainly strange. I have a few questions for you, is your 'compiled VI' and executable build using the application builder, or is it a normal VI running in the development environment? Are you seeing this same performance with all combo boxes? So if you create a simple VI with a combo box with a few elements and then run the VI in remote panels, are you seeing the same sort of thing where the combo box in the remote panel is different than that on the host computer? Would you be able to simplify your application a post an example VI that is exhibiting this behavior?

 

As for the literature, here are some resources you might want to take a look at: Developing Remote Front Panel LabVIEW Applications and Remote Panels in LabVIEW -- Distributed Application Development

Hope this helps.
-Ben

WaterlooLabs
0 Kudos
Message 4 of 7
(3,678 Views)

I think I've 'fixed' the problem, and it had nothing to do with the SystemComboBox running in a Remote PanelSmiley Surprised

 

Basically, I need to get the path to the running VI, and the path is different if I'm running in the IDE, or if I'm running a compiled version, so I've got a boolean switch that's set in the VI.  I then test the True/False state to determine how to derive the path.  What's happened is that I've got a local variable for the switch.  I test the T/F from this local variable in a number of places in my VI so I don't have to have a wire for it running everywhere.

 

Apparently, when I run the compiled program on my computer, the state of the switch is correctly read into the local variable before it's used, and everything works as expected...when the program runs as a Remote Panel, it looks like the local variable isn't populated with the switch state when the program starts, so it builds the path incorrectly, and when it can't open the file, it puts up the default values.

 

I'm an old C programmer, so the parallelism of LV appears to have bit me!  My 'fix' probably isn't as elegant as a seasoned VI programmer would do, but what I did was to add a Flat Sequence with my initialization steps in one 'pane', and the rest of the VI in the other (I'll probably add a 3rd pane for my shut-down steps).  Doing so makes sure that the local variable is 'filled in' first, before it ever gets used and appears to have fixed my issue.

 

Still trying to wrap my C brain around LV programming 😉

0 Kudos
Message 5 of 7
(3,653 Views)
Message 6 of 7
(3,644 Views)

GREAT!  A much better way to 'determine' if I'm running debug (inside the Development environment) or an exe than using a toggle!  I've added it to my code!

Thanks again.

Steve

0 Kudos
Message 7 of 7
(3,634 Views)