crelf

So the LabVEIW development environment is based on MDI, without the benefits of it being an MDI?

...and the famous LAVA T-Shirts are available. The only difference to last year's design is that we've removed any reference to a particular year of NI-Week, so you don't have to buy one every year

So check it out in the LAVAStore (and why not grab yourself some other fine LAVA related products? )

I got my ticket!

PS: If that Brian Powell guy says I'm paying for his ticket, he's a dirty rotten filthy stinkin' liar!

Is there a course somewhere that teaches how to test an OO large scale project that uses Hardware Abstraction Layer, design patterns, UI framework and so on?

What do you mean by "how to test"?

Well, this test is intended for entry level programmers, so I guess it should not change.

I agree. If those questions/answers were in the CLD or CLA, then I'd ask for them to be changed, but this test is for a completely different scope.

Afford me a story: When I was in my first chem class in college (I was a science-physics major), the lecturer asked us to draw a model of a sodium atom. After some time trying to remember how many electrons it has, and the packed orbital limits, most of us came up with the old nucleus surrounded by co-axial rings. He showed a slide that looked just like that ("whew!"), and then said, although it's certainaly a model that was enough to get us through high school, it was time to abandon it for something closer to the truth, as the old model wasn't accurate enough for what we needed to learn now.

So, should the high school ciriculum be changed to teach everyone the latest, greatest and most complex model of the atom? No - because, for the intents and purposes of high shcool, the model that we were taught is just fine. Same goes for tests like this - if you only ask questions that the most savvy architect knows the real answer to, then you're defeating the purpose of the quiz.

That said, if there's something blantantly wrong in one of those quizes, or you disagree with the scope, then feel free to ping NI training about it. We've had success in having quizes updated in the past.

I'll kudos your idea if you kudos mine: http://forums.ni.com/t5/NI-TestStand-Idea-Exchange/Add-quot-Project-Globals-quot-and-or-quot-Workspace-Globals-quot/idi-p/1148493

If you ever do work out the pattern, it'd be nice if it was added to the LabVIEWwiki.org.

In my admittedly biased opinion, Zune was better than iPods and iTunes in almost every way.

Can't argue with that. IMO Zune's biggest downfall was that it wasn't marketed by Apple.

Yeah, MS has a habit of jumping into a market for a couple years then abruptly jumping out. (Home networking products and Zune come to mind.)

Although I worked on the team that designed and built the EOL testers for the Zune family, I have no internal knowledge on this - this is purely my own speculation: I like to think that MS "did" the Zune for a number of reasons, not only to try to make $ in that product domain. My gut feel is that a lot of what they learned during Zune has gone into the Windows phone, and part of me beleives that the Zune was, at least in part, a precursor to the phone by design.

If I would make two of these installers I would make the full version one version higher than the base installer.

Ok, we're confusing terms: "Base" = Full (it's got everything including all the other installers), then "Upgrade". Can you repost using those terms, because I' mnot understanding what you're trying to say when we mix the terms.

A side note: when I'm in this situation, I create two installers: one base installer for new users, and an upgrade installer, and put them side-by-side on the download page, with the full one first - and I make sure I name them so it's obvious which one's which, as well as list the file size (so those with the full are generally forced to look twice). This means that people that don't read the instructions most often download the first one (the full), so even if they already have it installed, there's no harm done (other than them having a larger download).

As for your actual question: Sure, you can create a launcher that looks for the essential components then error out and close should they not be there, or dynamically load the main app if all is well. It's a good place to put custom license control stuff too.

