crelf

At my wedding reception, we played Harry Connick Jr's "Forever, for now": QUOTE

QUOTE (ASTDan @ May 27 2009, 07:45 PM) Looks like NI was listening - the preliminary schedule has this presentation on Tuesday the 4th at 4:45pm in room 16B (that's a pretty big room as I recall... anyone else remember? I always get room 14 and 16 mixed up).

Since the response to this thread has been amazingly underwhelming, I wanted to let you all know a little more about what we're planning: this isn't going to be the same old V-Model presentation that you've seem a gah-zillion times before - this will be how good process can impact your daily engineering life in a positive way. Learn how to not only give your customer what they want with minimal effort, and how to make sure what you deliver is what you said you would. This won't be presented at the manager's perspective, but at the engineer's perspective. Why? Because process is often driven from the top of a company down - we want to equip you with the tools and ideas that can make your work easier, more reproducable and ultimately more fun, and then you can drive those processes up in your organisation. That said, our presentation is far from set in stone, so let's hear your ideas on what you want us to present - what company processes currently get in your way? How can they be made better? What works well at your company? What inter-team challenges do you have? What works well with small teams? What works well with large teams? What doesn't work at all? We'll also be giving some demos on some tools that you can use to make your process life easier and more traceable. Let us know if these are good ideas, and/or if you'd like us to cover something else...

QUOTE (jlokanis @ Jun 2 2009, 01:35 PM) ...unless you're working with children of ActiveX nodes or the link - yuck!

QUOTE (Aristos Queue @ Jun 2 2009, 01:07 AM) http://forums.lavag.org/Node-count-versus-SLOC-t3632.html' target="_blank">GOBs.

QUOTE (Yair @ Jun 1 2009, 02:23 PM) True - and that's the important distinction I was trying to make. Most people refer to the combination od scripting and private functionality as "scripting", and I was trying to point out that, while they're delivered in the same package, they're not the same thing.

QUOTE (Phillip Brooks @ Jun 1 2009, 10:55 AM) Hey - I didn't say that I was writing that post while I was on the dunny... ...but I was

QUOTE (peteski @ May 30 2009, 09:36 PM) Real LabVIEW programmers start with templates in their reuse libraries QUOTE (PeterB @ May 31 2009, 01:54 AM) What are folks really intending to do now with scripting that has such value ? You can talk about what you plan to do, but if you never allocate time to implement the idea then scripting isn't really all that valuable to you after all. I think it's because scripting is reall two things: the ability to create code on the fly (ok, not really many use cases for this, but they do exist) and exposure of previously private methods and properties on existing LabVIEW nodes, and it's the latter that I think will be more useful to most people. The create-stuff-programmatically part has be useful to me in the past (in fact, there's a few things I've done with it that I simply wouldn't have been able to do without it, and we certainly wouldn't have been able to complete a project or two), but you're absolutely right: it's not so much in my day-to-day architectures. The exposure of previous private methods and properties, on the other hand, is more common. Not that you need me to say it, but you're completely right: Its OK if you don't get too excited over scripting.

Due to popular demand, I'm extending the deadline for submissions for this year's LAVA NI-Week T-Shirt Design Contest to 5pm US PST on Wednesday the 10th of June, 2009. That's only a week and a half away, so you better get designing!

A big thanks to The Captain from National Instruments for offering up a LAVA/OpenG NI-Week 2009 BBQ door prize: a Guided Tour of National Instruments' Corporate Head Quarters in Austin, Texas We will be drawing 4 tickets to join this exclusive private behind-the-scenes tour of the corporate head quarters with our very own Norm as your guide. View things usually restricted to only NI elite, including Jeff Kodosky's desk, the site where was created, and the An Engineering Mind studios where Todd films his weekly rant about how engineers are awesome (and everyone else wishes they were engineers).From NI's website:

I know it's an old thread, but in case you didn't know, LAVA renders quite nicely on mobile devices (I'm writing this post using Opera on a Samsung Saga), so now you can LAVA from anywhere - including the dunny...

QUOTE (ShaunR @ May 25 2009, 05:13 AM) Care to share?

QUOTE (DDriver003 @ May 29 2009, 09:11 AM) No worries. I'm not saying that the original coding methodology is suspicious - it could be wonderful - but I don't know. Good luck, and let us know how it goes...

QUOTE (ASTDan @ May 28 2009, 04:28 PM) You know, I don't remember saying that... but it sounds like something I'd say

QUOTE (dblk22vball @ May 28 2009, 04:01 PM) You could use a Functional Global - then you could do functional stuff too like formatting (if you needed to).

QUOTE (Cat @ May 28 2009, 11:18 AM) Gotcha. I think it depends - if your code is sequential, then horizontal makes the most sense, but if it's parallel, then vertical might be better. QUOTE (Cat @ May 28 2009, 11:18 AM) I've read your tech articles on UI design and they've been very helpful. But they are for the FP, the actual user interface, yes? Tho, one might argue that while we're coding, the block diagrams *are* the user interface. I'm glad someone has read it Seriously though, I'm glad you've found them helpful. I've been meaning to move it all over to the LabVIEWwiki, but haven't been able to find the time You're right - the block diagram can certainly be thought of as a UI, and a lot (but not all) of the concepts that we try to apply to the FP to increase intuativity can certainly be appliued to the BD as well. One of my pet hates is a great FP backed by a horrible BD: often we consider our users to only be those who interact with the FPs, but forget the other class of user: those who will need to maintain and grow our software in the future. Clean code isn't just a style thing, it's functional too.

QUOTE (David M. @ May 28 2009, 01:54 AM) You can get the http://sine.ni.com/nips/cds/view/p/lang/en/nid/1394' target="_blank">NI LabVIEW PID Control Toolkit here.

QUOTE (Minh Pham @ May 27 2009, 10:50 PM) Oh yeah - I totally agree. QUOTE (Cat @ May 28 2009, 07:22 AM) Most of us do read from left to right, after all. Actually, most of us read left to right and top to bottom - I don't think that we can have one without the other, as reading is really a 2 dimensional process (unless, of course, you're only reading one line of text). What you're talking about is "vision path" and is a really important element of intuative user interface design - you can read more about it here.

QUOTE (ASTDan @ May 27 2009, 07:45 PM) Have you gained a little weight since I last saw you Dan? QUOTE (jdunham @ May 27 2009, 09:22 PM) All that stuff would be so much easier if it were supported internally by LabVIEW. It would be great for NI to show some leadership on this and modernize the error handling system. This would really boost my productivity. Hopefully at the very least they will attend the NI Week session Don't worry - NI is definately coming to the party - we're talking to a number of NI folks about how to do error handling better. QUOTE (danielsan @ May 28 2009, 03:07 AM) I will but it´s in an early stage so I´d like to test a little bit more... Great! If you don't want to upload it to the public forum, you're welcome to http://forums.lavag.org/compose-new-message.html&MID=181' target="_blank">PM it to me.

QUOTE (DDriver003 @ May 28 2009, 10:06 AM) Hi - and welcome to LAVA! It's a great community, and I'm sure you'll get a lot out of it (and hopefully we'll get a lot out of your contributions too ) Unfortunately, it totally depends on how the original app was written - there's many ways to write a LabVIEW app, and the original architect could have chosen any one of them. If you upload your code, we could take a look at it and advise you further.

