crelf

Well. I deal with automation machines and if it doesn't work there are penalty clauses. The clients are only interested in what day it will go into production and plan infrastructure, production schedules and throughput based on them being 100% operational on day 1. Deficient software is something desktop users have gotten used to and have been trained to expect.

Ok, so we were trying to compare apples to oranges. 'nuff said

Software is the only discipline where it is expected to be crap when new.

That's not entirely true, but it's not entirely unture either. I think that some new softwares are expected to be buggy, possibly because they haven't gone through alphas or betas, and/or the market has forced an early release on a less-than-mature product. It's also one thing that makes software so awesome - changes (whether they're bug fixes or feature additions) can usually be made with a much faster turn around than hardware. That's not always the case, but if we're talking about product platforms here (which we're not ), then it's a great way to go- especially if you have more than one customer: you can weight feedback on feature requests and make strategic business decisions based on them, which can be super efficient during alpha and beta cycles, as opposed to waiting until full releases.

Imagine if an architect said "here's your new skyscraper, There's bound to be structural defects, but live in it for a year with a hard-hat and we'll fix anything you find".

Again, apples and oranges. Image an iPhone user who wants an app that allows them to read their email: if you said to them "I've got an app that does 98% of what you want, but 1% of the time it'll take an extra 30 seconds to download attachments, so I'm not going to release it for another 3 years until it's perfect". The iPhone user goes and downloads another app.

Also, skyscrapers aren't ever perfect - they're good enough. And I'm pretty sure building owners are given tours of their buildings before they're completed

As for the type of systems you build, I agree with you - and we make similar-sounding systems too. Such tings are decided at requirements gathering and design phases, and are usually locked down early. That said, we also have a suite of software products we use on these programmes, so it's a balance.

In summary, as Jeff Plotzke said during his 2010 NIWeek session: "Models can, and should, fit inside other models."

Alpha and beta testing (for me) is internal only. Alpha testing will be feature complete and given to other programmers/engineers to break it on an informal basis. For beta testing, it will be given to test engineers and quality engineers for qualification (RFQ). Sometimes it will also be given to field engineers for demos or troubleshooting clients equipment. Clients will never see the product until it is versioned and released.

That's an admirable goal, and works extrememly well in some industries. I sometimes find it useful to get feedback from end users during development, because, in the end, we want compliant systems, on time, on budget, that make our clients happy. That last item can be tricky if the first time they see it is the last time they see you

Anyway, it depends onthe idustry, technology , and client. All I'm trying to say is that deriding alpha and beta programmes completely doesn't make sense to me - every tool has a place.

How so? They can only put it through use cases if it works. Otherwise they are just trying to find workarounds to get it to work.

I agree that you can't dump it in someone's lap totally unfinished, but I couldn't imagine dumping it my customer's laps without them having an opportunity to tool around with it before its officially released. What you're suggesting might work for systems that have few and very well defined features, but once you scale up even just a little, the possibilities of what your customers might do with it grow quickly. Look at LabVIEW: I'm glad they have betas, because, without infinite resources or infinitie time, they can't possibly imagine to test all of the combinations of awesome things we're going to try to make it do.

Maybe we're comparing apples to oranges, or I'm missing your point. It's a thread hijack anyway, so I'm going to split to t a separate thread.

I only release stuff that works and looks clean. I also don't believe in alpha or beta testing (it's just an excuse lazy people/companies use for free resource so they don't have to test it themselves!).

...and the opportunity for your potential customers to help shape the direction of your product by pushing it through use cases you hadn't thought of

Maybe that's part of the stuff that Wirebird Labs is working on? I'd keep an eye on them...

We have had to do USB switching before, and used the J-Works SSB118.

Yes! I was skeptical when we ordered these, but they work great - and have LabVIEW drivers (well, wrapped DLLs ).

Revoked.

To solve this issue, after the build we went to the <application>.ini file and change the WebServer.Enable=False

Is your exe builder/installer pointing at a custom ini that has this line in it?

Whats the conversion from cookies to Internet points? To Internet dollars? To Zimbabwe dollars? Back to cookies?

1.27.

PS: The cake is a lie.

Pretty interesting, which is why I told you about it. You posting it kinda feels like you are stealing my internet points.

You want a cookie?

My cat is fat...

Okay, now it just got creepy.

LOL! Doesn't everyone?

Sure! With gravy, a side of potatoes and peas.

Can't speak - too awesome! Wait, is that Kim Jong Un?

This is totally my favorite Chinese group at the moment - I picked up a CD when I was in Donguan a few months ago. FWIW: My 2 year old son loves them too

I'm getting frustrated, thanks to some of you (Crelf!). I keep getting status updates in my work inbox about neat sounding LabVIEW-related things, but when I click on them, I can't access the site. Probably because all those shortened t.co addresses are aliases for shortened bit.ly addresses which is a domain controlled by the Libyan government.

