Michael Aivaliotis

Yes, go to the Dialog Controls Pallette. That's it. Also, the Graph you saw is not built into LabVIEW. This is a trick. Someone has taken the traditional box in the graph and replaced it with a box stolen from a button in the Dialog Pallette.

Actualy, password locking would prevent ANY editing including front panel changes. Yes, this is a good option as well. It sounds like you are running LV code on a test system and your operators are aborting the VI or something. When you build your VI, you should design it so it automatically runs on startup and has all the menus and toolbars disabled. If you have to click the RUN button to execute your application then something is wrong.

Yes, this is not obvious at first. Not very intuitive. You have to feed in 2D arrays for both X and Y inputs. You have to define all your data. LabVIEW does not automatically apply the 1D data set to all plots. In your specific case you have to add a build array function on the X data (if it is identical).

What do you want to do with the detected pulse? Are you trying to measure the time between pulses, counting the pulses or just triggering something? If measurement and counting is the key here then the focus of your attention should be using the counters and the examples in LV surrounding them. Counters are excellent for that. As far as the DAQ occurences, I see no reason why they shouldn't work actually. However this seems like an backward way of doing it since it fires an occurrence when certain amount of data is acquired not when the pulse arrives. If you look at the help for the DAQ Occurrence Config.vi, you will see an option called: set the occurrence every time the output of the counter specified in the channel string control changes state such that an interrupt is generated. This might work!

Well, if we were to go live and pay for the service ourselves it would be very expensive. Nothing we could afford. It also doesn't look like anyone is offering to donate this either. I've been experimenting with a free (free as in open source) web streaming utility that may allow us to do this at no cost. It is a technology called NSV. For more information see here: Introduction to NSV The only problem is that it's one way. You will be able to view but not ask any questions via voice call. We can work-around this however by having a live chatroom open that can capture questions from remote users. I am planning an experimental webcast to test this system out in the near future. More information will be available in these forums when I'm ready for the test.

Hey, you can always add a password. File>>VI Properties then select ->Security

The idea arose on Info-LabVIEW and was initiated by ggatling. If you want to speed up wiring of your tunnels, here is a utility that will do that for multiple cases in one shot. It doesn't eliminate the wiring but it makes it a whole lot easier: http://forums.lavausergroup.org/index.php?showtopic=211 Here is the discussion and responses to this initial post: I second the motion. Could the current tunnels just be modified slightly to implement this idea? For instance when you wanted the data to pass thru for a particular case you could right click on the tunnel and select the "just passing thru" option that would display a small arrow on each of the tunnels for that case. As you flip through the cases, the tunnel image would have to update to no arrow if it was wired. Of course the arrow on the case tunnel would have to be distinctly different than the Sequence Local Arrows. -- Brian Bean

Ok, I feel better now...

Why?... Yes, it is possible. Do you want the button to stay down or pop back up? If you want the boolean to pop back up then use a local variable on the boolean and set it to false.

LV6.1 has event structures. I don't see why not? Have you tried it? What problems are you seeing? I didn't see any flashing on my end in the examples posted previously. I saved the LV7.0 version into 6.1 however I noticed that the behavior changed. The 6.1 version behaves very buggy. It does not remove the hi-lighting... Open the attached VI using LV6.1 to see bug. Download File:post-2-1090558621.vi

Ah well of course, you want me to write your whole program for you... see attachment (LV70)Download File:post-2-1090557055.vi

What I described to you in my post is exactly how this is done by the suppliers of toolkits for LabVIEW. There really is not much more to it. When the VI's are distributed, mnu files are included. I'm not sure what you mean by "the .mnu files change". The .mnu files included with the toolkits always reflect the VI's they are included with. Ah well this is called a "Merge VI". Here are some links for more information: http://forums.lavausergroup.org/index.php?...findpost&p=1121 http://digital.ni.com/public.nsf/websearch...52?OpenDocument

The datalogging capabilities that you talk about are rudimentary but may be useful for something. I just don't know what. :question: I honestly don't know why NI has not dropped this feature since I have never come across anyone who uses it (of course now I will be proven wrong). The type of files created are the same format as your standard datalog files. Datalog files can easily be created by writing a cluster into the file IO functions. How is this different? Go to a brand new VI and create a bunch of controls (booleans, text input etc.). To enable datalogging you have to go to this VI that you want to log data from and go to the Operate>>Data Logging>>Change log file Binding. I bet you didn't notice that before eh? You will be prompted for a file. Enter a filename with any extension. Now go back and edit the values then click the run button. Now go to the Operate>>Data Logging>>Log.. menu. The values of all the front panel controls will be saved as a single record to the file. To retrieve the data you have to place this same VI on the diagram then right-click on it and select "enable database access". A weird file cabinet icon will wrap around the vi and now you can create indicators to retrieve the data from the datalog file. So in essence the entire front panel of your VI becomes the cluster you would otherwise use in your normal datalog file IO VI's. See image:

