Justin Goeres

QUOTE (Giseli Ramos @ Apr 8 2008, 11:15 AM) May I suggest a http://tortoisesvn.tigris.org/' rel='nofollow' target="_blank">version control system?

At the risk of seeming unhelpful, what is the difference between this thread and your previous thread from a couple weeks ago?

QUOTE (scls19fr @ Apr 7 2008, 10:34 PM) Aha! So it is for schoolwork! QUOTE (scls19fr @ Apr 8 2008, 02:07 AM) Wow ! Not sure of being able to do this ! Maybe you have a link that could explain these patterns (using some use cases) I haven't downloaded your code to look at it, but there's some information about state machines in the LabVIEW help, and there are some built-in templates that you can find under File >> New... in VI >> From Template >> Frameworks >> Design Patterns.

QUOTE (scls19fr @ Apr 7 2008, 12:28 PM) What Mike said is right, but I'll give you a couple nuggets: You can't "break" a sequence. All the frames must execute, from beginning to end. You shouldn't be solving your problem with a sequence. The concept you are looking for is state machine.

QUOTE (scls19fr @ Apr 7 2008, 07:24 AM) Just bear in mind that the method discussed in the NI article is fine for relatively simple programs, but may not scale well for larger applications. In that case, you'll need to do something with queues, notifiers, events, etc. (like the examples posted above).

Everything orko said is right; I would also add that you might find some info in the SMTP RFC document. Also, in your case you might find it easier to use a command-line sendmail. I don't know much off-hand about how to format an attachment into an email, but you might be able to glean some of what you need from here, or by just emailing yourself a simple attachment and looking at the raw source of the email.

QUOTE (eaolson @ Apr 4 2008, 01:18 PM) I can't identify the quote, but it feels like something from Futurama. Same show, different quote: "Hey! I don't tell you how to tell me what to do, so don't tell me how to do what you tell me to do!" And to keep this relatively on-topic, I haven't upgraded yet. I'm going to let some other schmuckspoor, tortured souls try it out first .

QUOTE (Aristos Queue @ Apr 4 2008, 11:34 AM) Oh, I'm much more cosmopolitan than that! :ninja: I always replace the default icons completely with my own, so the built-in banners don't apply to me. That frequently translates to banners (& wires) that are some sort of dark foreground color and one of the muted background colors from the color picker (although I frequently invert foreground & background on the wire design because I like the look better for whatever reason). QUOTE Someone suggested that the wire color should be set the same as the banner color by default. What would you think of that? For myself, it would bug me, if only because yellow makes a great banner color but a lousy wire color. I don't have any immediate aversion to that, but like I said, I (almost) never end up using the default banner color anyway. It doesn't matter to me what color the wire starts out if I'm going to have to change it later regardless. That having been said, it might be beneficial to cycle the default class wire color (cycling it with the banner would be a fine choice once you solve the yellow problem), if only because sometimes I don't fix the wire color/pattern right away and I end up with several class wires on my diagram that all look identical until I get around to changing them.

This is one of those things I might regret admitting later, but I usually pick wire colors that match the foreground & background colors of the banner at the top of all the class icons for a given class. That has the advantage of producing wires that look like the class VIs they connect to, but risks occasionally running afoul of AQ's color guidelines above. As for wire patterns, I pick whatever suits my fancy at any given moment. But I do gravitate toward certain things in certain situations. If I'm working on, say, an LVOOP instrument driver, I tend to either pick a wire that looks sort of like >>> or a set of dots. My brain seems to think that means this class transmits data on a real-life wire.

Will there be a chapter on Regular Expressions?

QUOTE (Daklu @ Apr 2 2008, 01:16 PM) I never put my vi.lib directory under source control. My rationale for that is that LabVIEW manages vi.lib itself (toolkits, updates, etc.) and nothing good can come of any contribution I make to it. In the past I had parts of my user.lib under source control, but it was a pain to deal with and I felt really uncomfortable having SVN-managed files hanging out in a subdirectory of Program Files. So I stopped. I do have elements of my user.lib in SVN, but I export them into user.lib instead of checking them out. QUOTE When you check in code do you create a zip build and check that in? (As near as I can tell you need to do that to collect the vis not in your project directory, unless you want to find them and add them all manually.) The answer to this question sort of depends on how your source is organized on disk. In my case, I keep all the non-vi.lib and non-user.lib VIs for each project arranged below a single parent directory. Then I check in that entire directory (and all subdirectories) and treat it as the repository branch for a given project. I don't recommend checking in a zipped set of files, because if you do that you lose the ability to version each file individually. It short circuits one of the main features of source control. QUOTE Does your strategy change when you are checking in code for a project currently under dev versus closing a project? No. I use the standard SVN trunk/branches/tags arrangement. So all my checkins go into trunk (or into a branch if I'm working on a branch). Then when I do a release or close a project, I copy the current trunk (or branch) to a new subdirectory under tags. Because of the magic of SVN, that gives you a trivial way to create a named snapshot (tag) of your tree, and uses virtually zero extra disk space. QUOTE Many of these projects are being archived and if they are ever checked out again it's likely it will be by a different user on a different computer with different addons installed, etc. Because of the nature of LabVIEW's vi.lib & user.lib directories, I don't know of a catch-all solution to that. One thing I do to mitigate the problem is I build a Package Configuration file for each project and store it in the trunk of the project it belongs to. That way when anybody checks out that trunk, they can apply the package configuration to set the libraries up correctly (obviously this only works for libraries that are managed by VIPM to begin with).

