ShaunR

You can use the edge detection with the IMAQ MagicWand VI bounded by your ROI boxes to produce the mask. It will fill to the edges of your region (either inside or outside your edge). You can then either use that as a mask or just count the pixels as a percentage of the area.

Why are you removing diagrams from the VIs? If you don't remove the diagrams, then you can use the externals/submodules features quite happily in all [forward] LabVIEW versions. The issue with LabVIEW is re-linking, If a VI changes or is a different version, then LabVIEW usually wants to recompile the entire hierarchy including those you pulled out from other projects. The separation of compiled code from the diagrams has eased but not eliminated that aspect.

The project size is determined from the requirements. The risk assessment defines the variance due to mitigation (replaces your arbitrary fudge factor) and the effort required is derived from the tasks identified to achieve the requirements. This is all straight forward and exist in all formal methods but usually not the cause of over budget or project failure The biggest problem is generally not identifying all the tasks that are outside the purview of the person quoting. Software engineers know little about how to build machine frames from aluminum, for example and may under estimate hardware resource requirements or assume instruments are available instantly when required.. Breaking down the requirements into the effort required is time consuming. This is a problem since at quotation you do not have a budget, you only know the starting point for features and are not guaranteed an order. However. you can mitigate by operating a two step quoting process (lets not get into the project flow at this point) which enables a first guess (known as a budgetary quotation) which cannot be ordered against but aims to be within 5-10% of the final quotation assuming things don't change. This enables a quick response with small outlay of time and energy to ascertain the probability of an order. It also allows the customer to waive a figure in front of their colleagues and peers and does not commit you to delivery. If they are serious, then they can apply for a full quotation and you can commit resources to a full breakdown or decline to quote. For small teams/businesses. It is a great advantage if you can split out the development from the requirements discovery especially if the customer doesn't have a detailed specification. This is a big bugbear in non corporate environments which tend to have minimal or undocumented, requirements definitions with vague references to other projects or driven by a guru that has "some thoughts". These customers need to be hand-held through the requirements discovery and sign off on a detailed requirements spec that you will formulate to their satisfaction. 90% of the time this is not factored in on Waterfall Projects since it falls between the hand-off from sales to engineering although it has to be achieved before any code is written but they already have a price so you are already at risk . If you are on good terms with the customer, then you can usually get a payment up front for the "Feasibility" phase which you can iron out the exact requirements over an agreed period and iteratively define the requirements to their satisfaction with no expectation of delivery. This gives you your first flag in the ground to start development and you should have detailed requirements and implementation documents for the engineers.

That approach will probably end in random crashes. When dealing with DLLs the memory to be written to must be the correct size or bigger. If it so much as one byte too small, a crash (GPF) is inevitable, although sometimes not predictable. The only safe way is to know how big the memory allocation needs to be before writing data into it.

Just to expand on what Rolf is saying. There is a catch 22 with these sorts of functions. To resolve the "need to know buffer size before knowing the buffer size" problem. Many functions allow calling with a null pointer for the array/string which then populates the size parameter. You can then call the function a second time knowing the size from the previous call.

I have a feeling that when you say "Query" you only refer to getting information out of the DB. Queries are also used to put data in (like the results) Take a look at the Board Testing Example in "examples\lvoop\BoardTesting". Look to see how you would convert that into being sequenced from test stand rather than LabVIEW. Look at where you would replace the board information, pass/fail criteria and results logging with SQL. Move the responsibilities, piece-by-piece, over to Test Stand until you are satisfied. If you can do it with that example, you can do it with most test systems. It will answer nearly all of your above questions and provide insight as to .where your design decisions are crucial and where they are arbitrary preference. You will reach an equilibrium point where things become a lot harder to move over or become overly complex (at the hardware abstraction usually). It will also be a good frame of reference to ask specific questions that we can give answers to with practical examples. Just bear in mind that Test Stand is a sequencing engine using linear scripts. It is not a programming language!. Don't complicate it by trying to force a scripting IDE to operate an OOP architecture - let LabVIEW do that and use Test Stand to drive it. Test Stand does many things exceptionally well but much of what is advertised is better done elsewhere.

This is a real issue with linear life cycles and whilst it can't be eliminated, it can be mitigated by not using them at all The short answer is use an iterative/cyclic life cycle (I'm deliberately avoiding the use of the Agile word). Iterative cycles enable staged payments since you have customer identifiable, feature milestones and it reduces your risk exposure to specification drift . There are also no surprises for the customer. The customer sees progress easily and, unlike linear cycles, timescales and billing can be adjusted during development.("sure we can add that feature-it'll cost this much and push delivery out by x weeks") No. LabVIEW projects are no different to other software projects. Short iterative cycles. Operate what I call the Bunnyman principle (ECCO). Early involvement, Constant Communication and Often (with the customer). You factor it in by specification. If you have bums on seats programmers who'd rather be doing Python, then you will need to specify every VI, its behaviour, and its inputs and outputs(detailed design specs). If you have some neck-beard programmers, then you can create a systems design document and they can create the detailed design for you (that's what CLAs do in the exam). Where many companies struggle is they don't have a dedicated, customer facing, project manager or systems engineer and rely on one of the programmers who are then also factored into the software development. It's a double spend since that person will be so busy making sure the wheels are oiled - site visits, meetings, purchasing, answering questions, hammering out specs, handling subcontractors - they won't be doing any programming. I would suggest that you promote one of your CLAs to Chief Systems Engineer and let him only do that for all the projects.

