orko

QUOTE(yen @ Sep 6 2007, 10:11 AM) I've been using that as a reference as well, but unfortunately the ConPane images have disappeared! Jim: Do you still have the images, and can we get a good copy into the wiki?

Hey Sparky, Check this out: <labview>\examples\general\strings.llb\Extract Numbers.vi The code in the while loop is probably all you need (Note that they don't match for a "+" sign at the front of the number).

Okay, here's one way you may be able to get the answers you're looking for: 0) Take care of that bug in the "Message" event case :-) 1) Right click on the Queue RefNum input terminal inside the bottom while loop right before the Dequeue Element and put a probe there. 2) Run the VI and watch the probe. Notice how each time you click on Connect/Disconnect, there is another "read" that goes into the queue (effectively adding 5 seconds in this case before the next read is queued) 3) Click the Connect/Disconnect button a few times, then click on Stop. Notice where the "exit" is in the queue stack? I assume that it needs to be in the front of any other queue elements. 4) Right click the Enqueue Element in the Connect/Disconnect event case in the top loop and replace it with a "Enqueue element at opposite end.vi" in the queue operations pallete. This one puts the element at the front of the queue, and I use it for stop or error conditions that I need handled right away (on the very next iteration of the queued state machine). To handle the reads stacking up the way they are with each Connect/Disconnect button press, you can do several things. One suggestion is to preview the queue elements (with "Preview Queue Element.vi") and if there is already a "read" in there not adding another. You can also create a subVI that previews the next queue element and if it is NOT a Stop or a read, then it queues up the next read. I think this may be a little more elegant solution. Hope this helps out.

Since you are dealing with a sigmoid, if you are looking for the time of a certain data value (best fit) within a tolerance you can also use the "Search Waveform.vi" in the waveform palletes. http://forums.lavag.org/index.php?act=attach&type=post&id=6854

QUOTE(Donald @ Sep 5 2007, 04:07 AM) Now THAT is a setting to remember! Thanks for the tip! :thumbup:

QUOTE(CamilloN @ Sep 5 2007, 02:09 AM) I'm assuming that you already have a way of capturing the signal from whatever hardware you are using. A sample VI of what you have so far would help here to better understand what you are working with. Check out the "Waveform Min Max.vi" located in the waveforms pallete. It gives you the MaxTime and MinTime of an analog signal, which you can use to calculate the elapsed time since the start of the waveform. This may be what you are looking for. http://forums.lavag.org/index.php?act=attach&type=post&id=6853''>http://forums.lavag.org/index.php?act=attach&type=post&id=6853'>http://forums.lavag.org/index.php?act=attach&type=post&id=6853

