Front Panel Mass Binding Project Variables Issue

Hello -
When attempting to bind controls to shared variables through the front panel mass binding option, there is an issue where you can not seem to bind a "project item" to the control. The method of binding I am using is to export a text list of control names, urls, mode, and function to a text editor utilizing the front panel binding mass configuration options. The text editor shows, in the fourth column, a "0" for no function, a "1" for network item, and a "2" for project item. when attempting to import the list back into the front panel binding mass configuration, all "2" indications become "1", as all items are treated as network. Thus one can not effectively bind to a project shared variable item.
The binding works fine manually by means of utilizing the properties selection of the control, but it is difficult to do this for 821 controls, as in my application.
My application is based on a OPC served group of 821 variables which are linked to controls and indicators through the shared variable representation for each item created in the multiple variable editor.
Does anyone have a work around for this issue, as it is a showstopper right now, ie, you can not effectively bind a large quantity of controls or indicators to project located shared variables as required.
The rationale behind utilizing project located variables instead of network located variables is to reduce the amount of calls to the OPC server which was causnig a large latency in the refresh of the 821 items. With the items defined as shared variables within the project, a single call is issued, which has tremendously sped up the refresh cycle for the list of variables.
Thank you in advance for your insight in this matter,
John DeCroos

Hello Brian A.,
In response to you comment --
"in 2006, and John did not follow up with any more information for Efosa"
-- a great deal of information was provided to NI (Efosa and many, many others, up to the product manager for the DCS module). I have never heard back on a fix for this bug for the identified version of LabVIEW. The reply by Efosa here was well after we had shipped our product -- (please see date + Efosa's apology) -- we had found our own solution as is identified in the original post.
My solution was, as is also indicated in my original post, to manually bind each variable. This was unbelievably time consuming, but was all I had.
The version of software I am now working on uses far less variables, manually bound to avoid the multiple binding issue we had in the past.
I have checked the mass binding function in LV 8.5.1, it works fine now. I guess it would have been nice to have had a reply that the bug had been resolved ---- would have helped me out a bit.
Thank you,
John DeCroos

Similar Messages

Bind a front panel control to an item

Hi all,
I have a problem with selecting DataSocket in "Data Binding Selection" when I want to bind a front panel control to an item in another server such as an OPC Server. I want to know whether we connect to that item via OPC Server or DataSocket Server after specifying an OPC URL. The LED_DataSocket near the front panel control planned to bind to an OPC Server's causing this doubtfulness for me.
And I want to know in a big application what the difference between these two is:
Connecting a front panel control to an OPC Item selecting:
NI_PSP\network Items\then selecting the item from an OPC client instance currently created or,
DataSocket\browse\ finding the item we want through Servers listed.
Please advice.

I'm working on a big HMI application with more than 200 I/Os. if I want to read/write these data items from an OPC server, do you mean it's better to use shared variables bound to OPC data items, then read/write directly the shared variable from a front panel object, connecting a shared variable node to it?
I want to know if I bind my all front panel objects to shared variables or OPC items via NI-PSP or Datasocket, for this number of I/Os, it works. And what are the differences between these two technologies?
I 'm for the best way of gathering data from an OPC Server.
Message Edited by Maryam on 04-20-2006 11:41 AM

Datasocketing a Front Panel

Hi,
I'm looking for a way to transfer the image of a front panel from one vi (which will be running) to another vi. I was thinking of datasocketing the front panel items; however, it seems as though you can only datasocket indicators on an individual basis - i have 40+ items I'd like to data socket and I don't really want to cluster all of the indicators as I'd have to rewrite the entire block diagram.
Any suggestions?
Thanks,
Richard

If you are using LabVIEW 8, it is also possible to bind a shared variable to a front panel item. The Shared Variable can be configured to have a cluster data type which may be another option for you.
I'm a little confused by your description - are you trying to avoid create a cluster of the objects? If so, then you have no choice and will have to individually bind the front panel objects to a variable (or use datasocket pre 8.0). It will depend on how you have your code structured, but it may be simpler to package your data on the block diagram and use TCP comms for passing the data between different machines/VIs. I wouldn't worry too much about the fact that you have to modify the code; this normally doesn't cause a complete architecture re-write and there are clear benefits in implementing this on the block diagram as it will make the readability of the code better rather than Front Panel binding.
Let me know your thoughts and we can discuss further. If you want, you could post code here and I'll advise which is the best approach to go for.
Thanks,
Stuart

How to resize the front panel to fit different resolutions

I m using LabVIEW 8.2 on Windows XP SP2
I've tried both “maintain proportions of window for different monitor resolutions” and “scale all objects on front panel as the window resizes” selected but just messed up everything when i switched to another different resolution. It's annoying since I'm using 22 inch monitor to do the coding but the user supposed to run it on laptop or wince.
Any solutions to it?
Thx in advance.

Thank you all. Following is the reply from NI support. I think the best way is to edit vi in low resolution.
One of the easiest ways to tackle varying screen resolutions is to design
the front panel to the lowest resolution that you expect it to run on. It
should then look acceptable on any screen larger than that.
However, you can get a bit more tricky by programmatically determining the
computer's screen resolution and then dynamically changing the size of your
front panel objects. Use an Application Property Node and select
Display>>All Monitors to return the current screen size. Then, according to
the screen size, you can size the control or indicator programmatically
using the Size property node for your front panel objects.
Ultimately, these issues have often been a result of font size issues.
Specifically, this can be a problem when two machines have different
desktop theme/font settings. If your objects are coming out in different
sizes on different computers, you can setup up LabVIEW to use the same font
on different systems by modifying the .INI file.
The easiest way is to do this: use Tools->Options->Fonts from the LabVIEW
GUI. You can then set the system fonts to anything you want. After you
have done this on one machine, open your INI file (it is in the same
directory as the LabVIEW executable) with any text editor and copy the
corresponding entries to another file. Add these entries to the INI files
on any machines you want to lock to font. You will probably run into
issues if you are supporting different platforms (Windows and Mac or Mac
and Linux, for example), since the fonts you want may not be available on
both platforms. There are Windows fonts available for both Mac and Linux
platforms, so this can be somewhat ameliorated.
This is all I can think of, but that's not to say these are the only
solutions. You might check the Discussion Forums, as many of our LabVIEW
Champions have tackled similar issues and offer their expertise as well.
Here's just a few threads that I'd like to refer you to:
How to make the size of VI and controls unchanged irrespective of the
resolution?
http://forums.ni.com/ni/board/message?board.id=170&message.id=273613&requireLogin=False
How to program the front panel size to fit different monitor resolution?
http://forums.ni.com/ni/board/message?board.id=170&message.id=87160&requireLogin=False
I hope this discussion helps you along the way in your application
development. Please let me know if you have any further questions/comments
and I would be happy to discuss them with you.
Otherwise, it was a pleasure assisting you and thank you for choosing
National Instruments.

Front Panel binding of shared variables very slow initialization / start

Hello @ all,
I am using a server running Windows2000 and LV 8 DSC RTS for datalogging. All shared variables are deployed on that server.
I am now facing the problem, that all front panels running on the clients using the network shared variables on the server take very long to sync on startup. First the flags on the controls bind to the shared variables turn red, after up to ten minutes they start to turn green. The panels use up to 40 controls bind to the shared variables.
All firewalls are turned off. I tried to connect the client to the same switch the server is connected to. Same problem. Does anybody have a clue?
Thx for your quick answers.
Carsten

While I can't offer any solution to your problem, I am having a similar issue running LV8.0 and shared variables on my block diagram (no DSC installed).
When using network published shared variables, it takes anywhere from 30 sec to 4 min from the vi start for any updates to be seen. Given enough time, they will all update normally, however this 4 minute time lag is somewhat troublesome.
I have confirmed the issue to be present when running the shared variable engine on windows and RT platforms, with exactly the same results.
In my case, the worst offenders are a couple of double precision arrays (4 elements each). They will normally exhibit similar "spurty" behavior on startup, and eventually work their way up to continuous and normal update rates. Interestingly enough there are no errors generated by the shared variables on the block diagram.

Using Shared Variables and Initialize Front Panel Binding (to PSP)

Hi,
I use LV DSC RT 8.2.1
I have a Vacuum System That includes signals from - Pumps failure, Valves status, Vacuum gauge, start Pump ...
Each signal is read by a FieldPoint.
All the relevant FieldPoint Channels are read by the Server (a computer in the Ethernet Network) and published to the network in the form of Shared Variables.
I have a client VI that is reading the Shared Variables published by the Server using Front Panel Binding.
Problem :
Some of the Bindings are in the mode 'Write &Read' and that causes some initialization problems.
For example - Valve #1 is Open, and then a User start running the Client VI, (the Valve #1 Status mode is 'Write & Read")
if in the VI the status of Valve #1 is closed (before running it) then the Valve status is changing to Closed.
I want the Client VI to first read the Physical status of the instrument and then to change the Value if the User changes it.
But that's seems to be a problem when using Front Panel Binding... (is it?)
I know I can Deploy a lvlib in the Client Side and Item Bind to the Shared Variables or Use DataSocket.
(Is DataSocket is a Reliable method when connecting to Shared Variables? What are the disadvantages when using DataSocket?)
What is recommended by those of you that are experienced or by NI ?
Sincerely Yours,
Amitai Abramson.

Amitai Abramson,
Hello and thanks for using the NI Forums.
I'm glad that you've read the Using the LabVIEW Shared Variable Tutorial on our website. Check out these other resources:
Network Variable Technical Overview
Troubleshooting Network-Published Shared Variables
Why Do I See Unexpected Value Change Events for Shared Variables Using LabVIEW DSC?
All You Need to Know About Shared Variables
Creating a Value Change Event for Shared Variables
Alternative Method for Using Shared Variables Between Systems in LabVIEW 8.x
What Is The Difference Between Using Shared Variables And DataSocket VIs To Access OPC Tags?
The issue that you are seeing by having "Write & Read" bound items on both the server and client side is essentially a race condition, you don't know which one is being read/written at what time. To resolve this issue I would take a look at some of the documents below.
Using a Local, Global, or Shared Variable in Parallel Loops Can Cause Race Conditions
Using Local and Global Variables Carefully
Tutorial: Local Variable, Global Variable, and Race Conditions
Locking a Shared Resource or Variable in LabVIEW Using Semaphores
You mentioned not wanting to have two sets of shared variables (one on each side), but this is a great method to resovle this issue, that, or you can develope some sort of hand shaking to prevent these race conditions.
I would suggest that in the future when using these forums you try to ask only one question per thread and make it more concise. It's hard to tackle multiple questions and such broad questions as "I want to know all the ways that I can connect to Shared Variables, and I want to know the advantages and disadvantages." I suggest this because we want you to get your questions answered and more concise questions will result in quicker and better answers.
Message Edited by Ben S on 10-01-2009 06:05 PM
Ben Sisney
FlexRIO V&V Engineer
National Instruments

Dr. Damien's Development - The Xylophone Project X - Font Issues and Front Panel Layout

The Show Raw Data button was made active in this installment. Doing this in a robust fashion was more involved than one might think, due to font and platform issues (remember I want to port this to a Windows Mobile device eventually). The following changes were made.
The A frequency indicator was made active. This was an oversight from the last update.
A front panel object, XylophoneFP.lvclass, was created to hold the front panel references and methods.
The front panel object was used to implement the Show Raw Data button.
The front panel object was used to compensate for font issues.
When testing this application on Windows Vista, I noticed that the font differences between Vista and XP were annoying enough that I wanted to fix them. This will also lay the groundwork for any layout issues when porting to Windows Mobile. Usually, I create a cluster containing all my front panel references, but this time I put them into an object. Besides the usual object boilerplate, there are two methods, one to rearrange the front panel and one to show/hide the data graphs.
Once the controls and indicators are properly arranged, showing and hiding the data graphs is simple. VI server methods are used to find the edges of the outer controls, some whitespace is added, then the front panel size is reset. Arranging the controls in the first place is much more complex. Dialog controls are used, and these controls change size based on the default font size. Font sizes can change due to user preference or when using the application in a different operating system than it was developed in. Button sizes can also change due to localization.
This problem is difficult to solve cleanly, and the VI which does this, XylFP.lvlib:XylophoneFP.lvclass:ArrangeControls.vi, shows the problem. It relies on the actual sizes of the controls/indicators to rearrange the front panel in a hopefully pleasing fashion. Even though this is a relatively simple UI, the VI is fairly complex. It uses VI server calls to determine the current sizes of controls and then rearrange them. If you choose to do something similar, consider the following hints:
The Bounds property of all controls is not writable. To change the size of controls, you need to find the property or properties which change the size. There may be more than one (which is why Bounds is not writable). For example, to change the size of a boolean, use the Button Size property.
In many cases, the property you use to change the size of the control will not be the same value as the Bounds property. Using the boolean again, the Bounds of a 3D LED include the 3D effect around the LED, but the Button Size only includes the LED itself. Comparing the Bounds property to the result of a query to the property you will be setting will give you the necessary offset to convert between the two.
Make sure you label your wires if you attempt to do things like this. Long wires are very common in this type of programming. It is difficult enough to keep track of things without the added aggravation of having the trace wires back to their source to identify them.
A few judiciously placed type converters can eliminate many type conversion dots. This is not usually a real problem in this context, but you should get into the habit of efficient programming.
I will be hiking through the mountains of New Mexico with the Boy Scouts for the next couple of weeks, so do not be dismayed if I do not reply to comments very quickly. However, comments and suggestions are still welcome and encouraged. I will reply when I return.
Previous Installments
Data Acquisition Concept
GUI Concepts
Specifications
Core Architecture
Data Acquisition and Note Analysis
Sound Acquisition Revisited
Sound Analysis
Configuration Dialog
Calibration Dialog
Message Edited by DFGray on 06-05-2009 03:09 PM
This account is no longer active. Contact ShadesOfGray for current posts and information.
Attachments:
XylophoneX.zip ‏1259 KB

DFGray wrote:
I put the event structure in the command loop so that events are processed synchronously. In the past, I have run into a variety of race condition/synchronization issues when separating the event and command loops and prefer to keep them together to make the program structure simpler.
It is simpler but you give up any multi CPU performance. That LV is inherently parallel is one (the only) real advantage over a text based development system. I can write good structured text that is almost as visually easy to parse as LV. With modern syntax coloring engines, the difference in icons vs. structured text is not that great.
But the challenge I give the traditional text coders is to keep track of many mulitple threads. This is why dataflow is a powerful concept. Yes it does lead to asynchronous execution but if you impose synchronicity on your code you are working against LV. I get most first time programs where everything is in a sequence structure. "Just to be safe".
Of course this is much better but my first design goal is that any application should take advantage of a much hardware as possible, degrade gracefully on slower hardware and play nice with other running applications. This simpler structure severely handicaps that first goal.
In this case it is simple enough to "get away" with it since as you point out that there should not be anything that takes significant CPU time. But that may not be true on the PDA?
If you are going to run it on the PDA will we be discussing techniques to seamlessly use both NIDAQmx Base and NIDAQmx in the same system? That is a real challenge. I look forward to more of this!
Cheers!

"Shared Variable Control" combo box on Front Panel is empty after Build

Hello;
I have a project using shared variables and the DSC module. I am working on building a .exe application now that the project seems to run well.
I have several places on the front panel where I have shared variable controls. These combo boxes allow the user to click the drop down button and browse the list of shared variables in the project, as well as "browse". When I run the VI from the project, the combo boxes fully populate with all of the deployed tags in the project (I have only one .lvlib in the project).
When I build the project and run the executable, the only item in the combo box list is the "browse..." selection. I can click on that and browse to my variables, but it is much more time consuming to do so than to simply select the desired variable from the drop down list.
So, how can I populate the list of shared variables from a particular library ino the Shared Variable Control combo box in a project build?
A couple of things I have done to try to esolve th problem are ensure that the "Enable Enhanced DSC Run-Time Support" box is checked in the advanced tab of the build window, added the appropriate .lvlib file to the "Dynamic VI's and SUpport Files" window under the "Source Files" tab of the build window, and properly deployed the tag library programmatically in the project.
Thanks,
Michael Hampson
Michael Hampson
President
XL Automation, Inc.

Hi Michael,
What you see in the development environment is to make it easier for developers, and as far as I know, there's no way to automatically populate the shared variable control during run time in an executable. The reason being that the shared variable control would have no way to know which process it should be using to get the variables from. The attached vi demostrate how you can acquire the list of shared variables in a process. You can also set the default values of the shared variable control by right clicking it on the front pannel, go to Data Operations->Make Current Value Default. I can do some more research on this, but I'm about 95% sure that there's no way to convert the array of shared variables to populate the shared variable control, as the shared variable control is a special type of xControl.
Yi Y.
Applications Engineer
http://www.ni.com/support
Message Edited by Yi Y on 07-02-2007 01:27 AM
Attachments:
SharedVariableList.vi ‏15 KB

Can I Bind a Front Panel LED to a specific element in an array of booleans?

In LabVIEW 2010 I have a string of LEDs. I have and array of boolean values that contain the values that the LEDs should indicate.
What is the best way to connect the LEDs to elements in the array of booleans?
Can I Bind a Front Panel LED to a specific element in an array of booleans?
How is this done?
Can anyone show sample code?
Solved!
Go to Solution.

Imagine that you have an I/O card that provides 128, 256 or 1024 digital inputs and the requirement is to have an LED on the front panel to represent the state of each digital input. This frequently occurs.
Wiring that many digital inputs individually is a royal pain and then some !
It would make sense to have one shared variable as an array of Booleans that represents the status of all inputs and then use data binding instead of wiring each individually. The individually wiring would violate all recommendations on diagram size and fan out.
Frequently scanned For loops to update all of the LEDS would take alot of CPU time.
Wouldn't it be MUCH better if PSP could be used to update the LEDs whenever the data changed (as it is supposed to do) ?
In my case I have a LabVIEW Yaskawa servo driver that provides me information about 16 servo drives that may be connected. I have LEDs on the front panel to represent some of that status for each individual drive. But Yaskawa provides the information on the drives as an array of clusters of information for each drive, which I perform some business logic on and turn into shared array of Booleans to feed the LEDs (and some banks of switches as well).
Unfortunately LabVIEW does not seem to have any way to bind the LEDs (and Switches) to individual elements in the shared array of Booleans. It is just not that smart. Even with only several banks of 16 LEDs and Switches, wiring them individually using Decimate Array of Index Array functions is a royal pain and makes the block diagrams very large. It would be much worse and almost unreasonable to do if the size of the information was much larger.

Mobile VI Front Panel Display issue

I am not sure whether I should report this as a big of Mobile Module, so post it here and see if anybody else encounters the same issue.
When create a mobile VI, if you put a TCP Connection control and String array on the front panel the same time, it won't run. It compiles and deploys all fine, but when you try to run it, it doesn't. And if you put it as a subVI, it will stuck when it is called.
Guess I am lucky. Just so happened that I needed to put both controls on the front panel and ran it as a subVI. Every time this subVI was called, the whole program stopped. It is a simple subVI call, but maybe it is so simple that it becomes so hard to debug. I started to check if the memory was full, then subVI property, and then put all kinds of breakpoints to debug. Finally, just when I ran out of debugging ideas, I was looking at all the controls on the front panel. Is it possible that one of those controls has some sort of conflicts with others, or the mobile module simply cannot load the type of control(s). So, I took one out at a time.
It took me a whole morning, but that's how I found this bug. I hope after I post it here, it can save your time to debug this type of bugs.
Attachments:
TCP Control.vi ‏10 KB

Hi, Paul,
This could be another bug of Mobile Module if you can repeat what I did.
Here is the issue. When I transfer time stamp from PC (time stamp flattened to string) to the palm (then unflattened back to time stamp), the time stamp on the palm is always plus one hour. Don't know if this is a bug or a programming error?
Thanks.

How to update the variables in sub-vi on main front panel?

hi~
The problem is to display variables in Sub vi on main front panel.
What should I do?메시지가 04-07-2005 03:14 AM에 julitan에 의해 편집되었음
Attachments:
main_.vi ‏14 KB

You probably want the slide to update while the while loop in the subVI is running, so you can't simply wire an output from the subVI to the main VI. So you are going to have to use some form of communication between the two VI's other than a hard wire. For this simple case I think I would recommend using a global variable. You could also use DataSocket or even write the value to disk, but using a global is probably the easiest method for this case. I've attached your modified VI's. Let me know if this works for you.
Robert Mortensen
Software Engineer
National Instruments
Attachments:
global.zip ‏45 KB

How can I display a changing variable in a subvi on the front panel of the main vi as the subvi is excuting

In the document attached the vi on the right is sub to the vi on the left. On the subvi on the right the variable "Field Reading" is continuously updated on the front panel of the subvi as the "for" loop is executed, but only the last value of the variable is updated on the main vi front panel which is what is expected. My question is how can I display the changing value of "Field Reading" on the main vi front panel as the "for" loop in the subvi is running?
Thank you.
Solved!
Go to Solution.
Attachments:
Doc2.docx ‏554 KB

Hopefully I can explain it well enough. It really is simple.
1) Create an empty global variable and call it something like User Interface References.vi
2) For each and every control and indicator on your front panel, right-click and select Create/Reference
3) Place these references wherever you like (I use a series of Event cases to perform my initialisation and these all live in one of these event cases). They can be placed anywhere in the main vi.
4) For each of the references, right-click and select Create/Indicator
5) Moving to the front panel, Cut all the indicators and Paste them in the global variable (eg. User Interface References.vi)
6) Moving back to the block diagram, wire the global variable to each of the references and select the same named global variable.
All the hard work is now done (until you add another user interface terminal). You should now have something that look as shown below, [except the reference labels would be to the left (not sure why the snippet put them above)]. In my latest program I have 82 references!
Done. You can now access all your front panel controls and indicators anywhere in your program as shown below.
You can just select Value in most cases, but in this particular case I wanted to fire off an Event to do some things (log the alarm) as well as just update the value. So, this is another bonus with the method.
Hopefully this all makes sense. If not, let me know.

