Michael Aivaliotis

All this talk on Info-LabVIEW lately regarding recursive algorithms has prompted me to post a version of the Recursive directory listing VI that uses true recursion in LabVIEW. By this I mean using a VI that lists the directory structure of one directory and then have that VI call itself for any subdirectories it may find along the way. I realize this setup creates a huge performance hit however I think it should be included in this posting for completeness so it can be compared to other implementations. Enjoy. Download File:post-10-1086381407.zip

I was recently informed that there is a method to submit wish list items directly to NI. Here is the link: National Instruments LabVIEW wish list You can submit LabVIEW product suggestions directly to NI via the above link. I would strongly recommend that you also include the contents of your suggestion to the LAVA wish list forum as well. I suggest this because it is possible that your wish can be something that is achievable with existing tools. Another member might have a solution, a workaround or may be willing to create a VI that does what you want. Making your wish public knowledge fascilitates this open discussion on the wish list item.

I started looking at TCL and found it interesting. I've created several test executives in pure G but never thought of trying an external script engine like TCL. Going through the TCL docs doesn't give me specifics on the TCP/IP comm you describe. Where do I start with this approach?

Sounds like you should post this to the wish list: http://forums.lavausergroup.org/index.php?showforum=14

Well, I took my previous implementation back to the drawing board and decided to go with a sub-vi call. In essence, the menu list is a subvi that pops-up. It works quite well actually. I was surprised at the excellent look and feel of it. it looks like a real right-click menu. it might require a bit of programming to create nested menus but it can be done. Best of all, no WinAPI call required. :thumbup: In the process to developing the above implementation I tried using Callback VI's. It almost worked however I was getting LabVIEW crashes and hangups. The Callback VI was the menu so it contained the event structure. When the menu was selected and the Callback VI panel was closed, LV would hang. Maybe I'll post that version seperatly. Download File:post-19-1084516114.llb

I created a LV7.0 VI that shows how to do this using the event structure and a listbox. I am not Entirely satisfied with this implementation because it has an issue when you right-click close to the border of the VI. The menu gets chopped-off. However this implementation might be ok if the right-click requirement is needed for internal areas of the VI. Download File:post-19-1084498075.vi

I don't know the answer to your LabVIEW commnd line switch question and I don't know of any other utility to verify VI's. On the other hand, it sounds like you're an expert at PHP programming so there might be another way. What you can do is build an EXE in LabVIEW that is responsible for handling the launching of your VI's. Then that utility can do a verification by dynamically loading the uploaded VI. If it is invalid or corrupt then you will get an error from the "open Vi reference" function. The utility can then write a flag to a MYSQL database or into a textfile. You can make a PHP script to go and read the result of this file or database entry. Also, I would be a little concerned about allowing users to upload and launch any VI onto your server. That VI can easily have a "deldir" function ! I'm curious, how are you presenting the results of the VI execution to the user? Is the VI running in a remote panel container?

I don't know of a way to enumerate the items. However you can bring up an interactive window programmatically. If you go to the datasocket pallete then you can run the VI called Datasocket Select URL.vi. This will allow you to choose a URL. I know this is not ideal but I see no other way.

If you go to LEM's website then you can download the drivers. The NORMA 5000 drivers should work, not? They have LV7 drivers and excellent documentation. Here's the link: NORMA 5000 LabVIEW Drivers

Windows 2K should not matter and running an executable should not matter as well. This is strange, I've never had a problem with this method on any platform. I'm not sure what is different on your computer. You should try this on another machine and see it it has the same behaviour. Since you have all the utilities, you will see another one called: make window always on top. This will make the widow frontmost always even if you click another app. Try this one and let us know.

You can't do this using any of the built-in LabVIEW functions or capabilities. For this to work you need to make a call to the user32.dll in Windows. There is a collection of VI's available from many sources that will do this for you. Here is a link to NI's site where you can get them: Windows API Function Utilities (32-bit) for LabVIEW In any case, I've put together a LV7.0 version of a VI that will do exactly what you ask. I've attached this. Download File:post-19-1083913103.llb

I have attached a VI that demonstrates this issue. The problem started when I switched from using the FP.Open property to the Open FP method. NI notes the following in the help file: So after converting all my properties over to this new method, I noticed that my subpanels where not working as expected. I also noticed that I could not abort the VI's that contained this new method. So if the subvi uses the Open FP method and it contains a subpanel then you will not be able to manipulate the subpaneled VI. Download File:post-16-1083739174.llb

It's not clear from your post what you actually require. Are you looking for an FTP program? If so then what Jim posted above will work for you. However, if you're looking for a way to remote control your VI's then you can do this already using the Remote Panels feature. This is built into LV7. Let me know if you need more information.

Actually LabVIEW is doing exactly what you are telling it to do. LabVIEW does not care what order you create things in. You can build the tree out of sequence. The only thing that matters is the parent tag. In your case you are telling all the childs to attach themselves to a parent that has a tag with the label "a". If you look at the LV help you will read this: So this means that the new parents will have the following tags: a a_1 a_2 You can see this after you run your VI. If you right-click on the tree control and select Edit Items... You will see tag a_1 etc. So, the key is to attach the child to the correct parent tag. How do you do this? Well LV provides the tag value that was generated for the parent tag. You can use this value for the reference to the child. I've shown you how to do this in the attached image.

