Norm Kirchner

QUOTE(LV Punk @ Oct 30 2007, 10:43 AM) Well I was going to follow that idea but unfortunately the , is an illegal character (a 'sick bird' if you will). So for now I will just simply have to append my surname or convert all the way to The Captain.. Maybe I should start a poll. But then the gods may decide to turn my legs to roots and arms to branches next to a river so that I may gaze upon myself for all time.

Ok, if you haven't seen, there is another Norm on the forums. Search for recent posts on GPS. Now I'm all good with sharing, but he must acquire a nickname so that once we get going on some of the same posts, I won't lose my mind. I already got confused when I didn't realize that another Norm existed and heard Justin Goeres talking about what I had said.... well not me... but the other me. Well perhaps I've already lost my mind and it's not worth the effort.

Well from the array and name of the items, you should be able to find the context called NI.LV.Dialog Then look for a all exported VIs in memory for that specific context then once you find the name of the VI or if you already know the name of the VI, simply pump it into an 'open VI reference ' along with the correct application reference. If that's still not enough, just re-post and I'll put a snibbit of code

Very far from the LV model, but I would have to say the best example of an "easy to program" language. Even better than LV. Of course w/ lack of thought into the programming of something, so goes the ability to troubleshoot, extend, and re-use. But for those just getting into programming, it's a way to keep them interested