Fatal1ty Champion Front Panel I/O Issue

'Fatalty Champion Front Panel I/O Issue I just purchased a Creative PCI Express Sound Blaster X-Fi Titanium Fatalty Champion Series Sound Card. I have installed the card and front panel into my system with the latest drivers.
I am unable to get the front panel to work (the soundcard works fine). It has no lights, volume does not work and the mode selection does not work, in fact the only thing that works are my headphones. When I plug in my headphones my speakers mute and I get sound in my headphones. I have disconnected all connections and reconnected them ensure they are fully seated. I have reseated my card as well.
System Specs
EVGA X58
2G of 600 RAM
2 Vertex20 SSD?s in RAID0
DVD Player
GTX295 and a GTX8800
Dual Mon
Win7 x64 Ultimate
My system is extremely stable with no issues other than the new Sound Card. Here is the driver I used, Creative Sound Blaster X-Fi Titanium Driver 2.7.0007. I have also tried the Product Identification Module Update.
Any suggestions?

Thanks for the answer so fast.
I use win xp 32 bit,is there any solution for win xp
Product indentification module update
File Name : PID_W7PCAPP_US_2__0.exe
Requirements:
[color="#ff0000"]Microsoft Windows 7 64-bit, Windows 7 32-bit <
Sound Blaster X-Fi and X-Fi Titanium series of audio devices listed above<
Review and found this also
XFTI_PCDRVBETA_US_2_7_0008.exe
Fixes:
Resolves issue of Sound Blaster X-Fi I/O Dri'veBay not workingin Windows XP. <
But I have the same problem.
If you me that fix to you with that patch, I'll have to install win 7.
Regards

