hooovahh

Amen! Anytime I concatenate more than 3 strings, it's time to pull out the Format into String node. It usually helps eliminate upstream code as well, as it would in this case.

You dislike the concatenate string function so much that I use it just out of spite.

But seriously I have a bad habit of over using the concatenate function and find that using format into string is almost always better.

The OpenG tool look interesting. Was there a reason it wasn't built into a package? Possibly into the Application Control? Or Builder package? I think there are places that the OpenG method, and my method could both be improved. Over the weekend I was thinking about all the stupid things I did in mine that could be much simpler, and support for array of controls could be made simpler too so you just need to make a scalar of the data type then specify the size. Not sure if I'll ever have time to improve my method but I wanted to get it out there for others to look at and possibly improve on.

So in a recent discussion here the was talks about scripting polymorphic VIs. At the time I was surprised to hear that no one had made scripting code to generate polymorphic VIs. This feeling passed when I realized several people have attempted to generate polymorphic VIs through scripting. There are some on NI's site here, as well as some older ones on Lava as well. Still I didn't realize this until I had taken my own go at it.

So here is a really beta version of my attempt to generate VIs that are 99% the same as another VI, with the small exception that the controls on the front panel have been replaced with a different control.

Attached is my quick and dirty approach. Open "Main Create Wizard.vi" and run the VI, it will prompt you for a VI to use as a template. I have included an OpenG version of the Filter 1D array under the Example Files, I also renamed it so it shouldn't conflict with already installed OpenG code. Then choose the controls that you would like to replace in the new interface by clicking the boolean corresponding to the control connected to the connector pane of the VI you selected. Then choose the control types to replace the selected controls with. These control types are just controls on disk and by adding any control to the folder "Control Types" you will be adding them as an option in this window.

At the moment it is quite limited. You can only replace controls that are on the connector pane, and they all must be replaced with the same control. So you can't do anything fancy like replace one control with a path, and another with a 1D array of a path. I think that wouldn't be too difficult to add but I didn't want to spend too much time on it. The code should then generate a VI for each control type you selected in the same folder as the template VI you selected at the start.

This code relies on some OpenG packages, I'm not sure all of them but File, and Array for sure. Let me know if you have any questions, and feel free to modify and post your updates.

Create Polymorphic VIs hooovahh.zip

I just posted an idea on the idea exchange related to the polymorphic VI creation.

I'm actually quite surprised no one has made a scripting VI (or no one has shared it) that can do this. I agree it should be build into the IDE (which is why I gave a Kudo) but this doesn't seem that hard. If I get some time I may give it a try.

I'll be at the Walled Lake location. It's hard to tell from the site but is this basically the NI Week presentation on 2012 with a little Q&A?

Yep, the built-in search is pretty much garbage. I almost exclusively google site:lavag.org whatever my heart desires.

I just had to try the link to see what comes up. Turns out this thread is the number one result for whatever my hear desires on this site, go figure.

And just to stay on topic I will not be attending NI week this year. My boss mentioned it, but I said no. I just started this new job and didn't think it was good timing to leave so soon after starting. But we agreed next year I will be going. I've never been to NI week but am excited for the chance to go, even if it won't be for another year.

I did some testing... everyone was using Match Pattern... I found a code snippet that was faster than that in every scenario I tested:

I wasn't sure if it was only prefixes that were being sought ... all the test harnesses only created prefix test cases. If you want "anywhere in the string", then this doesn't help, obviously.

I realize some of my posts are a little long winded so I don't blame you for not picking up on what I was trying to say. In my first post I said this:

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.

Which was my way of saying that the search should be throughout the string. If I knew it was at the beginning I would use your technique with the string subset.

Also I may be missing something, but why does concatenating a "^" symbol cause the Match Pattern method to work faster?

Our internal solution is quite similar to wouters solution. The big differences are that we use "ArraySubset" instead of "DeleteSubset" and that we reuse the incoming search array to store the result.

