hooovahh

You already have it, launch the example finder Help >> Find Examples and search.

LabVIEW 2015 leaked screenshots via Hollywood movie? Probably not.

The previous link seems to do just that, it measures the time it takes for a loop to iterate. But in most situations I'd recommend instead of trying to capture each frame as it comes in, tell it to acquire at 30FPS but then ask to read the frames remaining in the buffer. This way if your loop rate is 200ms that's fine, you'll still get all the frames. There are examples shipped with IMAQ that demonstrate both methods, and even shipped examples to calculate the actual FPS and time between iterations.

Okay deep breathes everyone (including myself). New users need to be pointed in the right direction some times, there were times when we all knew nothing so they should have some slack just like we should have had some when we were new. But on the other side of it, how are new users going to know proper etiquette if we don't point out what it should be? Lets try to be mindful of other cultures and remember we all have bad days. Lets just try not to take it out on others. We can be overbearing at times, and new users can make mistakes.

Well we can't control what window is active, the user can. I mean we can temporarily change what the active window is, but there is no telling what the user does. It could be a race condition between software and the user.

Your "final" looks cleaned up to me. Sure the terminals aren't quite right, and wires are a bit long, probably indicating that the terminals are added after the code generation (just a guess not sure XNodes actually do this). But you don't have wires on top of each other like the first image. Since this XNode lives in the VI that calls it, and is pretty much inlined as far as we can tell, the terminals are probably added when you right click the XNode to look at the generated code, and before then an interface to the XNode is this nebulous thing (at least to you and I).

So I just did a test and the GetActiveWindow returns the same HWND as the Front Panel >> Native Window, and the deprecated function Front Panel >> OS Window. Application >> Parent Window for Dialogs also returned 0 as mentioned earlier in this thread. I also thought you might want to know an alternate way of getting PIDs and the application names, so the attached VI does that too. EDIT: Oh and the command line program wmic can get some other PID information. Get HWND and PID.vi

