crelf

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.

Windows is not deterministic, and should not be used for an application that needs to maintain timing less than 1 ms.

Quick clarification: Windows *is* deterministic, if your acceptable jitter is high enough. LVRT is more deterministic than Windows, but you can't say an OS is deterministic or not - it all depends on your use case.

The more you build a relationship with your sales guys (local and inside) the better they'll understand your expectations and requirements. Remember that most of us aren't the architypal NI customer: we usually can put a system together on our own, and don't need a lot of help, but NI gets a significant portion of their sales from newbies that really appreciate someone in-the-know walking them through it. And, when it comes right down to it, NI's sales guys are there to, well, close sales - and few sales guys closed extra sales by doing nothing. Build a relationship with NI, and overtly tell them how you want your relationship to be - then you should get fewer direct sales calls.

They'll still track your use of their site (and why not? it's *their* site afterall), but you can mould the relationship.

...something tells me they should call them something other than "private message".

There's no such thing on the interwebs.

try asking them nicely to stop doing it. it never hurts to ask (nicely).

Right.

Any interest in using CrowdTilt or similar to raise funds to contract out the migration? I would chip in.

Or Kickstarter.

That said, I'm not sure how easy it would be to contract a migration like this - the site's in a pretty bad state, and I think it would take people with a little OpenG knowledge to do it effectively.

If you don't want NI to track you using their site, you have two easy options: don't browse their site, and don't login when you browse their site (but you won't get content you have to be authorised to see).

Well my methods may be disgusting but at least spaghetti_developer agrees with my methods...on second thought I'm not sure how I feel about that.