hooovahh

Crosspost in NI Forums So I saw a new error today, one I've never seen before but I'm assuming other have. It is error 1072, and the text along with it is the following: I was not aware that LabVIEW shipped with method calls that are available without hacking, which are not implemented. I was attempting to use a invoke node to remove a frame from an event structure. I was first frustrated in the fact that I couldn't programatically get the name of each event case. There is a Lava post here which attempts to read it using OCR but has issues with different system fonts, clear type, and cross platform issues. I decided to just delete the frame based on the index and not the text since that seemed to difficult to find. Apparently this won't work either and I was forced to come up with a work around using a disabled diagram structure, which would have duplicate code in each case, other than in one the event structure has the one case removed that I wanted. I would then remove the disabled structure leaving the case I want, with the events I want. The post I linked to earlier is from 2009, and I'm a little surprised to find out that the event structure scripting tools are still immature. Can anyone comment on their development? Or what other scripting functions are available to but not implemented? I assume features like "Remove Frame" are implemented and NI uses them, they just aren't exposed. If that's the case I'm surprised that NI couldn't find the time to expose these functions in the couple of years scripting has been mainstream.

So I embarked on a little journey this morning. Many times when developing code I have the need to search an array of string for some pattern. Usually I am looking for some set of characters in a string and then I need to get the whole string, and possibly the index that the string was found in the array. There are many different ways to do what I just mentioned, some more obvious then others, and I wanted to know which was the methods that should not be used for larger arrays, and which method appears to be the best, on a Windows machine with time to process being the only thing to judge on. So attached you'll find a VI (saved in 2011) which generates an array of strings. Each string will be between 5 and 15 characters long and the array size is controllable from the front panel. For approximately half the elements in the array, a string will be appended to the front of the generated string. These are the values we will search for. We then search the array looking for the indexes that contain the string we are looking for. In this example the string is appended to the front, but I would like to make this generic and I am assuming the string we are looking for could be any where in the string not just the beginning. I use 6 different methods for finding the indexes and calculate the time it took to find them. I noticed for arrays of 1000 elements or less it doesn't matter too much. Each of the 6 methods take 0 or 1 milliseconds to complete. For 10,000, or 100,000 the winner is Method 2, which uses the Search/Split String, combined with the OpenG Conditional Auto-Indexing Tunnel. I know this is such a simple task, and for most cases it doesn't matter, but I was wondering what others have found. Is there a method that is generally preferred more? My thoughts would be that Method 1 would have been the fastest, since we only have to iterate over the items once, instead of an OpenG method, but I do realize the Build Array is an operation which can be bad for memory. Search Array Of Strings.vi

I went from 2009 to 2011 so I'm not sure which neat new features are from 2010 or 2011. The changes for me aren't some thing I can't live without, but I do use some of the newer features all the time.

I'll admit that the current top 10 has no killer apps, but it has several things that I would use on a daily basis to help me save time, either in development, or to better document my own code. I have also seen some good ideas with not much attention. LAVA is a decent sized community, and if we collectively see something we want in LabVIEW, NI will notice hopefully implement it. Let me be clear I'm not saying we should all band together and vote for one thing, I'm saying that if an idea is truly a good idea, and it doesn't have much attention, post about it here and let the community decide.

I usually start with a NI example, they aren't perfect but they give a nice starting off point. I recommend the "TDMS Logging - Cont Log and Read Data.vi" found here: <LabVIEW Directory>\examples\DAQmx\Analog In\Measure Voltage.llb\TDMS Logging - Cont Log and Read Data.vi I'm guessing your problem is the fact that you are doing a single sample read, which takes a very short amount of time, but then in a loop read again, this whole time the AI read task is still running filling up a buffer, and by the time windows requests another single sample, there maybe hundreds of samples waiting to be read. This eventually fills up and you run out of your buffer on the DAQ hardware. To prevent this try to decrease the sample rate, or increasing the number of samples to read. The example above uses 1K samples at 10KHz.

I'm sure you don't need my compliments, but that is a very impressive looking graph.

Yeah I'll admit I was half expecting it to just be a stationary model. When I saw it spinning I really wanted to see it go all out, and start spinning until the thing broke up all of its pieces. I guess that wouldn't be too good of an ending to 8 weeks worth of work.

They probably learned a lot on that project, learning is satisfying if you enjoy the subject. This subject is legos so I probably wouldn't have a feeling of being satisfied either. Some would say developing in a "fisher price" programming language can't be particularly satisfying either. It does seem like this could make a nice marketing tool, for both Lego and Rolls Royce.

