hooovahh

I'm not a DataFinder expert so what I say may not be accurate. DataFinder does not index the values of signals. At least with TDMS data you cannot perform a search on if a channel has a value that is in some range. You can only perform searches on the properties of the data. In TDMS this is easy because the file, groups, and channels have properties and searching based on if a property of a file is in range is easy. I assume for DataFinder to index the properties of a CSV file you must write a data plugin which allows DataFinder to know what properties are. Let say your first row of a CSV is property names, and the second row is the values. This is something that DataFinder just can't know without you telling it and you do that by making your own plugin. I've never made a plugin and wouldn't know where to start but my guess is this is the only way for DataFinder to allow you to find information on the file. I think the only exception to this is the file name, path, and date. This appears to be something that DataFinder infers without needing a custom plugin being made.

I had something similar happen. Before today I have never ran a tools menu item from the project window not that I think it is a bad idea. I have a tool that takes an array of string and makes an enum based on it. It will make it in the application instance that the VI calling it is in. When I run it from a VI it works as expected making it part of the project that VI is in. But similar to your issue when I run it on the project window it makes the enum not putting it in the project instance. Not sure if this is expected or not just wanted to let you know you aren't crazy. By the way I see this in 2012 SP1.

Please do not create duplicate posts asking the same thing. If this was a mistake then don't worry about it. Please contact NI directly with this type of question. We do not have the tools to help understand what happened but NI does.

Not specifically LabVIEW but I'm a fan of DisplayFusion. I've seen alot of LabVIEW developers use multi-monitor setups and having quick shortcuts to moves windows between monitors is nice along with multi-taskbars. Custom Quick Drop items. Several of the more popular ones. Custom scripting functions that I put in the Tools menu. Simple things like Array to Enum, and Configure SVN with my settings, or setup LabVIEW.ini a specific way. I don't think I've ever had just a single version of LabVIEW installed on my main development machine. Things like the custom LabVIEW icons help differentiate between versions. Abort All VIs function. Variant Probe. WinAPI functions. How much time has been lost by accidentally opening a 2011 project in 2012, and clicking save all, only to realize it later. SCC helps but it can still be a problem. I use a updated program similar to my old LabVIEW Tray Launcher which high jacks the execution of .vi files. Also adds an Abort All VIs, Launch LabVIEW (version specific), and Kill LabVIEW (version specific).

Some prefer one development style over the other. Some see right click menus a break in the development flow slowing down the developer. If I know the function names I want to use, traversing through the palette takes alot longer then it does just typing it in quick drop. I did use the RCF and know it can be used for things that seem clunky in QD. Honestly I don't know which I prefer. I think I can adapt to either given enough time. But when it comes down to it using an official feature that isn't quite perfect, is better in my opinion, then using a more cumbersome method with more flexibility. Often times I see NI develop some new thing that obviously gets inspiration from the community (the Icon Editor is one). When the NI method gets good enough we as a community start to abandon the older way of doing stuff, with the knowledge that we no longer need to support and maintain a project, and instead NI has sorta taken over it. This then helps the community focus on other cool new projects that NI hasn't tackled yet. And so the cycle of ever improving software development continues.

For the data to be usable you have to know what it is at some point. Sure you can say you have a variant but if I'm going to get an average of a variant I need to know how to interpret the data. Should this be a string, that is then transformed into a numeric? Or is it a boolean and should be treated as a bit? Or is this an enum which corresponds to some value? If you don't know what the data type is just yet, but you know that in two places the data type is the same, I highly recommend a type def. Using the OpenG Write Key (Variant) and Read Key (Variant) under the Variant Configuration palette I can write and read any thing to a file. Quite nice but at some point I'm going to need to turn that variant into a usable data type. Variants are great for a transport layer where we don't really care what the data is we just send it and then the place that receives it needs to convert the variant back to something usable. The Write and Read Key can be thought of as the transport layer where we send some data as a variant to a file, then we receive it back when we read it. For it to work properly ideally the write and read have the same data type. If these are both linked to the same type def, then that means updating the one type def will update both the write and the read to use the new data type. We may not know that data at design time, but we know what ever we write, we are also going to want to read and the data had better be the same. I've seen variants used in Queues, User Events, TCPIP, File I/O, FIFO, and several other transport layers. These all work great because they don't care what they are given they just send the bytes and who ever gets the bytes is responsible for getting usable data out of it. If you aren't dealing with a transport layer, and instead are just passing data around a VI but don't know what it is yet, there isn't really a need to use a variant, just stick with the type def and update it when needed.

