Michael Aivaliotis

I am not Entirely satisfied with this implementation because it has an issue when you right-click close to the border of the VI.

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

I found that yes, the window will popup over all other LabView windows but will not popup over any other applications running. This seems to be exactly what happens with your vi as well. I compiled your vi to an executable and tried it again, in case that changed the behaviour - but it didn't.

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:

National Instruments recommends you use the Open FP method instead of this property. Use the Open FP method to set the state of the window when you display it.

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:

Child Tag: A unique tag for the new item. The default is the string you wire to Left Cell. If an existing tag already uses that string, LabVIEW appends a number to the string to create a unique tag for the new item.

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.

Problem is I want to take these two paired outputs (2 per loop cycle) and output them as a set of paired data I can load into Excel. 

I have tried the build array (inside and outside the loop) and tried the build cluster from these wires etc.. I've changed indexing on/off, basically everything I can think of. 

I just want to take these two output from each loop cycle and make them a 2xn array where n is the number of loops.  Everything I try just gives me the last set of data (last current, last power) and that's it.  I know there has to be a simple way to do this.  Please help me.  I want to do it the simplest way.  I want to add it to the array as I go, one pair of data at a time.  I don't care if it's in an array, a cluster or whatever.  Just want the data out.

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.

In my recursive directory listing I ignore Windows shortcuts.  We had a Coop student accidentally create a a shortcut to the same directory the shortcut was in.  Caused a good infinite loop and few hours to figure out why the software was filling all the memory.  You can steal a prototype from the Tree example (called Directory Hierarchy in Tree Control.vi) in LabVIEW 7.  The shortcut check is called Validate.vi.

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:

Solution: You can resolve this problem in the following ways:

    * Replace the ControlPropertyPages.llb in the labview\resource\PropertyPages directory with the attached file.

    * Add a needle or slider by right-clicking the control and selecting Add Needle or Add Slider from the shortcut menu.

    * Add or delete only one needle or slider at a time and close the Properties dialog box between each change.

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

How long has that "prepare for reentrant execution" option been there? i.e. how long have I needlessly been messing around with VI templates?

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.

Since the variant carries data type information with it it is possible to create a generic unpacking VI.  Also by passing an array of variants rather than just  one, (or a cluster) you can have a generic variable/data list that can be passed to subVIs in the State Machine.  These subVIs can have a strict typedef VIServer interface _or_ free form front / connector panels and still communicate with the State Machine. This lets you implement the subVIs as plugins.

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:

Good afternoon, all. As you know, there have been a number of problems which have impacted the availability of the Igor and Info-LabVIEW mailing lists recently. I've asked the readers of both lists for their support in moving those lists to another server and in taking over the administrative tasks I've been performing.

As I fully expected, given the fine caliber of folks who use Igor and LabVIEW, a number of folks threw their hats in the ring. I'd like to start by publicly thanking Michael Aivaliotis, Scott Hannahs, George Gatling and Arlen Walker for doing so. I'm quite sure that all of them are fully capable of taking on the job and making sure that it will all happen. I have asked Scott Hannahs to take the reins and he has not only agreed to do so, but he has agreed to take both mailing lists over!

The lists will be run via an OSX server, housed in a real machine room, with admins on the job to keep it all running smoothly, backup power and all that other good stuff (a far sight from my shoestring setup, that's for sure!).

Scott and I are working the details of how we will manage the transfer. Right now, our strawman plan goes something like this:

o Shut down subscriptions on my machine here to freeze the subscriber list. o Transfer that list to the machine at Scott's site (National High Magnetic Field Lab at Florida State University) and install it there (both sites use the same software, so that will be relatively straightforward). o Announce the new email addresses and activate the lists at FSU. o Set my machine here to forward list mail to the new addresses (probably active for 30-60 days or so). o Turn off forwarding here and put an autoreply on those addresses pointing users to the new site (again, for some finite period of time). o Shut down my machine (a 6100/60, ie 1st generation PowerPC, in case you were wondering).

We expect the move to happen some time the last week of March or first week of April as it stands right now. More details will follow as they become available.

I'd also like to take this opportunity to thank some other folks who help out here: Brian Renken, who runs the info-labview.org website and Andrew Johnson, who bought us the copy of LetterRip Pro which makes these lists happen in the first place.

As I slowly fade from the scene, I'd also like to thank all of you for making this a really great experience. Way back when I was a heavy Igor and LabVIEW user, the lists made a tremendous impact on my ability to do my work here. Time has marched on and I do different things now, but the value of user communities like these is clear and real. You all can give yourselves a big pat on the back for making that happen!

Take care...

Tom Coradeschi

Excalibur Systems Engineering

tom.coradeschi@us.army.mil

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.

So, will Tom give you the info-labview members email list so that you can do a batch import?  If users have to sign up for the new list manually, I'm afraid that many of the list members will be lost forever.  It seems that to be successful you will really need Tom's blessing and assistance (in getting a member list).

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.

i believe the key for making the "for loop" work is using the "array size" function to determine how many array elements (clusters in this case) are in your array.  Once you do this,  the for loop will know exactly how many iterations to do.

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.