ShaunR

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.

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!