In the shared variable properties box, when enabling aliasing, what is the difference between binding to a project variable vs. to a psp url

In the shared variable properties box, specifically with regard to a the target being an rt target, when enabling aliasing, what is the difference between binding to a project variable vs. to a psp url?

The difference is in the type of variable you are binding it to. A project variable is a variable that lives within the specific project in which it was created. A PSP URL is an address using the Publish-Subscribe Protocol (PSP). You can learn more about PSP URLs here: http://zone.ni.com/reference/en-XX/help/371361G-01/lvconcepts/using_datasocket_technology/#Specifyin...
PSP URLs will enable it to communicate between different machines and also between projects which may or may not be open. The project variable will exist within the project.
Julian R.
Applications Engineer
National Instruments

Way to plot two variables on a chart by selecting the two variables on the front panel?

Hello,
I have created a VI to control a tensile tester which controls/outputs the following variables: time, load components in 6 directions, tensile displacements, displacements measured by a capacitance sensor.
Is there a way such that there would be only one plot on the Front Panel, and there will be buttons on the front where I can select the variable for the x and y axis when the program is running?
I only know how to make a plot using Chart Buffer using only two fixed variables. The only way I think of doing this is making a plot for every single permutation of variables, then put those plots in Tab Control...is there an easier way?
Thanks!

I have done this a lot in applications to save realestate and simplify the UI. Basically, I create an enum (or typedef) describing the x or y-axis values I would like to display on a graph. Using an event structure, you can watch for a change in these selector and re-plot your graph. You store your data somewhere (possibly in an array) and simply index into that array based on what you want to show. I attached a short example to illustrate this implemenation. Hope this helps. (LV2009)
-cb
Attachments:
Select from multiple curves and axis to plot.vi ‏19 KB

Front Panel Mass Binding Project Variables Issue

Similar Messages

Maybe you are looking for