I have not bechmarked it against the other solutions, so I don't know if it is faster or slower.

/J

I'm starting to get inconsistent results, but from what I've seen it looks to be one of the better solutions but not the best. The best I've seen would either be Method 3, or Method 3, modified as wouter suggests.

A bit of lateral thinking?

In my tests this did not perform as well as the others. It would usually be 4th or 5th place in any array size. Not terrible but not the method I would prefer.

Maybe something like this:

I'm not quite sure why but your VIs on my system took 34 seconds to search through, using 10,000 items in the array, and it took over 900MB of private memory.

To compare my original post took a minimum of 169ms and 1.4GB of private memory for all 6 methods. At the start of all of this I said the only real criteria was time for execution so the memory usage is a little unfair to add as a requirement, I simply wanted to give a comparison.

An alternative to the toolkit could be a command line call to FTP the files. I think the toolkit version is the clearest solution, but if all you want to do is this one function you may be able to do it another way. All though it is just $500.

Windows has a built in FTP command line program (just FTP at a command prompt). I've never used it but I assume it has the ability to login to a server and send a file over.

Let's all be clear here, we are talkiing about Event Structures (and Stacked Sequences if you are keeping score). Remove Frame is implemented and works just great for Case Structures and Disable Structures (only ones I have tested).

To help with the clarity I've made a VI that shows the error. It will make a new VI, drop down an event structure, add a frame to it, and then optionally attempt to remove that frame, then open the block diagram to see the result. If you choose to remove the frame after making it, there will be the error we are talking about.

Maybe that's the case - maybe not. My guess is that no one uses it internally at NI, and that you've tried to use it will jog their memory to include it in a subsequent release.

Thanks Crelf, you saying that made me realize this may be better answered at NI's forums so I posted there as well.

I played with this just now. Let me post my remarks. The tests where done with 1 million elements

....

Wow thanks alot Wouter. I'm not sure why I didn't think of pre-allocation. I think this would make a nice little reuse nuggest for the community or OpenG some day. I also did notice that with a smaller sample this method 2 with pre-allocation doesn't always win but it may be the best solution overall.

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:

LabVIEW: This property or method is not yet implemented.

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'm always afraid that if they did introduce something awesome enough to make me upgrade from LV2009; they would stick it in a toolkit

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.

But that's part of the problem with the Idea Exchange kudos system; the top 10 ideas *are* low hanging fruits with minor impact already. The good ideas (as in; will significantly improve the power of LabVIEW and the products we can make with it) hide in the middle and even lower ranks.

The current top ten ideas yet to be implemented or declined are:

1. Wait (ms) with error pass-throu​gh

2. Show hidden controls as "ghosts" in edit mode

3. A faster & neater way to show Cluster Element Labels

4. Probes for Loop Iteration

5. Selection of Items on BD or FP needs to be Easier!

6. Some indication that a string control isn't showing the entire string.

7. Align objects should not align increment/​decrement buttons

8. Same Height of Unbudle by Name / Terminal / Local Variable

9. Include LabVIEW Version Number in Applicatio​n Icon

10. Smaller Event Ref Constants

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.

Because you can change the colors to transparent and overlay graphs with images, you can get any sort of look you want.

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

This would be a pretty cool pet project, but if it were what I was employed to do, I wouldn't really be satisfied until it ran.

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.

Whilst I applaud the coolness of this effort, if I was an engineer on this project I can't imagine feeling particularly satisfied that I'd used my talents in a worthwhile way to make the world a better place.

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.

What JKI does with VIPM, is making an executable, zipping the executable up.

Store that zip as a string inside a VI. Then use the installer VI to extract the zip-stream.

Ton

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.

The last time I had this problem I found this:

http://digital.ni.co...6256E93006E31FA

Written for LV 8.2, still true in 2011 AFAIK.

This works perfectly thank you.