crelf

That's the best kind of requirement Not sure why - I did build the reply (I'm on vacation at the moment, so I'm working on my phone.

The IEEE9001 standard requires "shall" statements to be met, and shown to be met - never violated. You just failed an audit, my friend! 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. Then you're doing it wrong. 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.

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.

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. 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.

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 Mmmmm barbque...

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

Use the PXI trigger lines - that's the beauty of PXI I don't think so...

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!

no No NO! Having code span more than the available screen resolution isn't inherently bad, and anyone who tells you so is a fundamentalist1 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.

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

Agreed.

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. There's no such thing on the interwebs. Right.

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).