QUOTE(Michael_Aivaliotis @ Sep 3 2007, 10:00 PM) Hmm... I understand that this looks like the SubClust1 class has been typedef'ed. Okay. What I still don't understand is why the original typdef cluster (SubClust1.ctl) is linked as a dependancy after the classes are set up. You can see this by deleting the SubClust1.ctl and MasterClust.ctl from the project and refreshing the dependancies. Why is the project now dependant on the SubClust1.ctl? What is still using it? EDIT: OHHH.... I understand. The SubClust1.ctl has *BECOME* the typedefed SubClust1 class! Oh my head... that IS confusing. But it makes sense what is going on now (although I'm still not sure if it is "correct" or sane behavior to typedef the class in this way)! http://forums.lavag.org/index.php?act=attach&type=post&id=6844''>http://forums.lavag.org/index.php?act=attach&type=post&id=6844'>http://forums.lavag.org/index.php?act=attach&type=post&id=6844

QUOTE(yen @ Sep 3 2007, 11:57 AM) I personally wouldn't mind having it somewhere near the "Select a VI..." icon in the pallettes as opposed to making it a daemon. My mind would be in that zone anyway when I went to search for a VI ("I need a VI... click, okay, Find a VI..."). Just how my mind works. YMMV

QUOTE(yen @ Sep 3 2007, 11:53 AM) Yes, that was my understanding as well. This is what was confusing me, because after converting the clusters over to classes as described above, this is what I get: http://forums.lavag.org/index.php?act=attach&type=post&id=6842''>http://forums.lavag.org/index.php?act=attach&type=post&id=6842'>http://forums.lavag.org/index.php?act=attach&type=post&id=6842 This to me says that even though the class data is private, it is still depending on the type definition from the old strict typedef after I converted them over. In fact if you remove the old typedefs from the project they show up as dependancies until you release them from the class control (disconnect them from their typedef). I guess I understand what is going on, and why...but I do not understand why this be desirable behavior... Why would I need to go through my entire class heirarchy after converting to classes and one-by-one disconnect them from their original typedef? I guess my specific question, now that I understand what is going on, is this: Why doesn't the "convert contents to class" project function release the new private class data from the original strict typedef control dependancy? Is there a reason this isn't done that I'm not thinking about?

:thumbup: Simple is good. QUOTE(jdunham @ Sep 3 2007, 01:37 AM) If you put the timeout constant inside the sequence and the wait primative on the output you won't have the "stale" newval issue. http://forums.lavag.org/index.php?act=attach&type=post&id=6836''>http://forums.lavag.org/index.php?act=attach&type=post&id=6836'>http://forums.lavag.org/index.php?act=attach&type=post&id=6836

QUOTE(Val Brown @ Sep 2 2007, 01:48 PM) Oh I still use VI (in it's Gvim version) to this day... nothing beats the power of the ":" :worship:

QUOTE(Michael_Aivaliotis @ Sep 2 2007, 01:29 PM) Yes, I'm trying this in LV8.5. As expected... what do you mean by that? I'm not sure yet if I'm not just fighting against the "expected" behavior, so it would be helpful if you could explain what you did/how the conversion went as opposed to my experience? Thanks Michael.

Well, I had some time finally to take some existing project data structures and see if I could convert them over to classes using the native LVOOP. At first, this seemed easy to do, with simple clusters. Then I tried a hierarchal cluster that included several other typdef clusters. Hmm. There must be a better way... Taking an existing cluster that had typedef clusters inside and right clicking on it to convert it to a class, I would have thought that there would have been some easy way to convert the "subclusters" into classes as well. It turns out that even if after I converted the top cluster into a class, and clicking on each cluster contained in it and converting them to classes as well in the project, that the original typedef clusters were referenced in the main class instead of using the new classes I converted. Is there a trick I'm missing to do this sanely? I ended up having to weed through the dependancies, and find all of the old typedefs that were still being referenced...then finding them in the main top level class...then replacing them one by one with the new classes created from them. To provide a simple illustration, typedef cluster A.ctl has two typedef clusters of type x.ctl inside of it. Converting A.ctl to A.lvclass leaves the two x.ctl's inside of it. I can see why this would be the expected behavior. But then converting x.ctl to a class in the project, the typedefs in A.lvclass are still not replaced. Replacing the first x.ctl with x.lvclass still isn't enough, so I have to replace the second one as well. You can see that if there are 10 clusters of differing data types inside of a main data cluster that I'm converting that this gets messy...without even thinking of clusters that are inside those second level clusters... Is there an easy way to convert all of the clusters inside of a cluster into classes without all of this manual labor? Am I missing something basic (I wouldn't doubt it since I'm a LVOOP newbie)?

It would seem that you could avoid a lot of initial drawbacks to this idea if you made it a VI you place on the pallete window vs. a shortcut key activated thingy. Sure, a key to bring this (and many other VI's I could think of) would be nice, but I have a feeling that in future releases of LabVIEW they will allow custom VI's to be associated with shortcut keys (NI correct me if I'm wrong...but why else would there be that hint of a "bug" in the File menu shortcuts...?). I would suggest that getting the autocomplete while typing feature and the "refreshing" of the VI lists would make this tool very beneficial by itself. Then perhaps we can get some kind of workaround so all of our nifty tools can be popped up with a keystroke. Just my 2 cents Great idea by the way!!!

QUOTE(dsaunders @ Aug 31 2007, 02:45 PM) Ah. Okay. That's easy to fix. Thanks! QUOTE(dsaunders @ Aug 31 2007, 02:45 PM) On the topic of the name, would this also break if there was more than one instance of the subVI on the block diagram? Wouldn't it always stop on the first instance found, rather than search until it found the correct instance? Good.............point :headbang:

QUOTE(Val Brown @ Aug 31 2007, 01:55 PM) Eeeeeeewwww! http://forums.lavag.org/index.php?act=attach&type=post&id=6823''>http://forums.lavag.org/index.php?act=attach&type=post&id=6823'>http://forums.lavag.org/index.php?act=attach&type=post&id=6823

I would be interested in this as well...

QUOTE(BobHamburger @ Aug 31 2007, 12:50 PM) I agree with this and it was my original thought when reading the post. Mine was only an alternate suggestion that worked without polling, as alukindo seemed to be after. It probably isn't the best suggestion now that I'm looking at it (since someone already found a bug in it ). Ah well, just another way to skin the feline.

Another way of doing this is to put a case structure outside of your event structure that handles the waiting for the mouse up if the slider has been clicked on. Of course, it depends if you have other events you want to trap while you are sliding (this won't work in that case). http://forums.lavag.org/index.php?act=attach&type=post&id=6820 http://forums.lavag.org/index.php?act=attach&type=post&id=6821 (LV8.2.1)

QUOTE(Jim Kring @ Aug 30 2007, 08:16 PM) Hey! I want a touchpad that I can dance on!!! That is such an awesome video... Thanks! I needed that!

QUOTE(yen @ Aug 31 2007, 05:39 AM) Not sure what you mean here. Wouldn't getting all of the subVI's from the caller's caller's BD SubVIs[] property be sufficient to find the subVI? I thought we were just trying to see if this instance of the VI that has the ConPane_Wired.vi in it has a particular terminal wired? A.vi has B.vi in it. B.vi calls C.vi to find out if terminal t is wired. C.vi would search A.vi's block diagram for B.vi to get to it's terms[] property to find terminal t. Is there a better way? QUOTE(yen @ Aug 31 2007, 05:39 AM) and that it relies on the name, which could be duplicate (although in most cases people would probably not use duplicate names). Yes. This was one of those things that bugged me, but I wasn't able to figure out another way to do it. Any ideas?

This issue has been resolved...see EDIT below. Silly orko. In one of my projects (LV8.2.1) I reorganized/renamed a handful of type definitions to be better organized in the project tree. After each change, I applied the changes in the control editor and hit ctl-shft-S to make sure the changes were propagated. After the changes had been made, LabVIEW wouldn't mass compile my project anymore! Crash after a certain VI was hit every time! I found the VI that it was choking on and moved it out of the project directory. Mass compile now works (phew!) but there is now an annoying error message in the mass compile log that won't go away (even after removing every trace of the "corrupted" VI from my dev box): CompileFile: skipping <old path to corrupted VI> The VI is definitely not there and my project is saved and working fine...so how is my mass compiler getting confused? Closing down LabVIEW doesn't appear to make it go away either. Searching on the NI and LAVA forums doesn't reveal this mystery... Has anyone ever seen this error? And if so, how'd you make it go away? .... and what in the world is this "CompileFile"? EDIT: Never mind... it turns out that this was a simple case of leaving the file inside the project while deleting it from the project directory on disk. The "CompileFile" as far as I can tell was the .lvproj file which still had the old file listed in it.

QUOTE(Aristos Queue @ Aug 28 2007, 04:52 PM) I thought about this a little while this morning (needed a break from my other project). I ended up coming up with a way that I think works, and it tested well on LV7.1.1, LV8.2.1, and LV8.5. Let me know if anyone has a better way, or a suggestion for improving this VI: http://forums.lavag.org/index.php?act=attach&type=post&id=6814''>http://forums.lavag.org/index.php?act=attach&type=post&id=6814'>http://forums.lavag.org/index.php?act=attach&type=post&id=6814 (LV7.1.1) The reason there are three VI's here in this ZIP file is so I could test the real world behavior when the ConPane_Wired.vi is used on the BD of a VI that is being called from another VI (where one of the terminals is either "wired" or "not wired"). Run the "ConPane_Wired_TESTVI.vi" to see it in action.

QUOTE(Gavin Burnell @ Aug 29 2007, 12:38 PM) You're not the only one, Gavin. I'm trying to keep up...but there's a lot to digest! http://forums.lavag.org/index.php?act=attach&type=post&id=6803''>http://forums.lavag.org/index.php?act=attach&type=post&id=6803'>http://forums.lavag.org/index.php?act=attach&type=post&id=6803

QUOTE(NormKirchner @ Aug 29 2007, 08:38 AM) It's worth noting that this tool will only work as desired if the "Use native file dialogs" option is checked in the Environment options. Otherwise the file dialog dropdown gets all "mangulated". Thanks, Norm! :thumbup: http://forums.lavag.org/index.php?act=attach&type=post&id=6800''>http://forums.lavag.org/index.php?act=attach&type=post&id=6800'>http://forums.lavag.org/index.php?act=attach&type=post&id=6800