hooovahh

I wondered how that worked, that's neat. I for some reason always thought it was all the packages in one, so I never installed it because I was worried I would have two versions of OpenG installed on my palette if I did. Thanks for the info.

Not just the disabled diagram structure. I found one time where my code used the conditional diagram structure to do different things if it was in the runtime engine or not. Both cases were executable and worked fine. Then I changed the VI to be inlined. The VI ran just fine in the development environment, but in the runtime engine case I used a property node which isn't allowed in a inlined VI.

We did something very similar here about a year ago. We took our reuse library (2011 and up) and added pre-build VIs for VIPM to use before making the package, to remove compiled code, and turn off automatic error handling, and allow debugging, on VIs that aren't demo VIs or example VIs (these we tend to probe around and see how it works so we want to be able to debug). After a year of usage we've had no issues. We also invested some time to understand what VIs can be inlined and went through the process of inlining them. And again after a year no issues yet.

Simply because you don't understand a feature, doesn't mean it is unsuitable. I agree with Yair that a different way of displaying it is the right way. I've never seen a Waveform Chart used in a real application, only in test demos to show quick data. When you make a real application you realize how limited it really is and must upgrade to the Waveform Graph, or XY Graph to manage the data your self. It sounds like you have found one of those times where the Waveform Chart is limited. You can do this with relatively little updates to the code, you just need a way to remember the data your self, in a shift register, functional global, or feedback node.

When I've used that INI key it makes the log file in the same directory as the project file with a .TXT file extension.

Wait you could put a control in a subpanel? What would it do for you? Just show an image of it that can be interacted with...can you then programatically get the control value...can you then build dynamic UI's where controls are semi-made at runtime? Yes the easiest solution would be to make a VI that just has that control in it. Kind of strange that they would remove a feature like this. Maybe there is some NI code that only works on subpanels if it is a VI so they removed this feature to support another.

How much work would it be to recreate your project in 2013? I ask because I have seen instances where a project file get corrupted or something, where it breaks and there is no explanation for it. So I tried making a new project, then adding my code to it, making the Build Specification the same way the other was and it works. Possibly something went wrong in the upgrade process from 2011. I'm not saying this will fix it but if the project file it self is the problem this should help. I just reread your post and it sounds like you may have tried this, you said "so I upgraded it... with no success..." what did you upgrade? Also I never use the Generate Preview. The last time I used it, it took just as long to generate a preview as it did to build the application. Has it improved over the years?

This guy is just spam. They troll threads looking for keywords that they can promote their product with.

Well we probably do need one. In my defense I could control how close to a point you could be. I noticed that the GetPlotAtPos method registers when you are clicking on the line. I increased the line width and my space I could click increased.

I'm not sure I fully understand what you need. Your post was a little wordy. But I think what you want is the "Mouse Down" event on the graph. This will be generated when a mouse click event happens when the mouse is on the graph. You can then read the "Button" value and determine which mouse button was used (left, right, middle). You can then determine if the mouse is on a specific part of the graph and ignore the event or not based on other criteria. EDIT: Okay so I re-read you post and I think you want to know when a plot is clicked on. Attached is a quick example on how you might be able to do it. Run it and click on a data point on the white plot and it should stop and tell you what you clicked on. Note that this only works on the points them selves, and not the line drawn between them but you can modify it to support that. Also note that if you are within 5% of a point it considers you clicking that point, for some large or small graphs this may need to be changed. Graph Mouse Click Plot.vi

I've wanted a scroll wheel mouse event since the event structure existed (7.0? 6.1?). NI some times takes time catching up with implementing out futuristic ideas. At least they give you the tools to be able to come up with your own solutions/work arounds until it is a native feature.

I can't speak for the "Team LAVA" because I was not involved, but I know for a fact that Mark is still very active and personally goes through each submission to the CR when something is submitted.

An easier thing to do (in 2013 only of course) is you can set the size of the queue that is used for an event. So in this case you would set the queue size to 1, and only one event will be in the queue to be handled. In the Edit Events window select the "Limit Maximum instances of this event in the event queue" and choose 1. My tests show that this seems to work correctly and the last event to handle is the last event fired.

To be clear I don't think the toolkit is free (someone correct me if I'm wrong). What is free is the deployment of a EXE that uses a subset of the Vision toolkit components. So you pay for the Vision Toolkit, develop code in it, then build an EXE. If the toolkit VIs you used, included image processing functions, then you must pay for a run-time license on each machine that runs that EXE. If you only use the other functions of the toolkit then you can get away with making an EXE and not need to pay per seat by using what was linked to.

If a VI is being called once, it can benefit from inlineing (assuming it can be inlined and be made reentrant without a functional change) Maybe that's why I am inlineing so much, I am not familiar with what inlining means in other languages. Is it just taking text files and basically inserting them into one big file? If you had 3000 text files (like 3000 vis) would a text based language have a difficulty time using it? EDIT: The link I posted to earlier mentions this. Many OpenG VIs are small subVIs, that could be called within a loop, likely has unwired outputs, and you may call it once.

I don't have a lot of tight/fast loops running using OpenG code but I do call OpenG code quite often (Arrays, File I/O, Application Control, LabVIEW Data, String, Time), and inlineing a VI is a quick and simple way to get some extra performance (little or not). It's not a magic bullet by any means but I made a point when working on our internal reuse library to inline VIs that can be inlined. There was also a tool NI made for 2012 that measured performance and detected when VIs may benefit from an inlineing operation.