Interesting that they can sell the "Student Edition" to non-students, or rather people who are not enrolled in a higher learning facility. In the comments someone links to the NI FAQ on the difference between versions, and it seems like the difference is there is no support from NI, and you have water marks on the VIs which are removed when ran in a professional version.

That's one way of doing it. If I was going to make my own installer, I would build an EXE with LabVIEW 7.1 or older, so that the runtime engine can be included. I would put my real EXE (built with modern LabVIEW) in a subfolder along with any support files (possibly the required runtime engine as well). Then zip all that and convert it to an EXE that runs my 7.1 EXE after getting extracted to a temp folder. That way there is only one EXE to the user, that they run, extracts and runs a LabVIEW EXE and runs without any runtime engines installed, and from there can install my application or other components. Of course coding in 7.1 isn't impossible, but there are some functions that are taken for granted that I may have to code my self which were not available then. Also I'll essentially be including two run time engines. The 7.1 runtime engine was around 12MB zipped up so it won't add alot of space but still is extra code that won't be used after the install. I've never done this approach, because it is re-inventing the wheel and supporting a tool seems like a pain, for very little added benefit.

I'm not quite sure what you're asking, so I'll answer the question I think you are asking, because I know the answer to that question. In the past I've used Inno Setup to make software installers. Part of the installer has the ability to have standard installs, custom, minimal, and settings for what to do based on the users selection, as well as installation directory and what to do during an uninstall. I've used this in the past to install several NI components at once. Lets say I had LabVIEW Run-Time engine, the TDMS for Excel Add on, and maybe any number of other NI installers, in my build. Then each of these can be a checkbox during the install, which will simply run the setup.exe for each component, with what ever silent switches that are needed. I've also used ISTool which is a piece of software that helps make Inno Setup installers. I don't believe there is much for UI customization, I've always used the plain one. One thing I would be interested in is how JKI does it for VIPM. I'm guessing what they do is very customized and probably not something worth sharing.

This works perfectly thank you.

Sorry I didn't give more detail, I didn't want to inundate anyone with too much information, especially if the answer was a simple property node. I'm doing something similar to Ben's Docking code. http://forums.ni.com...cending#M351512 Here VIs get pulled out (sorta) and become floating windows. In this case the VI always is open, it just may be in its own window, or in the subpanel. What crelf said.

This returns true when in a subpanel. EDIT: Also I started looking at the properties/methods available to a subpanel and I was surprised at how few there are. I couldn't even find one to tell me what VI was loaded into the subpanel. Is there really no way to know what is in a subpanel. DOUBLE EDIT: Apparently it is in 2012 beta. http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Add-subpanel-property-VI-Ref/idi-p/1214481

I think I know the answer to this, but is there a way to know if a VI is loaded into a subpanel from the VI that may or may not be in the subpanel? So say I have 5 VIs running, each of them can be loaded one at a time into a single subpanel in a 6th VI which is running. Is there a way to know from any of the 5 running VIs, if they are currently loaded into the subpanel? At the moment I am keeping track of which VI is in the subpanel from the 6th VI which the subpanel is in and this works fine, I just didn't know if there was a better solution. I have also noticed that the property Front Panel >> Title Bar Visible will be false if a VI is in a subpanel, so this could be used as long as the VI has the Window Has Title Bar set to true in the VI properties. This solution won't work for me, because there is the occasion where the VI will have no title bar, but will be outside the subpanel.

Wow this takes me back. So I forgot about some code I did when I was first learning LabVIEW. I had a java program that made an analog clock, so I wanted to recreate it in LabVIEW as a test of my newly found skills. Here is the result. I'm a little ashamed of my code written back then, but it was a learning experience. I'll probably look back on the code I'm producing now in several years and think the same thing. Edit: Man I need to update my site some time.

The question was about Multitouch. For LabVIEW to support multitouch, first windows needs to support it. By default if you installed two mice on your PC, you still would only have one pointer and both mice will control the same pointer. As mentioned by Yair a touch screen is just a mouse so to support multitouch you really need to support multi-mice. A quick search found several 3rd party programs to have multiple mice in Windows, but I've never tried any.

That's what I was going to suggest. At one point I was trying to interface with 7-zip through the command line and I believe it too supports gzip compression.

Saved in 2010 Add Edit Scale 2010.vi