Hey! I heard that! Actually James, If you look at the sub-vi's that Quixote is using, you will see VISA there. Presently this is the only way to use serial. As far as the coding style your improved re-write is great! Of course it can always be done better...

Or like the Label\Caption relationship. Correct?

Here is a brief tutorial (with pictures) on how to replace the index control in an array. This is useful when you want to provide a user friendly interface to the array control or you want to create custom front panels using the array control as a main component. Right-Click on the border of the control and select Customize from the menu Click on the wrench Icon to break apart the control Click on the index control so it is selected with a dotted line around it. From the menu select customize which will bring up another control editor window for the index cotrol. Now from the right-click menu you can replace the index control with any other numeric object, in this case a slider. Now you just close the control editor window, don't save the control, just say yes to replacing the old index control. The final product.

You should not edit the mnu files directly. Go to your LabVIEW menu and select tools>>Advanced>>Edit Palette Views. This will bring up the palette editor. From this editor you can edit exisitng subpalettes by right-clicking on the nodes or you can create your own mnu file. You can only create custom mnu files in your user.lib subpalette. Once you insert a submenu you will be given a choice to create a new mnu file. I hope this gives you some starting point with mnu files. There is extensive help in the built-in LabVIEW help on this topic.

Are you guys using the built-in ini functions that come with LabVIEW? If you use these config VI's you should never run into compatibility issues because this is handled automatically. I hope you're not creating the path yourself using strings are you?...

You can't build applications or run the Application builder in the Evaluation Version of LabVIEW... Sorry.

It seems that your wish is granted... twice! See this link 1: http://forums.lavausergroup.org/index.php?showtopic=158 See this link 2: LV7.1 Feature: Navigation Window for easily viewing large front panels and block diagrams

You should have no problem doing what you want with LabVIEW. NI has developed a LabVIEW Datalogging and Supervisory Control Module but this only works with LabVIEW version 7.1. I don't think you can buy it for version 6.0 anymore. Here is a description from NI's site. Like I said, you can do all of the above with regular LabVIEW but the add-on module will make your development go much faster.

Hmm, it appears to be a bug that's reproduceable in LV7.0 and LV7.1. Can someone else confirm this? I recreated the same VI in LV6.1 and it behaves as it should. It appears to be some kind of rounding error bug. I found a work-around: 1. Right-click on the control and select representation>SGL 2. Right-click on the control and select representation>DBL. It will work now as expected.

I've moved this post out of the bug-list section because I don't think it's really is a bug. If others disagree I will move it back. I've modified your example VI (LV7.1) and added a fix. I also converted it to LV7.0 for the other folks in this forum. The problem is that when you hide a page in the tab control, that is currently active, LV doesn't know which tab it is suppose to make the active tab. You, as the programmer, must give LV this information by setting the active tab. I've shown this in the code by adding a property node that always forces the first tab to be active. Download File:post-2-1089913388.vi

The LabVIEW run-time installer only contains information for installing components related to running LabVIEW VI's. Hardware communications (like serial) requires different modules that are not included with the "basic" run-time. You can try a little experiment. Create a blank build script. By "blank", I mean do not include ANY vi's. Go right to the Installer tab and configure it as shown in the attached image. Build the app. Run the setup.exe file on the computer that cannot communicate with the serial port or has errors. Does this fix it? If so, then you now have a serial port installer!

You cannot abort a process this way because you have not programmed any modularity in your code. The only way to do this is to put case structures around the bits of code that you need to abort and then make those cases false when you hit stop. For example, if you have three VI's that have to execute and you are executing VI#1 then you can ignore VI#2 and #3. However you cannot abort VI#1 until it has finished executing. If you need this type of control I recommend using state machine architecture and break down your code into smaller chunks that can be controlled better. Here is the FAQ entry: What is a State Machine If you want to do simple start and stop button behavior, look at the attached example (LV70) Download File:post-2-1089822983.vi