This is likely a discussion that is similar to many others that OpenG has had to discuss but I'm bringing it up anyway. There are improvements to LabVIEW that could make OpenG better, but OpenG likely wants to keep support for older versions of LabVIEW. One such improvement is the ability to Inline VIs. I think that many OpenG VIs should be inlined, this would make them more like primatives where they are reentrant, and at compile time will be inlined into the calling VI reducing the overhead in calling a sub VI. The issue is that Inlineing was added to LabVIEW in 2010, and I believe the minimum version OpenG supports with the newest release is 2009. OpenG dropped support in the newest build of packages, for 8.6 and older, over 2 years ago. Thoughts? Objections? Obviously OpenG will still support older versions of LabVIEW (OpenG version 2.0 goes back to LabVIEW 6.0) this will just mean that any new features/bug fixes would only be applied to LabVIEW 2010 and newer.

Awesome now my prayers are answered. Next step will be to update my Right Hand Quick Drop Shortcuts to use the OpenG functions that I couldn't before.

Awesome idea. I don't use DVRs much (or OO) so maybe that's why my mind didn't go there, but I much prefer how the DVR implementation works.

I was talking with a coworker of mine and they had an issue where they were creating clones of a reentrant VI. But in this VI is a functional global VI. Now normally this VI is non-reentrant so there will only be one copy of this VI in memory, and any clone writing to will likely overwrite the data there. Then all kinds of race conditions happen, and then there is the issue of this being a blocking call to other clones too. So I wanted to see if I could make a reentrant global, that only really was used in one of the clone VIs made. Attached is my attempt at it. Not much in line of error handling but I think all references are closed as they should be. Run the Main.vi and it will create 3 clone VIs with a graph control where you can add data and clear data to the graph. The data the graph loads is from the reentrant global, but only one clone should use one global clone. Keeping track of all these global clones is yet another global (this was a poor test but I wanted to just see if it would work). Now my main can have access to all the globals too for what ever reason I may want. Has anyone done anything like this? Does anyone find this useful? Would a shift register in the Clone be alot easier? (probably) Reentrant Global Test.zip

Very neat I never knew that existed. So you develop using the Vision Toolkit, and if you don't use any image processing functions, then you can deploy to PCs without needing a license of the Vision Run-Time Engine. I would need to test to see what functions do and don't work without a license. EDIT: Looks like there is a page describing the functions that are included. http://digital.ni.com/public.nsf/allkb/5476BD570E87E0BA8625797D0071263C

No I don't have any tool like that in my back pocket. But I would love to see it implemented with a picture control. I've done some stuff like that in the past and it was quite rewarding/time consuming. I think that some .Net could come into play for image resizing (I'm in love with the GDI resize) so your drop down selection fits to the control size. If I were to do this I would have a sub VI be the thing that is shown when you click. It is called and moved into location to look like the drop down. The VI would then contain a picture box on the left, a single column listbox for the text, and a vertical scrollbar. Very do-able just time to get mouse clicking to index (with scrollbar) and mouse move on the controls to highlight the row by drawing some box around it. Sounds like fun.

Looking at the help on that invoke node method in 2012 it states that it does work in the Run-Time engine. So I wanted to to test it and make an EXE. I don't have 2010 but I do have 2011 so I started there. The problem is in 2011 this invoke node method is private (and I assume 2010 as well) which means that it was probably just a test case and not fully implemented. I would recommend staying away from private methods, especially if it is in an EXE. That being said the work around is you can use other methods to get access to the image. Here is one http://lavag.org/files/file/30-get-data-from-clipboard/ The other one by RolfK I like better but can't seem to find a link to it at the moment. EDIT: Sorry the clipboard code posted above uses the same Get Image function. RolfK's does not but as I said I can't find a link.

Ok so an Arduino is a microcontroller. Not all microcontrollers are Arduinos, but all Arduinos are microcontrollers. Arduino hardware and software is open source and has nothing to do with NI. People can make their own Arduinos that meet their specific needs but there are several official Arduino types like the Mega and Uno. The software used to program an Arduino is a custom build IDE which is basically C++ (correct me if I'm wrong). Once you program the Arduino it can run without a PC, it will just do what it was told to. Here is where LabVIEW comes in. NI developed a toolkit which has a set of code that is put on the Arduino so that it can communicate back to a PC running LabVIEW. This set of code allows you to do a whole bunch of stuff without needing to write any text programming because NI already has done the work for you. This removes some of the low level features of an Arduino but for most people it is a way to add cheap hardware to LabVIEW. The Arduino does not run LabVIEW code, and you cannot compile a VI to be put on the Arduino. The toolkit is just a set of functions that allow you to control the Arduino from LabVIEW. I don't know what you mean by worldwide standards, an Arduino Uno is the same anywhere in the world.

The LabVIEW code to perform a color quantization sounds complicated. There are a few command line utilities that could work for that you could call from LabVIEW, but I admit I couldn't get them to do what I wanted. All the files I tried them on became corrupt and actually grew in size. http://pngnq.sourceforge.net/index.html http://www.cs.berkeley.edu/~dcoetzee/downloads/scolorq/ http://pngquant.org/