convert numeric string2009.vi

There's also Daklus LapDog which is (arguably?) more equivalent to the AF than messaging libraries and IMO superior to the AF. There's lots of info over on the dark side.

Pretty much my assessment so my comment was agreement with you. For clarity, it is well known I dislike the AF, hence the predictably bit since I view it as a Rube Goldberg machine that solves a problem noone really has, in a way noone really needs.

Predictably, +1

I don't have a Pharlap target, so I won't be able to investigate. However. If I had to guess at a starting point; I would be looking at the variant type library since it uses UI (orange) calls to LabVIEW.

Whats the difference between your "public data member" and a global variable?

Hmmm. Marked as broken? If i hadn't stumbled into the code repository area by mistake, I wouldn't have known. I wonder when that was reported? P.S Can we change the spelling of my name in the VI package description? (just noticed)

Right click on the read and write primitives and select "Synchronous I/O Mode>>Synchronous".

All implementation questions Once you have figured out how to query a database and populate the station/sequence variables with the results (manage your inputs as you put it), the rest will be down to your specific design and preferences.

In the "one that works" the VISA timeout is 10 secs, whilst the one that doesn't it is 200ms.

In theory, LabVIEW should be pretty good. I know of a couple of web CMSs that you can create web pages by dragging and dropping and people use their mobiles to update their websites. Typing is horrendous, but LV being D&D you would just need a quick way to bring up a condensed palette (no right-click) and rely on the auto-tool (may need some tweaking). I think you could probably come up with a "quick-bar" for the IDE that would make it fairly painless. Of course. If you rely on quick-drop, you'd be stuffed

If you are looking for a "Design My System" button. There is none. You have to design it. Welcome to the world of Systems Engineering. If you have a definite specification or a question about a technology then we can assist. However, we cannot design it for you-that's your job. Getting data into and out of test stand is either a training course or reading the documents. Same goes for SQL and LabVIEW (although JKSH has told you a very easy way as long as its not a MySQL database). If you are looking for an "in". I.e the issue is "where do I start". I would suggest reading up on SQL, download a few examples and decide what data and therefore what queries you will need to do each test in the specification. There are no short cuts here, I'm afraid. It is application specific. Once you have done that, it then becomes more obvious how difficult the tests will be to execute in each environment. Do this, do that, read result very easy in Test Stand. Increase until X, wait until Y stabilises then check Z much harder and probably better in LabVIEW.A lot will depend on your own preferences and your or your teams abilities' as to how much you do in Test Stand and how much in LabVIEW or if one will suffice for everything.

Maybe. Maybe not. I don't think you really believe that. I think talks like the security one at CERN, though, should be required viewing and it would be a disservice and detrimental to the community not to make it widely available!

I have just been watching a shed-load of videos on Eliptic Curve Cryptography and Distributed Hash Tables. May seem like a strange combination, but there ya go. Where they even aimed at a LabVIEW programmer? Nope. Where they of different depths and breadths? Yup. Where a lot of the things they talked about way over my head? Only until I looked at more videos and academic papers to fill in the gaps. Would I be thinking about the networking system I have buzzing around my head if I didn't have access to those videos? Not a hope in hell! One video required me to watch 5 other videos and read 7 PDF documents from NIST and various Universities to understand some of the things they were talking about. Maybe one of your non-general and targeted presentations would be, or has already been,, a similar starting point for a journey of discovery.for someone.

Hmm. In that case. I'm not sure any context can be given for an in-joke no matter what the medium. It is quite likely that of a room of people, not everyone got it anyway. Differences between presentations? I'm not sure that is relevant. It is what it is for who it was intended for; presenters change their talks all the time. It seems a bit harsh to say no-one can benefit outside the club because the presenter has to be more careful with their language. It's not as if it was being surreptitiously videoed without the presenters knowledge for a sting to catch them out.

Can you put more meat on this? What is the imperative for downgrading? What issues does it address? What are the likely side effects?

Presentations are self contained with a title. They are from a "LabVIEW CLA summit". What more [context] is there? What exactly is your worry if it's not the feelings of the presenters or the availability to non CLA programmers?

No. I hope you are just being facetious. As an aside. What happened to the VI shots podcasts?