I prefer to use the registry. We have reuse VIs that read application ini files in their application folder, then when MS really started locking down Program Files, we made drop-in replacements that work with the application's entry in the registry. Plus, that gives us a much easier way to overwrite or add keys outside fo the application's installer (eg: say an installed instance includes a couple of our products + a custom OI: we can install the standard stuff and keep it encapsulated as products, then overwrite any important custom stuff with the custom OI's installer) - works great iff you install stuff in order (there's something not quite right about LabVIEW's installer when it comes to registry keys).

"face heart"? Awwwww

So I wonder if this would make a nice labviewwiki.org entry? Maybe it could be expanded to include antonyms that are specifically LabVIEW-centric?

I am well aware of that. I purposely used shall to make this an enforced requirement. But, since I don't have to meet ISO or IEEE9001, this is more of a 'do as I say, not as I do' requirement...

That's the best kind of requirement

BTW: your post resulted in LAVA sending me 8 emails! Seems a bit excessive for a quoted reply...

Not sure why - I did build the reply (I'm on vacation at the moment, so I'm working on my phone.

As for BD size, our coding guidelines officially state:

Size considerations

The block diagram shall not exceed the size of a standard monitor...

Obviously, I sometimes violate this standard, but it is a good rule to try to live by, if for no other reason than it makes the code more 'portable' when viewed on other dev's machines for code reviews.

The IEEE9001 standard requires "shall" statements to be met, and shown to be met - never violated. You just failed an audit, my friend!

If the diagram becomes larger than one screen, review it and look for opportunities to improve readability and reduce size by inserting appropriate abstractions.

That's a great way to look at it - and we look at BD size, and many other metrics, with that in mind. For example, we try not to say that a VI with a high GOB count is bad - it's just a flag that it should be reviewed. There are several edge cases where high GOB count VIs make perfect sense, and the same goes for large BD VIs.

Sitting on the fence just hurts your arse

Then you're doing it wrong.

I think the most underutilized feature in LabVIEW is the SubVI. Use more subVIs people! Sheesh.

Maybe by CLADs, but not where I work. I often get berrated for using too much abstraction and too many subVIs. I like to think the berrators just don't understand my brilliance.

Seriously though, subVIs are great, and, just like everything else, should be used when appropriate. Just to get a little BD space is not one of them IMHO - using them in that way is obsfucation - which may be appropriate, but you need to be mindful that you're doing it.

Have you thought about encapsulating TCP/IP functionality into method(s) that have similar functions as the Enternet-IP API?

Google "delegate pattern site:ni.com".

That's what I meant to say.

Have you thought about encapsulating TCP/IP functionality into method(s) that have similar functions as the Enternet-IP API? That's how I'd look at it.

The response from NI is that the problem must be with our industrial PC's and "Don't use the Silver Controls". Not using the silver controls is no problem of course, but I am interested how common this problem is.

That's a valid statement for a workaround, but do you know if they've escalated it into a CAR to be further investigated? My gut tells me that there are a few people in LabVIEW R&D that would be interested in this issue.

The crash does not repro in LV2011 on Win7 x64.

I don't have any issues on my PC - although it's the same model as asbo's (Lenovo T510), with Win7 64 and LabVIEW 2011 32bit SP1 installed.

My goal is to write clear code. The block diagram will be as large as it needs to be acomplish that goal. (Yes, sometimes they'll even require scrolling in two directions.)

(single screen coding)... promotes readabilty and forces you to think about modularity. There is no excuse for scrolling all over the place, it is a symptom of poorly thought out modularity and hierarchy.

I think you're both right: I would never say that you should keep all code to one screen*, and I would never say you shouldn't keep all code to one screen. Neither of those statement makes sense to me, and they're extremist views, albeit in opposite directions. I think that there's a middle way here - it's like when someone says "never use globals" - to me, globals are fine when used appropriately. Try not to fall to far on one said of the fence on anything when it comes to software engineering - because all you'll do is limit yourself, your capability of thinking, and your code. State your view (as you have eloquently), and, if others don't agree with it, you can either maybe try to see a middle way, or ignore the naysayers

*Define "one screen", because I'm thinking my screen is a different size to yours

Sacred cows make the best hamburgers... I've carved off a chunk and I have to say it's mighty tasty.

Mmmmm barbque...

I strongly suggest you submit it to the LAVA Code Repository.

Can someone tell me what is the best method to use to synchronize the three boards?

Use the PXI trigger lines - that's the beauty of PXI

Can MAX 5.0 simulate this hardware?

I don't think so...

So basically - I'm getting the feedback that NI needs to do more pranks, in general, right? Coming right up...

Damn right!

Oh, and welcome to LAVA - it's lovely to see you here! For those who haven't met Emilie, she's a stalwart at NI Week and has been an advocate for us within NI - certainly a big plus having her here on LAVA

Hmmm, this thread has me thinking, not of a community patch, but of a "crelf patch", or a "VIE TSIG patch" that I can take with me to new versions of LabVIEW. Right now, I have VIPCs that link to packages for our reuse libraries, as well as the latest OpenG "patch", but I've never really organized myself to go much further than that when a new machine comes online. VIPM's behaviour is highly configurable, and is becomming moreso, this might just be a good idea, even if only a local one.

PS: I'd love to see an "AQ patch" - I can only imagine the goodies that would be in there!

my code always keep on going left to right so that i need to scroll more .. i know this is bad.

no No NO! Having code span more than the available screen resolution isn't inherently bad, and anyone who tells you so is a fundamentalist¹ itchin' for a fight

I don't have any problems with code that scrolls in one axis (ie: left/right OR up/down), and it's often impractical to code some architectures without doing this (eg: FPGA, ActiveX or any other property-/method-based work, some UI designs). It's when you need to scroll in more than one axis that I get cranky.

PS: I love having 2 monitors: one for FP, the other for BD - awesome when you're debugging.

^1. Each to their own. I don't have a problem if anyone feels the need to have their code fit on one 640x480 screen, but I prefer to be practical, which means my time is more valuable working on things useful to the world than crusading (often only if with themselves) for something like this.

To bad we don't...

Awesome: sounds like you're volunteering to help - contact jgcode and he can get you started.

I think this is a bad example usage of the feedback node. I would just use Add Array Elements and call it a day. Or if you feel like being complicated, keep the equality comparison and use the Boolean to (0, 1) node and iterative sum that.

Agreed.