hooovahh

Very neat I didn't know this feature existed. Back to the TDMS question. I'd recommend you stick with the three separate logs at different rates because of the mentioned issue with huge log files, and the TDMS header being written all the time. The good news is that TDMS files can be combined easily using a command line "copy /b" command. So you can log to 3 separate files, each in their own group, then combine them into one file with 3 groups.

Your google-fu has failed you. That feature of Quick Drop has been called Super Quick Drop, and on the dark side I had a very similar issue. http://forums.ni.com/t5/LabVIEW/Super-Quick-Drop-Fails-Me/td-p/2833156 For me I first suspected DisplayFusion because I use that as a multimonitor program, but it turns out that it was TeamViewer and the QuickConnect feature. For it I suspect it is some software interaction, but might not be TeamViewer.

Your English isn't great, but that solution does work. This solution looks at all VIs in memory, and then attempts to save the Run-Time Menu of the VI to a temporary file. According to the help on this method: So this only works on VIs running, and not reserved to be ran. I tested it out by having a subVI in a case that is never called, and it found it wasn't running, then when I choose to go to that case it found that it was running.

Yeah that's nice and all if only there was source code attached. This also uses scripting (I'm guessing) and that still means only in development, and not RTE. I hope you have a way to save and load panels and connections too. Others have done similar style UIs, like something I put together last year http://lavag.org/topic/17046-multi-panel-interface/

That is interesting and I've never seen this issue before. Have you tampered with any of the files installed by LabVIEW in the Program Files folder other then user.lib files? How reproducible is this issue? What version of LabVIEW? What steps to reproduce it? NI maybe very interested in trying to fix this if it can be reproduced.

What I said was meant to be a joke as I was quoting ShaunR. His suggestion to gloss over things that look good on the surface but have gaping holes when you go to use them yourself, is a familiar feeling I have had when seeing NI demonstrate some products. EDIT: And thank you for spelling my name right.

That is exactly what it means. LIFA is a communication protocol between a LabVIEW and the Arduino using serial as the transport layer. LabVIEW code does not compile down to the microcontroller. That being said you can still use it similar to an FPGA, in that you tell it to do something, then it does so with its tight timed loops and can then return the result. That's where you could tell it something like "Turn the UUT On" which the Arduino knows is a large series of SPI commands that it sends out, then it returns after it has turned the UUT on. Even for a general purpose DIO device it's hard to find one for sub $20 with LabVIEW support. As mentioned before the SPI and I2C protocols are also supported on the LIFA palette. What is the cheapest SPI device NI sells? I think the 8451 which is over $400.

If you only have an output of the case structure, and no input to link it to, the option will be greyed out. Not sure what other situations will cause that.

You don't work for NI marketing do you?

Yeah the Student License of LabVIEW isn't restricted to only students enrolled in a college course. I remember seeing the wording being very loose, something like for educational purposes. Stuidica probably has a blanket rule for anything they sell for students/educators only. The Sparkfun bundle is great to get your toes wet. Just remember being student edition I believe you'll always have the watermarks, and no application builder. LabVIEW does have a student license for free for 6 months now too. The LIFA toolkit is the way to go. It hasn't been updated in a while but it doesn't really need to be. The Arduino hardware hasn't really changed much and its open source anyway. LINX is supposed to be the successor to LIFA but I haven't seen a need to use it yet. This is also a great opportunity to get into Arduino which is a fun little micro to play with. You can build your own from raw components for around $10 on a breadboard, then use another Arduino to program the bootloader.

My example isn't quite right. I just meant if you were handling other events, in addition to setting a timeout to be very large, that the result may not be what you expected.

You probably know this already, but the 15,000ms timer would get reset every time any event is handled. So if I had a Mouse Move event on the panel and continually moved the mouse, the timeout case would never get handled. Because of this I would often have a small timeout like 100ms, with an elapsed timer inside to see if 15s have passed. That being said I think Gregs answer is the better then this.

That's a pretty good list. As mentioned before 2013 had a big improvement in these types of controls as mentioned here. http://lavag.org/topic/17009-labview-2013-favorite-features-and-improvements/page-2#entry104672

I didn't know about this, but haven't had a need to yet. Also XBMC Plugins? You must be doing some cool stuff.