QUOTE (PaulG. @ May 27 2009, 04:01 PM) I'm okay with scrolling, as long as there's a reason for it, and it's in only one direction. I don't think diagram size is a strong enough reason on it's own for modularization.

QUOTE (atilio @ May 27 2009, 02:56 PM) Can you clarify what you mean by "considering the amount of scrolling needed"? QUOTE (Yair @ Nov 20 2008, 03:28 PM) * Statistically speaking. Does not apply to LV R&D engineers and LAVA admins with the ability to do bad things to my account. Valid only in the U.S. and Canada. I can't speak for any of the other mods or admins, but I'm pretty sure your account is safe. ...for now.

QUOTE (danielsan @ May 27 2009, 11:27 AM) I sure did Do you have any example code you can upload? QUOTE (jdunham @ May 27 2009, 11:45 AM) The XML contains the panel name (often different than the VI name)... Including the panel name is a great idea!

QUOTE (Black Pearl @ May 26 2009, 03:17 PM) QUOTE (Aristos Queue @ May 26 2009, 05:47 PM) And something very much like that is what I prototyped and posted to LAVA last year. One of the questions that has existed since man first used a LabVIEW error cluster is how can I make it scalable so I can have more than one error simultaneously. The next question was where do I put all this data? I've seen many different implementations, some concatenated their error structure to the "source" text field in the standard error cluster, some implemented a completely new system outside of the traditional error cluster (with appropriate converters to and from each system). The question is: which one is best? The former breaks less and required less retro-fitting of existing code, and can benefit from some of the existing error handling VIs that ship with LabVIEW, but it sometimes breaks when VIs misbehave and wipe the error cluster clean (yes, some primatives have been know to do it under certain circumstances). The latter is tempting because we can start from scratch and design whatever we want, but it requires integration into existing components that, by default, use the existing format is challenging. Thoughts?

QUOTE (Anders Björk @ May 25 2009, 11:51 AM) Great ideas Anders - That's very close to what we'll be presenting at NI-Week.