Michael Aivaliotis

Well wouldn't you know it. Leave it up to sneaky users like myself to try something like this. Plop down a Timed Loop. Double-click on the loop to bring up the Loop Configuration Dialog. Click on one of the front panel objects such as "Use Terminal". Now Press ctrl+period on your keyboard (shortcut for abort VI). Voila, the dialog hangs and you cannot get out of it or labview unless you abort the task from windows. No why would I press ctrl+period? Hmm...

It's not possible (yet) to create or remove a scale at run time. Scales can only be created by right clicking on them and selecting "duplicate scale". Scales can only be deleted by right clicking on them and selecting "delete scale". Scales can only be moved to the other side of the plot window, at edit-time, by right clicking on them and selecting "swap sides" Scales that exist (have been created at edit time) can be made visible or hidden at run-time. Once a Scale is made "active" the "YScale.Visible" attribute is used to show or hide the scale. During run-time, plots can be scaled-to/associated-with scales that have been created at edit time. Once a Plot is made "active", it can be associated with a scale using the "Plot.Y Scale Index" attribute. You must create the scale first at edit time and then use properties to hide it.

You can't get the plot area position from a property. You can get the entire graph control position but not the plot area. One thing you can do as a work around is to use some simple math to calculate the plot area position if you know the control position. This assumes that the size of the plot area doesn't change relative to the entire control. No, this only gives you the position of the legend. The plot area is the black box element that shows the graph.

Hmm, In application builder, have you included a toplevel VI in your Source Files tab?

I think you should be ok with changing the update rate and amplitude on one channel. I haven't done this but a quick search throughout the DAQmx examples in my LV70 shows a method for doing this. The problem may arise when you need to adjust this across multiple channels. I think the NI boards use a common clock source for AO generation and as such will limit you to adjusting the update rate on all channels at once. Here is an old NI example for sinewave output. Generating a Continuous Analog Output Waveform I think you can find a similar one for DAQmx. If you need to change the actual output waveform then you can take a look at the function generator example in your LV. This will allow you to output different waveforms based on a selector. The trick here is that if you have update rate limitations then you can "fool" the AO by changing the actual output data and keep the rate the same.

Well, there are many ways of doing this. It depends on the level of control you require. At the most simplest form is a method called Remote Panels. See a link here with more info: LabVIEW Remote Panels Tutorial If this is not sufficient then I can discuss some other methods.

James, your interpretation is as good as mine. I'll give it a shot. ancle, You have a small screen resolution and your VI block diagram has limited space? You want to have a scroll mechanism to place multiple VI's in a small diagram area? You can use a sequence structure! Unless I got it wrong.

If you change the mechanical action as James mentioned, it will be a cleaner solution. It doesn't sound like you need adjustable delay.

Ah, that explains the blank stare on my face ... I was thinking "man Jim's really lost me here"... I thought it was just too many beers I had... :beer:

Well, as you are discovering, manipulating your data is a real pain in the ######. Correct? That's good. It's good because this is a sure sign that you have chosen the wrong data structure to store your data. Instead of trying to jump through hoops to fit the data mold, why not change the data structure to the easiest form for you to handle... an array! This is why it is a good thing to sit down and think through the data structures you will be using to pass data around your application. if I were you, I would scrap the clusters and go for an array...

Non-trivial but possible. Besides, it's done already in the variant config data tools... not?

Do you mean show what the indicators are displaying? You can do that by having the front panel of the sub-vi open while running the caller... no?

Well, it's a feedthrough.... What more can I say?

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