She's on to us! <sound-of-circling-helicopters>

Sorry Cat - I fully support the concept that links in posts should be full, as there's no reason for them not to be. My guess is that I've pasted them from somewhere else: sorry about that, I'll be more vigilent in future.

As an aside: we use bitly to shorten links in our @lavag twitter feed - it gives us metrics on clicks, so we can see what stuff y'all are actually interested in. Apparently you like cats.

It's difficult to compare, as we don't know exactly what's going on under the hood, so we might be comparing apples to oranges without knowing it (eg: a c++ function might do a poorer job of finding an edge, but the IMAQ one might be slower).

I guess I need to know where you're coming from to better explore your question. Are you trying to decide on whether to use the Vision toolkit or something else based solely on execution speed? What's your target?

PS: The functions that are called in the Vision toolkit are invariably DLLs anyway, so perhaps the comparison is moot?

I think that maturing API designs is a key concept in professional software engineering, and for one's knowledge to grow, it's an important topic to understand (no one masters it, but it's fun trying ). I think NI's done an above average job on promoting good API design (even way back when they launched the NI Instrument Driver Network), and it's paying off with well designed products flowing into the LabVIEW Tools Network.

Here's an interesting article on high level API strategies on API Evangelist to get you started - read it here.

Please post your VI (you can take out most of your code if yo like) so we can take a look at it.

That this happened is actually kind-of neat: it suggests the number of people taking up community editions of the GDS has exceeded Symbio's predictions. Yay!

By the way, if you're reading this thread and don't know what the GDS is, have a look at it here. Then download and install it. Do it. Do it. Install it. Do it.

LAVA likes to keep you informed, and we know that a lot of our members have different ways of getting to LAVA, and one of those is to follow @lavag on twitter (we have over 400 followers). We'd like to ask our followers what they think of our tweets:

• Do we tweet too much/too little?
  
• Is the feed too technical/not technical enough?
  
• Do we tweet the right kind of posts/are we missing the mark?
  
• Have you followed us in the past, and don't anymore? We'd love to hear why and what we can do to change.
  

We've been tweeting for a while now, and we'd love your feedback on the @lavag twitter feed to help us better shape how we connect with you!

I've bought my t-shirt and I'll wear it next year at NIWeek - I'd love it if others joined me!

*Mugatu Moment - an internal struggle so confusing and contradictory that, neither absolutely nor ostensibly, one is unable to determine whether one is indeed h "taking crazy pills"

At first look, you might think "I'm not going to use that - I'll unsintall it so it's not hogging my PC resources", but I ask you at least learn a ltitle more about it - it's actually quite useful, especially if you use TDMS files, although it works great on other formats too.

I looked into it and tried the demo, but can't justify the overhead. My customers typically spec out delivery date, parts per year, perhaps what tests they want done (versus how to do the tests), and GR&R procedure.

Sounds like it doesn't fit your model at all. And that's okay - that doesn't mean Requirements Gateway is a bad product, it just means that it's not a good fit for you.

Also don't let your self be impressed with the graphical view shown in demos. With more than 10 requirements that view is worthless. I remember a few projects with several hundred, and one with over a thousand requirements where that view was just a blur of lines.

I can't agree more - we often open up the graphical view on even a small project for a few laughs.

That said, for what I do, IMHO the graphical view isn't high value anyway.

Put me down for a "me too" on a lot of these posts - we use it a lot, but our document templates match it well (or vice versa) so using it from project to project is simple and fast, but that's only because we spent a significant amount of time setting it up right (like most tools, I guess).

As asbo said, even if you're not in a regulated industry, it's worthwhile and gives you peice of mind. Even if it's just to make sure you don'e have duplicate requirements codes or the like. Of course, using it to its full ability is awesome too: there's nothing like a traceability report that's generated by a 3rd party tool which was written by an ISO 9001 certified company to make your customer sleep better at night

Featured how?

Dave talked about it for a few minutes and showed screenshots in this presentation:

Wed, Aug 8, 2012 2:15 PM - 3:15 PM

Hands-On: Explore Tools to Customize LabVIEW

Room 18D - ACC 4th Floor

Speaker:

David Ladolcetta, National Instruments

Presentation Options

View

Email

Track: Software Development Techniques

Customize LabVIEW by adding functions to the LabVIEW Project Explorer. Also learn to access additional resources and tools to improve the LabVIEW development environment.

Either CCT should replace it or VI Snippet needs more work. Since this is something that is (partially) integrated into the CCT I'm obviously not the first to see the benefit.

Sure, but as an integrated tool, VISnippet will probably be a little more hesitant to change, and wi'll definately take longer. I agree that updating VISnippet with all the CCT features would be perfect, but that's probably not oging to happen. That said, getting the CCT changed will probably result in less resistance, *and* the CCT developer doesn't have to wait until the next (or later) release cycle.

I don't mind either way - it's not a feature I'd probably use - I'm just expanding on the process as I see it.