Please don't post pictures. Would you take a picture of notepad and post it on a text based language forum? That being said the code you show is quite simple and all the work is being done in that one subVI which is where I'm guessing it is trying to read a file that it doesn't have permission for. Also that version of LabVIEW is probably from 2004 or so. Is that the current version your institution has? You're going to want to dig into that VI and probe around and see what is going on. Use probes, breakpoints, wires retain values (doesn't exist in LabVIEW 7.x) and the various step over/into, to figure out why this error is happening.

Awesome, you'll have a great time for sure.

So in my Find References XNode in my GenerateCode Ability VI, I call the Insert and Wire Template.vi which is a VI that I use for inserting a template VI (it still needs some work) but what you'll notice is at the end of that VI I have a constant set to false for cleaning up the BD. I just called the Block Diagram >> Clean up invoke node on the VI reference, which I got using the Owning VI reference on the Diagram reference passed in. I set that constant to false when I'm done, but have it be true during development so the code isn't complete crap and hard to debug.

Well a VI doesn't have to be reentrant to be dynamic. But generally this is what you want because dynamic usually means you are going to spawn N copies of this VI at once, and that can only happen with a reentrant VI. I'd start with proving it out on your host first. Here is a post I made a while ago showing how to launch reentrant VIs using a static VI reference and the VI name. This is a better way in most cases than using the VI path. http://forums.ni.com/t5/LabVIEW/building-an-executable-with-vits-with-Labview-2011/m-p/2384984#M740405 See how that works on the Windows development side. Then see if you can do something similar in a test VI on the RT. I haven't used the embedded UI but I didn't think there would be any strange limitation on the dynamic VI launching.

Bathtub Curve, could be early faulty hardware.

While we can't control google search results, I tired this. "Lava BBQ LabVIEW" https://www.google.com/webhp?q=lava%20bbq%20labview#safe=off&q=lava+bbq+labview And the first result was for the 2014 BBQ on the NI forums, where it has a link to the official announcement. http://lavag.org/bbq Which now directs to this page. Still I'd love me some of that steak.

Glad you found a solution. In the future post your code not pictures of your code. Things like history length on a chart is real easy to check when you have source code, but impossible to know from a picture.

Very catchy.

Okay you set up your hardware to sample at 1Khz, but then you choose to read it one sample at a time, so you hope to read a sample every ms. But you also need to do some thread swapping because every iteration you are using property nodes. Wouldn't it be better to say read n values at once, then wait however long you want, and read how every many samples there are to read? Change polymorphic type to one channel N samples. You're going to want to use a waveform graph as well, and keep the history your self. After you read N samples append them to the previous samples, then if the array size is too large, containing too much time, use array subeset to get the last N samples.

Restructure is good, but I'd suggest making the examples easier to find, maybe putting them at the top level. I just know when I get a new toolkit my first thing I do is run the example and see how it works and I had to go three folders deep to find the Example. Even if this is just a virtual folder in the library it might make finding examples easier. Personally I don't think requiring x64 Windows is that big of a deal but others might. I haven't used 32 bit Windows in several years. The only reason I see 32 bit LabVIEW used is because some toolkits aren't compatible.

Because recursion is fun, here is the link to the idea exchange to make this official. http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Symbols-on-all-columns-of-a-multicolumn-listbox/idc-p/3161734

I admit I haven't been having a good morning, so sorry if I've been in an arguing mood. Not trying to be fan-boyish for Windows, just saying the tools that already exist for doing things in a semi-standard way, are the ones I will prefer to use. EXE versioning (in my opinion) should live with the EXE. It is convenient to store build numbers in this EXE as well. SCC should always (in my opinion) be used. It is convenient to have the build number in an EXE link to the SCC commit version. Times when EXEs aren't made, or when SCC isn't possible, then other options have to be used to track build information to the source it came from.

Okay point taken. But in this case I'd just make it clear that modifying source code without SCC is not recommended, which is true for all development. Currently the same way, and EXE is built for Windows, which includes the bit file needed for the FPGA, which links back to the commit version. EXE version 1.0.1.293 is commit 293 which is the master commit for the project which includes all source needed including FPGA. I guess the day that I have a project which has no Windows built EXE in it, I'll need to try something else, but again never has that been the case for me.

My customers have no interest in cross platform-ability. They do care for standardization, and they know how to find the version of an EXE without running it. They also know how to look up what version of the installer was installed by going to Add Remove Programs. If those don't match it throws up red flags for them. If my customer site doesn't have internet I bring along a 4G USB device with my laptop. That being said I haven't been to a customer site that didn't have internet in quite a while. Tracking what version of source was used in an EXE also tells you what version of the VI was used in that EXE. When coupled with SCC, this gives so much more history and diff management. I just see it as another thing to manage when SCC does it for you.

Yes it is possible to use tags that get read, or editing a constant on a block diagram. But at the end of the day I want my EXE to show the correct version, when you inspect it in Windows Explorer too. When you right click an EXE and go to Properties, then Details it shows the Product or File version. This is a standard way for applications to contain version information. Having a string constant on the BD that gets updated is just another way of showing a version which might not match. For this reason I'd really rather just maintain the version with the EXE, and then read that using the <vi.lib>\Platform\fileVersionInfo.llb\FileVersionInfo.vi The best semi-solution I have for this I posted here. http://forums.ni.com/t5/LabVIEW/Pre-Build-EXE-and-Installer-Set-Version/td-p/3149028 Basically it has a pre-build that sets the version, then makes sure any installers have the same version, then aborts the built, and instructs the user to perform the build again. This second build uses the new build information we just set. I tried invoking a new build but couldn't get the dialogs the way I wanted and it would sometimes show an error.

Are you aware this is a forum dedicated to discussions of advanced programming techniques using LabVIEW? OpenG is not the right subforum, and LAVA is probably not the right forum in general. This has been moved to the LAVA Lounge where any topic can be discussed.

Yes this works if the members you have in your library already exist on disk. Here you create the library, but you add members from disk. In my case I created an XNode which also created an unsaved member for State. State couldn't be saved because the library hadn't been saved yet, and the library couldn't be saved because State hadn't been saved yet. As I mentioned earlier this is similar to an XControl where controls and VIs are made simply by creating the XControl.

You can do this too. Capture Mouse Down? then use the coordinates and the invoke node to get the row and column clicked, then set the background color the the blueish color. LabVIEW can make software with any UI capabilities of any other programming language. It just might take some work arounds.