I'm not sure I fully understand the problem. Is there something wrong with the VIs I posted other then the output of the subVI should be the reference instead of the value? Is the issue that you want to do this for multiple VIs at once? That will get tricky. I'm not sure how a subVI can know which instance on another VI it is responsible for. Feel free to attach a zip. You'll need to click More Reply Options, and from there can attach files.

The subVI I made has a connector pane with only 2 terminals. I did that for simplicity because I didn't know which would be input and output this way I could know index 0 was output, index 1 was input. Disconnect the variant output from the connector pane, and connect the Control Reference control to it. I made an indicator in the subVI for the reference itself. EDIT: And yeah I can't think of anyway to do this without scripting. Besides this needs the block diagram to be available and EXEs generally strip those out.

Okay a couple quick VIs later I have a working version but there are likely better ways to do it. Run Main VI with a control connected to the input terminal. The output is a variant value of that control, getting the value by reference, by looking at the control connected to it. Get Control Ref Test.zip

Yes this could be done with scripting. Of course if you call the VI in to places on one VI I don't think you'll be able to find one versus the other. This would have to be done with scripting, so you couldn't do this in a built application. Also you would probably want to limit this to only work with a control terminal wired directly to the subVI. For instance if you had a string control, then go to a string concatenate, then to your VI then this function wouldn't work. It sounds too difficult to keep looking up stream to find a control.

I like the idea of this but I think your implementation is a little flawed. I noticed that when selecting the digit to edit using the mouse, that you didn't take into consideration that numbers have different widths. You just took the total width and divided by the number or characters. The attached code should work on all font sizes, and types to try to find the character that the mouse is over, based on the coordinates of the mouse. Attached is an update that I think fixes these issues. Admittedly I haven't tested it on a bunch of controls just the one you provided with different justifications to test they all work. easy_inc Hooovahh Edit.zip

That's a great idea and will bring it up in my next goals meeting. Not to set a goal to get X number of likes/kudos, just another bullet point in growth over the past year. Well my legacy is being Crelf's alter ego for irking people. I'm not even my own person...or am I?

The most glorious link I've seen in a long time. The site seems a little cluttered and unorganized if you go up a few directories but still better then NI's site search.

Found a bug, Current VIs Parents Ref__ogtk.vi, and Current VIs Reference__ogtk.vi should not be inlined. They are index 5 and 6 on the VIs to Modify array and to fix it just turn off Inline for these VIs. They can still be Shared Reentrant.

I never said that an XNode would have better performance then the exact same code in a normal VI. I was comparing my implementation (or Gregs) to the XNode implementation which may or may not use the same technique. I thought I heard of an XNode replace before so I did a quick search. http://labviewwiki.org/ReplaceSelf_(XNode_Ability) Which I assume is what we are talking about, but again my experience with XNodes is quite limited, mostly just using what others have made.

This crossed my mind again recently so I figured, why not make a VI that makes OpenG VIs inlined? So attached is just that. Don't get me wrong it doesn't inline all VIs that'd be crazy. So what I did was opened each OpenG VI, then look at what VIs can, and can't be inlined, and if they are inlined do they have uninitialized shift registers? If so then they should likely have the Preallocate for reentrant clones, instead of Shared. I also modify all OpenG VIs to turn off debugging, and automatic error handling. In the zip is also a VI I used to verify find all broken OpenG VIs. This can be used to see if any new broken VIs are made, after making these inlined changes. For my OpenG setup there are 4 broken VIs that are supposed to be broken, and after running my Modify OpenG VIs.vi I still only have those 4. I don't know if there are other unintended changes but I haven't seen any yet. If you use this and find any issues please mention it. Opening each OpenG VI and looking for what can and can't be inlined I noticed that many of the ones that can't be inlined, are due to using local variables, where a constant (or type def constant) would work for getting the type. I also saw some instances of using the expression node when native math could be used. And I saw a few times where the conditional disable structure could be used instead of a property node. Even so all of the array functions can be inlined. If you do use this I recommend backing up your OpenG library, in case something goes wrong. Or you could just uninstall/reinstall with VIPM I guess. Modify OpenG VIs For Inline.zip

All off, I even have the subVI inlined just as my example in the zip I posted earlier.