QUOTE (micman2 @ Apr 2 2008, 07:19 AM) The name of the professor is mentioned in the article you linked. I would suggest contacting him if you are interested in the project.

I'm only wishing Michael a happy birthday to boost my post count .

QUOTE (neB @ Mar 31 2008, 06:29 AM) I actively avoid getting political on LAVA (which is why I'm only tackling the first thing you said ), but I would like to point out that the "Al Gore claimed he invented the Internet" thing is http://www.snopes.com/quotes/internet.asp' rel='nofollow' target="_blank">demonstrably false.

QUOTE (orko @ Mar 30 2008, 08:58 AM) And if you got four huge ones, that would be like saving EIGHT planets. :thumbup:

If you're really that green to LabVIEW, but have the kind of experience you're talking about with other languages, I'd recommend arranging to take the LabVIEW Basics course offered by NI (or through a local NI Alliance member company). It's a little pricey, but you will more than make up for that cost in the time and tears you'll save on the project. You might also do well to consult a local LabVIEW expert (CLD or CLA) early in the project to help you lay out a plan for the software. When introducing new people to LabVIEW, I've found that it's much harder for them to really grok the language unless they have a "real" project to cut their teeth on. You obviously won't have that problem, so from that perspective I think what you're talking about is a great project. However, the surest way to ruin someone's (or your own) enthusiasm for a new toolset is to throw them in the deep end and leave them to drown, so regardless of how you approach it you will need a safety net of some kind. Either knowledgeable people to go to for help, or a nice large cushion of time to let you make some mistakes and fix some poor choices along the way. For the record, my first project (years ago) was more complicated than what you're talking about, and I had none of the resources I mentioned above. It was a nightmare, and at the end of the day the code was horrid. (For those of you who know me, I'm not talking about that project. This is a different one. An even worse one .)

That video is made of Pure 100% Awesome. As for me, when my bottom feels strange, I check my LAVA RSS.

QUOTE (Yuri33 @ Mar 25 2008, 08:09 AM) But don't you get a trailing zero then in instances where the decimation doesn't come out even? That was what led me to the For-Loop implementation I posted. There may be a better way to get there (i.e. without a For Loop), but that was the motivation for adding the For Loop. I had actually implemented something very close to your method originally. Sorry, posting this on my way out the door or I'd check myself .

QUOTE (bayram_mercan @ Mar 25 2008, 04:31 AM) Just leave whatever index you want to disable unwired. For instance, if you want the third column of a 2D Array, leave the first index terminal unwired and wire a 2 to the second index terminal. http://lavag.org/old_files/monthly_03_2008/post-2992-1206452117.png' target="_blank">

QUOTE (SciWare @ Mar 22 2008, 10:24 PM) You mean like the Windows Task Manager?

Call me an optimist, but I won't start worrying until the headline says Australian man killed by murder robot.

QUOTE (Norm Kirchner @ Mar 20 2008, 08:13 PM) Multiple Cores.

QUOTE (Yuri33 @ Mar 20 2008, 09:59 AM) I don't think that works. Or am I missing something? I reproduced the code in your screenshot (or at least I think I did), and when I run it with Array = {0,1,2,3,4,5,6,7,8,9} Decimating Factor = 3 The result I get is Decimated Array = {0,3,6} (It should be {0,3,6,9}). Likewise, when I run it with Array = {0,1,2,3,4,5,6,7,8,9} Decimating Factor = 4 The result I get is Decimated Array = {0,4} (It should be {0,4,8}). It's easy to find plenty of other examples where the last element in Decimated Array is missing. EDIT: A little bit more testing leads me to believe that the Yuri33's code works as long as Decimating Factor divides evenly into the size of Array. If it doesn't (i.e. if R>0 coming out of the Quotient & Remainder), the last element of Decimated Array is chopped off.

QUOTE (No.1 @ Mar 20 2008, 04:49 PM) I don't know of a way to do what you're talking about natively through LabVIEW, but you might be able to find some Windows API calls to help you. EDIT: On second thought, is this more what you're looking for? http://lavag.org/old_files/monthly_03_2008/post-2992-1206071081.png' target="_blank"> (that's an Invoke Node on the left, instead of a Property Node. I'm not sure that method exists in LV7.1, though...)