I haven't tested it in anything other than in a development environment, but I believe it will work in RTE as long as the DAQ Assistant VIs are installed. The DAQ Assistant VIs actually call a NI DLL called mxwlvapi.dll, this is what actually does the heavy lifting and I assume this is installed with DAQmx. So theoretically you could create an installer, which has the added installer of DAQmx and this should still work, that is assuming you get the path to the Assistant VIs correctly. I believe there is a registry read that can be performed to help find this. Possibly something like %National Instruments Folder%\MAX\Assistants\DAQ Assistant\common\supportFiles As for how I did it...well, the forums have been discussing very grey topics lately, and one of them is block diagram passwords, and how they have been defeated. So out of my curiosity I started looking into all the VIs that were locked in VI.lib to see if I could find anything useful. I couldn't find much, most of VI.lib that has a password is simply a dll call. AQ has mentioned recently that most of the passworded VIs have been unpassworded to help share with the community and that is apparent here. So I searched my whole National Instruments folder and found these llbs named expressVIsXX.llb with different versions for all versions of LabVIEW. By opening up the daqmxNewItem.vit and daqmxEditItem.vit you can see that it has a control that gets casted to a DAQmxName object, and has code for Channels, Tasks, and Scales. So you can actually use this same code to Create/Edit a Virtual Channel or Task. I'm not sure why this information isn't a knowledge base somewhere other then the fact that NI may choose to change how these VIs work in the future. AQ has mentioned recently the dangers of using code from a password protected block diagram, but I don't believe this falls into that category, because I didn't use any code from a passworded VI, I'm just calling it, and I needed to know the type of input it wanted for a control. Looking at the BD helped me understand what was needed. In any case NI can still choose to change this functionality in the next version of LabVIEW if they choose.

Looks like you put in a lot of effort into this. One thing I noticed is the list of existing scales show all scales, even ones that are not appropriate for the current tab. So if I have a linear scale, but am on the Map Ranges tab, my linear scale shows up in the list, and trying to edit it doesn't work. Why not only populate the drop down with the scales for that type? Also is there a reason you are doing this all manually instead of using the DAQ Assistant? Attached is a quick VI I made to edit or create a scale. You may need to update the path constant on the block diagram to point to your DAQ Assistant because the path is set currently to a 64-bit Windows, running LabVIEW 2011. Add Edit Scale.vi

I'm very interested in this. I don't want to cause you any work getting an extensive list, but is there an easy way to know what information can be read without loading the VI and all of its dependencies? Edit: I may have found my answer is it the "Loads the block diagram into memory" remark or note, on the property/invoke node?

I've yet to use this feature but on my next new project I planned on not including compiled code. I'd like to hear other users sound off on any issues like these, so I know to avoid it for another version or two. I also wouldn't mind hearing people that have used this feature and have had no noticeable issues.

Some times I wish there were a more open file format for LabVIEW. I'm not looking to write my own IDE, but to be able to open the vi and determine what kind of objects are in it, or what labels there are without having to open it in a development environment would be nice. Lets say I want to do some documentation generation on a folder of VIs. Right now I can read the icon, and VI description without needing to start LabVIEW by analyzing the bytes in a hex editor. But what if I want to get the connector pane information? Like what terminals labels are and their data types? Or what if I use Requirements Gateway and I want to find all labels on the block diagram that start with "Covers: ". Looking at the VI file structure I have not been able to find free labels or text. Here are the things I have been able to pull out of the VI file structure by analyzing the hex bytes: Main/Internal VI version, LVSR Main/Internal version, flag bits, if a VI is protected, the Window Title, the Help Path, the Help Tag, the VI Description, a 24-bit image of the icon, and a 1-bit image of the icon. I think I can also determine if a VI is re-entrant, and the Revision History if I spent some time. I thought about releasing my findings on how to pull out this information from a hex dump of a VI in the hopes someone will be able to get more information, and possibly pull out free label text. If anyone is interested I can try to put some time into cleaning it up a bit and releasing it. I mostly stopped trying to figure out the VI file structure because most of what I want to do can be done with LabVIEW Scripting. I just think that it could be done faster by reading the VI file.

So I did develop a fix of sorts. I basically re-created the functionality of the Plot Legend so that I could do the things I wanted. Like don't allow the value of the vertical scrollbar to be greater than the number of plots, and allowing me to change the value of the scrollbar programatically. The problem with re-creating the Plot Legend is there is a ton of functionality in it. Changing plot color, plot type, line width, line size, bar plots, filling to other plots, interpolation, point style, scales, exporting data, and a few others. What I did was re-create the functionality I used the most which was a very small subset. In the end I wasn't satisfied with the results and all the extra code involved so I reverted back to the normal Plot Legend just leaving a few known bugs with how the graph functions.