ShaunR

Unwired, yes. Unwritten? Citation needed. Seems odd behaviour since you wouldn't expect a FP display to show zero in the same circumstance. you would just expect it just not update. Additionally. If you probe the wire in the case statement. It will retain the value, so why not the indicator? This seems like an overzealous optimiser issue.

Maybe there should be a whole section, or at least a dedicated thread, on Lavag for anecdotes like these. You usually get one guru that knows his stuff and is the only person that can make decisions. The rest of the dept are usually just a load of bums on seats armed with a PDF full of excuses which eventually just boil down to the fact that they fart unless the guru says so

Expect a call in few weeks when they close that loophole and the software grinds to a halt once again.

So what was the solution? Tell them that their IT department could only FTP into the system and disconnect it from their network? I've done that before This is why the attitude exhibited by the IT guy at CERN who gave that presentation was so refreshing. In IT, a solutions provider is as rare as rocking horse droppings. Empire building problem providers with aspirations of .tyranny are 10-a-penny.

There are quite a few ways to go about this. Take a look at the examples "ColorMatching Example (Express).vi" and "Threshold Example.vi" that are shipped with the Vision Toolkit. You'll be able to find them in the Example Finder (Help>>Find Examples) and using a keyword search for "vision"

Great. That's the hard bit sorted then. Designing the UI is no different from other visual languages-you have a form (front panel in LabVIEW parlance) and you place controls on it. You just need to learn how too use the editor (the LabVIEW IDE), Once you realise there is no separation between source code and front panel and the only difference between a user interface and a VI is visibility of the front panel (see the VI properties), you should find things really easy.

Rule #1 of arbitrary verbal tasks. Get a signature and a delivery date! First hing you must do before writing any code is get a signature as to what the software will actually do. You need definitive answers to questions such as will it support bank holidays in EU, Asia, USA or all of the above? Does the week start on Sunday or Monday (or is it configurable)? Does "only allowed to use LabVIEW" mean you cannot use a database?. So you need to create a requirements and a design document that details how the software will function then get your boss to sign them! The requirements doc will tell you if you have finished (does the software meet all the requirements). The design doc will tell you how to achieve the requirements (we'll use a MySQL database with these tables and these user interface dialogues). Sneak in a line that says you can use other languages other than LabVIEW to see if they actually read it If they don't then you have given yourself a get-out clause that they have signed that will allow you to fall back to a more comfortable language if time constraints bite or things are too difficult..Signed words trump hearsay, period! Politics- the anathema to engineering You will want to (if possible) use a database so SQL will be your main language, technically. Design this from the bottom-up. Start with your DB, figure out the schema and all the queries then choose your language to generate and display the results of those queries (in this case LabVIEW). Think of your UI as just a string generator for issuing commands and displaying responses. This is the easiest implementation to understand and code for. When you get good at LabVIEW you can be more adventurous but for now KISS! The Database Communication in LabVIEW tutorial is a good starting point to ease you into it. It finishes at just the point where the LabVIEW starts. Get the DB right then just bolt on a front end. You can even get it all working in Java or whatever then swap it for a LabVIEW front end to fulfill the "must use LabVIEW" requirement. This is a 1 day programming, 1 day documenting and 3 weeks learning LabVIEW type of task.

So they are not equivalent. When you disable the power supplies on the test system does the performance improve?

Starting to sound like the object cache. Do you have separated compiled from source? IIRC that was really flaky in 2011. I had no end of troubles with it especially with the 64 bit version. If you haven't already done so. Turn off the separate compiled code and then delete the object cache. Then try a full compile before building the exe.

Well bugger me!!!! Welcome back stranger .

You don't need to use VITs. A reentrant VI is perfectly fine. Just open it with 0x8 flag. Then you don;t need an external template file and it can be self contained in the executable. If you look at the Dispatcher Demo. It has a VI launcher that is used to launch a number of Publishers and Subscribers dynamically. It also does some extra stuff like position and show/hide the FP (useful for debugging).

There is a package (LVSpeak?) that was written by Norm Kirchner that used speech recognition to control LabVIEW. Might be a good place to start.

Well. Neil has given you the VI to turn the Nagle algo off. So that shouldn't be a problem. There is no primitive to use with the standard TCPIP VIs to find the number of bytes waiting. There is a Bytes At Port property for VISA, but people tend to prefer the simplicity of the TCPIP VIs.

250 ms is pushing it as that is what the default nagle is. That should not make it back up messages, though, just your heartbeat will timeout sometimes. If you have hacked the library to use BUFFERED instead of STANDARD then it is probable that you are just not consuming the bytes because a read no longer guarantees that they are removed. That will cause the windows buffer to fill and eventually become unresposive until you remove some bytes.

As a guess I would say you probably have a short timeout and the library uses STANDARD mode when reading. Do you get this behaviour when the read timeout is large, say, 25 seconds? Most TCPIP libraries use a header that has a length value. This makes them application specific, but really easy to write. They rely on reading x bytes and then using that as a length input to read the rest of the message. That's fine and works in most cases as long as the first n bytes of a read cycle are guaranteed to be the length. What happens if you have a very short timeout though (like your zero ms)? Now you are not guaranteed to read all of the x length bytes. You might only get one or two of a 4 byte value and then timeout. If using STANDARD mode the bytes are returned even though timed out but now they are gone from the input stream (destructive reads). So the next stage doesn't read N bytes as normal because of the timeout but now you are out of sync so when you come around the next time you start half way through the length bytes. This is why Transport.lvlib uses BUFFERED rather than STANDARD since buffered isn't destructive after a timeout and you can circle back an re-read until you have all the bytes at the requested number of bytes.

Timestamps are very useful.. That's the reason I added one to the Transport.lvlib so that I could ascertain the clock skew between the sender and receiver.

A listener has to be running for a client to connect via TCPIP otherwise you should get an error 63 (connection refused). That's just the way TCPIP works. It is up to the client to retry [open] connection attempts in the event of a connect failure but the general assumption is that there is an existing listener (service) on the target port of the server that the client is attempting to connect to. N.B. Regardless of the purpose of the data.to be sent or recieved. In TCPIP, Client = Open and Server = Listen

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.