Often times I find myself being distracted by the thoughts that the work I am doing would be faster if I just did it instead of spending time scripting it. There are a few times where I spent a long time working on some scripting tools that I figured would never be used or only be used once or twice. I was quite delighted to find that not only I had been using these tools, but other developers have been. Now these tools are part of my companies application building process and saving tons of time. They aren't all like this of course but I know now that my intuition on if a scripting function is worth it or not can be incorrect at first. Only time will tell if it is worth it.

This isn't a working solution but it might help. I would use 7-zip if the other native zip utilities don't like .GZ. .GZ is not a zip but many zipping tools support it. http://lavag.org/topic/16513-can-we-prevent-zlib-compress-dir-from-replacing-accented-characters/#entry101116 There someone asked about zipping a folder of files in a way that wasn't supported so I suggested using 7-zip in a command line to get the function needed. You can look at the code and modify it to extract the .GZ to a temp location and then you can read the files from there.

Post some code. I can't be sure the data type you are working with, or what you are trying based on your description but I think I know a way to go from the LabVIEW image data type to a system stream image in .NET.

I don't know why that idea doesn't have more kudos. Are people not using more quick drop items then what comes with LabVIEW? As soon as you start installing some of the ones posted on NI's site, or making your own, you realize quickly that QD only works well if you have very few functions. As soon as you have more then say 5 you start to run out of shortcuts, and only having one modifier key (the shift key) is also quite limiting. If QD is going to grow it needs to be overhauled. Not necessarily in the way TST suggested but in some way.

Do a repair install of LabVEW (or DSC). Go to Add Remove Programs, choose NI and modify it. Then a menu will come up with all the NI software installed. Choose LabVIEW and click repair. This will reinstall all the files needed to run LabVIEW. Note that you will need the LabVIEW CD/DVD as a source.

Curious what issues you've seen. I'd say we inline 80% or so of our reuse library and haven't seen issues in 2011, 2012, or 2013 as a result. What issues should we look for?

Let me save you the time. At the moment there is no easy way to do what you want. Well there is and it is keeping track of it the way you suggested. I've seen some test VI somewhere, where it took a print screen of the block diagram, then did vision checking to determine if the run button was running, or reserved to be running. That is the methods people have tried, in an attempt to do what you want programatically. Sorry.

The great leader demand video game entertainment perhaps.

This is not true. You can have a variant that has data in it being your "wrapper", and then that variant can have attributes your "hash table". You can then read the attributes, and you can convert the variant back into the data type it was before. The two uses aren't completely unrelated. Say I have a waveform. That can be XY data, or X0, delta X, Y so maybe I choose to put it into a variant so it can be either. Then I want to keep information like scale, or plot names I could store those as attributes so my single wire has all that information. Sure in this case maybe a cluster would be a better option but it is one way a variant can hold everything you need.

First issue is in state 2 (you should probably use a type def enum) you aren't passing through the bottom dynamic data type wire. This means that the sine wave data is lost and isn't available for the comparison in state 3. If you probe the wire in state 3 you'll see the top wire has data the bottom does not. Also the express VI doesn't seem to be doing what you want either. Instead I like to use the raw numbers and do the comparison my self. This way I can probe along the way and see what is going on. I take the Y and and subtract a range then perform a In Range on the other Y values. Then I say are all in range using the And array function. Test Code Hooovahh Edit.vi

Attached is a quick example. Basically you set the values as a look up table where a string corresponds to a value. Then you can get that data back by providing the string and performing a read. This is apparently a very efficient method of getting data. You'll need to convert the variant read back into something useful and for that you need to know the data type that it was written in. Here you may run into errors. Like in my example if I tried to read all attributes and said that the data type was string, one would read fine, the other 2 reads would generate an error because the data type isn't the same as it was written with. EDIT just saw you use 2010 so here is the same VI in 2010. Variant Attribute Example.vi Variant Attribute Example 2010.vi

