Michael Aivaliotis

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.

Yes, it would be a good start to get all the previous subscribers imported over. This, however can also happen at a later time. Right now we can just let everyone (including Tom) know the backup is there and there is a desire to continue. I've sent an email out to the list to let the existing members know and hopefully most will be willing to subscribe. Also, I think the existing members should have the choice to have their email address migrated over. We'll just have to wait and see if Tom responds. As you know, he is very busy and this list is very low on his priority list.

Yes, this is good. However since you already have auto-indexing enabled, adding the array size function is redundant. You will see that if you delete this function and the wire to the N terminal, you program will still work. In general, a for loop will iterate for every element in an indexing array input OR the number wired into the N terminal, whichever is smaller. If you have an array of size 10 and wire a 5 into the N terminal, the loop will iterate only 5 times regardless of the array size. Also, if you have an empty array then the loop will not iterate at all.

Well, I decided to put up an alternative Info-LabVIEW mailing list. Since it is a fact that many people refuse to use web based forums, I think a mailing list is essential. Right now, the original list is up and down. Here is the link to the new subscription page. Alternative Info-LabVIEW mailing list subscription I'm not trying to bully my way into anything. I just want to help the community. Feel free to sign-up and send messages. Time will tell of what will happen to the original info-labview list. In the meantime let's move on. If the original ever gets revived then I will shut-down my list.

Oh, now I know what feature you might have seen. This comes back to "playing" with graphics programs. You can now add animated GIF's to your controls. This will do exactly what you want. No special thing you have to do just generate 2 different animated GIF's in your graphics package and then place it in the 2 different states.

I guess my point is that, in user interfaces, your front panel objects should always "look like" how they behave. Even if you managed to code around this, you shouldn't. The "look" of the existing button conveys the following message: There are 2 buttons here. However they are covered by an icon that spreads across both. So, if you want the right side then click the right button but don't click the icon. If you want to click on both buttons then click on the icon, this will depress both buttons. Do you see my point? By splitting the icon in 2, you have suddenly changed the message you are conveying because now you have a dark "crack" between the icon. So, the operator "understands" that both buttons operate on the same factory but for 2 different purposes. There is no confusion. A better addition would be to add arrows to the 2 icons. Yes, arrows are sometime ok. One on the left -> (inbound) and one on the right -> (outbound). Hope this helps.

Well, before I give my response, I want to know the user interface purpose behind this decision. Why split it into 2 sections? Are both clickable? If so, then isn't this confusing for the operator? What message are you conveying? I would just split the image in 2, half on one and half on the other. No code changes are good. 5-10 minutes using an imaging application is better than extra programming. My opinion anyway.

I guess this should be a wish-list item. As fas I'm aware, this is not possible yet. I guess the closest thing would be to create a sub-vi with the code and feed-in a ctrl reference to the control of interest. Would this work for you? What exactly do you want to do with the custom code that can't already be done with conventional methods?

There was a post from Tom on Info-LabVIEW today regarding the future of that mailing list: I sent a personal reply to Tom offering the lavausergroup server as the new home to the info-labview mailing list. I hope he responds favourably so that we can keep this institution alive. :thumbup: There is an ongoing debate comparing the pros and cons of a mailing list to web Forums. In my opinion, both have their place. It would be nice, in the near future, to see them both combined so that posts to the forums can be emailed out and posts to the mailing list can go to the forums. This is an idea that I have been experimenting with for some time but not fully implemented yet. Of course public opinion would steer the debate. In any case, the LAVA server is here and ready. It also has the mailing list infrastructure to handle the new list. We already host the LAVA user group mailing lists. Comments are of course always welcome.

I agree on this. So far I have been impressed by the interest this one topic has generated on our Forums. It started as a simple announcement and took on a life of its own. I appreaciate the contributions everyone has made and encourage those that are silent to participate. It just shows that it is important to have an open forum where these discussions can take place. It also helps to have the history of all comments made so it can all be put into perspective. -- I look forward to more exciting discussions like this. ...

Ok, I think the best approach for you would be to use the GPIB interface on the back of the instrument to retreive the data into LabVIEW. You will need a GPIB interface card on the PC. Here is a link to NI's website to purchase a GPIB controller: GPIB (IEEE 488) Solutions The next step would be to build a LabVIEW driver for this instrument. Thankfully, there are drivers already built for you. Here is a link to download the driver for the 8720: HP8720C LabVIEW Driver These driver VI's can be run in LabVIEW. They will allow you to communicate with the instrument and retreive the data you would like. Once you have the data in Labview, you need to then pass it to the spreadsheet. You can use ActiveX to pass data from LabVIEW to another application. I assume your application is Excel? In any case, it sounds like you don't want to use VB at all. Is this correct? Do you want to develop the entire application in LabVIEW alone? I hope this helps.

In your original post you said your local NI rep claimed it wouldn't perform. What changed?

But on the contrary, you still do. Whether the datatype is an indicator or a constant makes no difference. How do you decide on what indicator to use? I agree that variants are more powerfull in this regard. Did you read my last post? I think this implementation is much improved in handling multiple datatypes on the same comm link.