-
Posts
3,433 -
Joined
-
Last visited
-
Days Won
289
Content Type
Profiles
Forums
Downloads
Gallery
Posts posted by hooovahh
-
-
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.
-
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.
-
1
-
-
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-through
2. Show hidden controls as "ghosts" in edit mode
3. A faster & neater way to show Cluster Element Labels
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
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.
-
-
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.
-
1
-
-
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.
-
Isn't that what you were after? If the subVI is running on its own as a "regular" subVI then its front panel would not be open. When in a subpanel the front panel has to be open, so the subVI can check itself based on whether its front panel is open. The property would still be true when the VI is running on its own, but does that matter in this case?
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.
-
What about looking at the Front Panel Window's Open property?
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.
-
1
-
-
Yes, it might be used to multi screen in Labview. Just check with the VI properties.
Might be attached image will help to do multiscreen.
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.
-
But integrating gzip by using LabPython is really very roundabout. Have you looked at executing the gzip executable through System Exec?
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.
-
Fastest Search Array of String
in LabVIEW General
Posted
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.
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.