Explain to me how this is a matter of life and death? You are not going to die if no one helps you. And if you are then you should contact the authorities and not a LabVIEW forum on the internet. Please do not use sensationalist titles in the future to grab the attention of the users. Spammers use the same technique and they are handled by being banned. LabVIEW ships with several games. Search for Moon or Moonlanding in the example finder for one.

Probe the path wire going into the New Report.vi when the VI is ran. You'll see that the path provided as a xls template is a path to a location that doesn't exist. Your XLS file is in the same directory as your Main.vi but you stripped the path twice meaning the folder above where the main is. Remove one of the strip paths to fix that then if you have the report generation toolkit installed it will open excel and make your spreadsheet. It doesn't get saved because you didn't use the Save Report to File. Call this before the Dispose Report. EDIT: Cross post http://forums.ni.com/t5/LabVIEW/Error-7-with-Report-Generation-Toolkit/td-p/2695725

Cross post: http://forums.ni.com/t5/LabVIEW/Embed-Screen-of-a-remote-machine/m-p/2693305/highlight/true#M800368 As suggested there download the ActiveX components and look into Microsofts documentation. http://msdn.microsoft.com/en-us/library/aa383541(v=vs.85).aspx

I fear he is trying to detect "Planes" by providing an image of a plane then seeing if the program can detect a plane in another picture.

What have you tried? It sounds like some LabVIEW tutorials would go a long way. Here are some of the typical education links I share most are free. 3 Hour Introduction http://www.ni.com/white-paper/5243/en/ 6 Hour Introduction http://www.ni.com/white-paper/5241/en/ LabVEW Basics http://www.ni.com/gettingstarted/labviewbasics/ Self Paced training for students http://www.ni.com/academic/students/learn/ Self Paced training beginner to advanced, SSP Required http://sine.ni.com/myni/self-paced-training/app/main.xhtml LabVIEW Wiki on Training http://labviewwiki.org/LabVIEW_tutorial#External_Links

I didn't realize this conversation had the scope limited to a button, and more so limited to the decal. This changes things slightly. Controls do not have multiple decals and a selection for an index (but sounds like an idea for the exchange maybe) One option is to use a Picture Ring. This contains multiple images and you can choose which to display. Instead of having a value change be triggered when the user clicks, you could capture a mouse down and change the picture ring to show the new image. A little clunky but it could work. There is a way to programatically replace a decal of a button, without the development environment. Here is a discussion on it. https://decibel.ni.com/content/thread/4901?tstart=30 This replaces the PNG images within the control and is not something NI would condone because it is messing with a file, whose structure is not documented, and could change at any time. This works well enough but again the .ctl file can't be inside the EXE. So you would need a way for the control to be loaded in the EXE from disk, and not from reference, or force the reference to be loaded from outside the EXE first. But then you will get warnings from the EXE saying control was loaded from a different location.

1) I've never known NI to post how the offset will drive with temperature. Only that it will remain within the specified tolerances, if it is within the temperature range that the card is rated for. 2) It appears this card also supports some kind of daily calibration I am not too familiar with it but there is a document on it. 3) Resolution can be found in the specifications for the card. It really depends on the selected range for the card. It is a 24bit resolution, but the range can vary between +/-42.4V and +/-316mV. This gives a resolution between 0.005mV and 0.00003mV. All this information can be found in the two documents. http://www.ni.com/pdf/manuals/373770j.pdf http://www.ni.com/pdf/manuals/371234b.pdf Which were both found at the product page under Resources. http://sine.ni.com/nips/cds/view/p/lang/en/nid/202236

For this to work you will need a full LabVIEW development environment. The LabVIEW Run-Time engine does not have the features needed to edit or resave a VI and that is what would be needed. This means this feature cannot work in a EXE. So if you have a full LabVIEW install you could do this using LabVIEW scripting. Go to Tools >> Options then VI Server page and check Show VI Scripting functions. This will add scripting tools to your palette. With scripting you can programatically open a VI and replace the control with the one you want and resave it, then run it. I believe packed libraries are made to act as a step between source code and an EXE, where you have the VIs but they don't have block diagrams or front panels. I know there are options to remove these or leave them but I don't know the default. If your VI has no block diagram then you can't edit it and resave. So for this to work you will need LabVIEW development, scripting, and VIs that can be edited.