Well, the key is that you need a 2D array of data to feed into the spreadsheet write function. I've attached an image that shows you the solution. Hopefully you can grow back most of the hairs you pulled out. As far as general coding practice, there is much that needs improvement (sequence structures... ouch!). When I have more time I will upload an improved version so you can see another approach.

Yes Dean this is a great idea. I took a look at the VI you were writing about. I have an issue however with the label that NI gave to the indicator. It should not be labeled "Shortcut or not a path?". That implies that the boolean will be true if it's a shortcut or not a path, which it is not. It would be better to call it "Valid Path?". If you look at the icon it says "Valid?" right on it. I know this is minor, but still unacceptable in my opinion. Either you apply standards to your coding or you don't. In any case... It seems simple enough to integrate this code into the Recursive Directory Listing VI. It would make sense to add it into Rolf's version since it appears to be the fastest. I guess a switch to turn link checking on or off would be nice too. I will take all the suggestions and enhancements in this topic and create a VI which can then be submitted to the OpenG library. Whoever has submitted versions or suggestions to this topic will be given credit. Personally I use the OpenG library quite a bit however I don't use certain VI's in it because they are not optimized. This is our chance to help out and create a VI that we can all use. Since most of you who have posted here are already willing to share your code, I will assume that you agree with the OpenG licensing. However if you are not familier with it, please read it over here. You must agree to this license if you want to participate. So, on that note, can anyone suggest any other improvements to the VI's listed in this topic? You can take a previously submitted VI and re-write it (like Rolf did) or create another approach. I will work on creating a test routine to provide performance checking. If you have suggestions on a test VI please let me know or just submit it here.

Yes, I can reproduce this. Also, if you break the express VI you will see that NI doesn't replace the complete string variable. See attached image.

Thanks for the code examples guys, it will help me in other areas, however what I really wanted was to create a (strict) property node to an existing control. This should not be wired to a reference but implicit. I'm afraid this is not possible with what we know, right?

I'm trying to create a property node and then associate (link) it to a specific terminal or control. I can't seem to figure this out. Anyone have an idea? I'm using the New VI Object function which creates a default property node but I cannot seem to get further than that.

Well, a very BIG thank you to PJM for this post! He's opened up a whole can of worms. I immediately started diving into the different classes and tried to figure out the hierarchy. Now I can finally get the feature I knew NI would never add to LabVIEW. I think our wish list will slowly disappear since if we need something we can just program it ourselves. I always wanted to have LabVIEW automatically color my diagram a slight shade of grey. But I also wanted every other structure to have white. So you would end up with grey-white alternating. Well, I just created a VI to do this! The process of building this VI was fascinating. It turns out that the VI diagram reference is only useful for listing diagram objects outside of structures. If you want to explore objects inside of structures then you must get a diagram reference to each structure. In addition, each frame of a structure requires another diagram reference. A simple comparison can be made between this and nested clusters in controls on the front panel. Of course this could only be resolved with recursion. I've attached the complete code that does this. By the way, If you don't need alternating colors then just make both colors the same. Hmmm.... what should I create next. Download File:post-29-1081666033.llb

Ni has a fix for this: I've attached the link: Insane Object Errors When Adding or Removing Needles or Sliders in Properties Dialog Box

Well, Jim is partialy right. You need to decode 2 frequencies. These are added to determine the X Y coordinates of the keypress. Three frequencies define the columns and 4 frequencies define the rows of the keypad. In any case, if you open the LabVIEW example called - Sim Phone.vi, you will see what I mean. I have built a VI that decodes the DTMF tones of a common telephone. I tried it on my crappy handset at home using a microphone attached to my headset and it seemed to work fine. If this is for a test system, I recommend a high quality microphone. There seems to be alot of variation in frequency. You might have to tweek the frequency ranges I selected in the decoding section of the VI. If you don't want to use a real telephone then you can use the LV Sim Phone.vi example (i've included it in the attached llb) with your PC sound card. The attached VI is LV7.0. You might need some advanced analysis DLL's that are only available in the LabVIEW full development version. If anyone who downloads this code can improve upon it then please do so and upload it back to this topic so all can benefit. Download File:post-10-1080893317.zip

I wouldn't say that using templates is needless. I hope NI leaves the usage of templates the way they are. I like them. One major benefit of using templates is you can debug your code while it's running. Reentrant VI's have annoying limitations. You cannot probe data on wires and you cannot view the front panel data.

Welcome to the forums Michael :beer: Yes, I agree with you 100%. Using variants is much more flexible. I use the array of variants implementation you mention as the main pipeline for passing data to test modules in a test engine. Check out this related post: Passing variant data through string comm link.

It looks like there is a solution to the Info-LabVIEW problems. Tom Coradeschi posted this announcement on the list: Let's all thank Tom for his initiative to start the info-labview list way back when there was nothing else around. I hope the new home is much more stable and lasts for as many years as the previous one.