QUOTE(crelf @ Oct 27 2007, 03:21 PM) Actually another beer bottle would have done it, that's why it's always good to have more than just a few beer bottles on hand at once. well I couldnt find a video of it, (although I know it's possible), but while you think about it http://www.youtube.com/results?search_quer...beer+with+a+%22

Please see the following post, I just made it in response to this topic. It belongs in the rusty nails section due to the sensitive nature of the things that it can show.

WRITTEN IN RESPONSE TO THE FOLLOWING POST. http://forums.lavag.org/How-to-access-use-...ance-t9400.html The reply belonged here Boy oh boy!! you hit on one of my favorite hacks! This should get you what you need. and more! This opens the treasure trove of all the guts of LV running LV. BEWARE Hence the move to the rusty nails forum

QUOTE(alnaimi @ Oct 29 2007, 09:10 AM) Somewhere like this? http://lavag.org/old_files/monthly_10_2007/post-208-1193670057.jpg' target="_blank">

ABSOLUTELY!!! I have done this a variety of ways, using the activeX 3d control avaialble within the graph pallette, w/ a slight modification. this something like what you want? The trick is that you don't use the VI's provided, rather just the reference that they drop and use the method "Plot3DMesh" using that method is critical if you data does not arranged perfectly (happens w/out you even realizing) This method does a connect the dots for you and makes the 3d surface and it is up to you to set the levels for the values, but this is very easy through right click the activeX control on the FP and go to properties. From there you set a lot of stuff. So go play w/ what I've given you so far and come back w/ about the 20 questions I'm sure you'll have

QUOTE(ptit bras @ Oct 23 2007, 01:50 AM) It is quite true, the XControl only runs when a pre-defined set of events are fired. In order to accomplish what you are looking to do, you must have a background routien running that is registered for this event and when it happens, it passes the information to a method of the XControl, preferrablly of the data type of the event. So it's a bit round about, but you'll start a background process, that has an input of the user event reference, within the process, register for that event and within the event case for that event, fire a user created method that takes the data from the event and passes it to the XControl, possibly w/ a command that the data is associated with. Sounds like a prime candidate for Objects.... wait.... I've already created this.... hmmm. called LVx A demo and the code is complete but the demo is not descriptive enough and bundling it up for distribution sucks ###### from the project.

Justin, who killed your cat and made you so pissy? "kitty cat... i'm a kitty cat.. kitty cat" Do you just need your keg of heineken. Stamatios, Can you show what the NI software is detecting? You may want to try going black and wite first, and increasing contrast/specific levels based on eye color. Really what you may want to try, is taking a variety of images into photoshop or GIMP and playing w/ the filters there to make the lakes show up. Also in the image that you posted, there are a few other lakes I see, why are you not interested in those?

Hello and welcome! First before we dig into the details of your questions we need to get some terminology straight (don't feel bad, it's confusing for us to keep straight too) GOOP and LVOOP although similar in ideaology are different in implementation. GOOP is an older, but still quite alive, way of implementing classes by reference LVOOP is 'brand new' and still evolving (read growing pains) way of implementing classes by value (or by wire if that helps make it more clear) So the first path that you need to define is, by path or by value. Now coming from a Textual and reference based OO background you may lean towards GOOP (by-reference) But I would recommend that you force feed LVOOP (by value/by wire) to yourself, but this will also depend on how good you are w/ LV too, but this route needs no toolkits to get started as they are allready native in LV 8.2.1 (go to 8.5 if possible due to advancements in LVOOP interaction) So in closing, you do not need a toolkit for either method of OO within LabVIEW. You should understand how to create both methods from scratch (although the GOOP toolkit is handy). If you are new to LV the learning curve for both methods is going to be steep and treacherous, but keep posting to the forum and we'll help you find the holds on the wall. Good luck

QUOTE(bbean @ Oct 26 2007, 09:05 AM) Something we do where I work is another similar but different alternative to what has been mentioned. Create a separate file/files that get digested by another program (read LV exe) as the data points are taken. That will allow you to prioritize the DAQ or the Logging also it provides robustness if the DAQ program crashes before all the data is logged. 0.02~,~

Quick side note, and gratuitous plug.... Don't forget to checkout the Tree Control API in the code repository. Although may not be faster while running, it will be much faster to program.

It's the part of the blog video where you see [censored] over my mouth. I was just making a funny w/ regards to passwords :gathering:

QUOTE(Michael_Aivaliotis @ Oct 20 2007, 06:39 PM) It's true. We should just get rid of the event structure and come up w/ our own management scheme that runs in the background and uses occurences to fire off our own 'events' Of course we'll do it ourselves, but wow isn't it nice to have it integrated too. And it's good if we make something ourselves and NI eventually picks up the ball, that way they already know what we want. Look @ the Tree Control toolkit, I'm sure it will make it's way to the dev environment soon enough

QUOTE(angel33 @ Oct 17 2007, 01:42 PM) Well don't I just feel used then.

I am definetly on board with pushing NI to allow us to easily plug in our own additions to the Dev environment. I can't count the number of times I've created floater utilities w/ 1 button to accomplish something. One that may make it to the CR is a tool to auto align the label of input controls to be justified to the right edge of the control. I know that you can now have LV auto do it but that is to the same location for both controls and indicators and for me, on the BD, controls label right just. indicator label left just. But to be able to easily add this in would be great, cuz finding out what the active VI is, is still a little bit of a hack. Actulally the new LLB Viewer is written in pure G and has the possiblity of creating your own plugins. Just watch the NI week 07 videos and I'll give you the passwords to get into it. I would have to say that the code is 'Super Spiffy'

I would strongly suggest you work through the getting started with LV before going much further. Creating and configuring a subVI is a critical part of any application and I'm sure that you will have follow up questions that may be answered just by taking an hour or two going through the beginner steps

QUOTE(Aristos Queue @ Oct 16 2007, 12:31 PM) So if we get this, we can come work @ NI at, at least a 5 year R&D salary BTW there is a dot on the output of the bundler on the inplace 'version', which you are not pointing out

QUOTE(Tomi Maila @ Oct 15 2007, 04:33 AM) I'm with Tomi on this one. Showing the dots gives no added clarity to the situation at all. Also I'm a little mixed up on why the nodes exist on the input terminals. I get it, since if we run it stand alone, it must acquire memory for them, but how do we reconcile this with the fact that it may be a subVI and the memory is already acquired? Or should we just always ignore on terminals?

Ahhh, the beauty of symetry ~,~

QUOTE(crelf @ Aug 3 2006, 09:47 AM) Has anyone seen mr jennings at this NI week. He still owes me a fight.

QUOTE(crelf @ Aug 5 2007, 07:09 AM) I thought we left it on the bus last year. Did anyone come pick it up?

QUOTE(crelf @ Jun 29 2007, 01:52 PM) LESS BEER!!! Don't toy w/ me.... I just can't handle it