ShaunR

Or you could just password protect them or save without diagrams. The advantage of DLL's as proposed by djolivet is that they don't require the full development environment (do you really install a Full Labview License on every target machine????); just the run-time engine which is installed as part of test stand anyway! It really depends on how often you need to make changes. Generally, Vi's are always converted to DLL's as the last phase of the release before deployment especially if it is for a customer and not for internal use.

If you start with the Labview Test Sequence Example (which I think we would all agree is useless) and change the individual tests to a single dynamic load, add a report,pre-test and post test VI (again dynamic load). With a bit of thought about the Data interface (2D array works best ) you can pretty much do 80% of what Test Stand does with a text file that tells the program which VI's to load. Discuss....lol.

QUOTE (hfettig @ Apr 11 2009, 04:56 AM) Unless you really need real time acquisition I wouldn't go with RIO (very expensive). PC as the controller (pc cards are cheap and you have the full flexibility and scalability of LV without the LV RT and memory restrictions) and any 3rd party ethernet acquisition modules (better channel count than NI e.g http://www.acromag.com' rel='nofollow' target="_blank">Acromag).

QUOTE (David Wisti @ Jan 23 2009, 06:04 PM) Yeah. Just what I need. Another license key to add to the 25 I already have!

Ive used Test Stand quite extensively over the years for testing and the biggest problem seems to be that it tries to be all things to all people. If it just stuck to being a sequencing engine then it would be fine. If your tests are all read some data from a device, record the result and check for a pass/fail and and spit out a pass/fail report at the end and your doing that over and over again regardless of number of UUT's and no user interaction, then its superb. However, if you are doing test like set a pressure and record the response over time and check that it reaches 70% in ...say 1 second, then you find it has severe limitations. In fact, you will probably end up writing a special piece of code to do that test because it's easier. If you have to write most of your tests in code, then basically you are just using it as a sequencing engine. You seem to end up exchanging one programming environment (e.g Labview, Labwindows,c++ or whatever) for another (Test Stand). And Test Stand doesn't do it quite right! You also have to write a large majority of the tests in code anyway and make them fit in. I now use the rule of thumb that if I have to write special test code for 40% of the tests (like the example above) , then the Test Stand overhead isn't worth it and will opt for a proprietry solution. As people have mentioned. It is a steep learning curve, but that is because you require an in depth knowledge of its features and functionality even to do fairly trivial things.

QUOTE (Ic3Knight @ Apr 11 2009, 09:11 AM) Using termination characters requires that a received message doesn't contain the character (otherwise you would return 1/2 way through a message). From your example, you only send 0x01's and 0x00's so jdunham is correct in that you can safely use 0xC0 as a term char for reading. Sending is different in that when you initialise using the VISA Configure Serial port vi, it does not set the termination char for writing (take a look inside, you could change that if you wanted to), rather, it sends the string you wire to it and terminates immediately once sent regardless of the characters in the string. So the short answer is yes 0xC0 would still get sent if you wired the term char 0xC0 to VISA Configure Serial port vi since the term char only affects reading.

QUOTE (crelf @ Apr 6 2009, 07:56 PM) Like I said. It depends on distance and whether he wants to build an interface or buy off the shelf.

QUOTE (raymyster @ Apr 6 2009, 01:07 PM) What switches depends on the range (laser are generally longer ranges than.....say...photo and inductive - not that inductive would be any good for detecting your hands...so how far away are you from the interface?) and probably more importantly on your budget. Other factors will affect your choice (do you have to see the spots...if not then maybe IR?) do you want to build something cheap (laser pointer and photo-detector < £5) or buy something to industrial standards (Pepperl + Fuchs £50-£100 each). Only you can choose the sensor as only you know your project. Go down to Maplins and see what they have or if you have an account....RS Components have loads under "Sensors and Transducers" e.g http://uk.rs-online.com/web/search/searchB...t&R=5103249 Getting it to the parallel port is with wire! Lots of info out there on using the parallel port as digital IO http://www.doc.ic.ac.uk/~ih/doc/par/ and I guess you haven't looked at the example yet to see just how easy it is to get the data in (watch the voltages though.....parallel port is 5v and many off the shelf industrial sensors are 12-24v!). You could go for a digital IO card but why not use the one that comes with every PC as you only need 2. With a bit of thought and preparation, you should have this up and running in 1/2hr after ordering/receiving the bits! function alert(m) {} QUOTE (mross @ Apr 6 2009, 02:51 PM) Yes, LabVIEW can do what you want. LabVIEW will do it much more easily than C++. But interfacing... I have not done that. I stick to LabVIEW. I do not see the point of lasers. You can use mechanical switches that cost a few pesos just as well. Thats not the brief. QUOTE we need to create 2 sensors with beams that will be projected to my hand, when i swing my hand left: a labview vi will detect that & send a left click instance to the c++ engine. & same thing vise versa when i swing right. QUOTE With a proper data acquisition and control system, you can sense and respond to continuously changing inputs which will be better for aircraft control. A binary system - hand blocking laser versus hand not blocking laser - is an ineffective way to control all but the simplest systems. How will you tell it to turn slowly or quickly? Indeed but that is not the requirement. I imagine this is a learning exercise rather than a commercial product to fly airplanes. QUOTE Your parallel port is not easily useful. It is a digital system. You can use use this for sending simple digital IO, but this is a misuse - alot of trouble with little payback. If you have a microcontroller that can send parallel information (bits, bytes, and words) then it is used properly. Only in this way can you get continuous control of the aircraft. I Disagree. Little trouble and cheap. Bits, bytes and words are just highs and lows on a digital IO interpreted in a certain manner. QUOTE LabVIEW is a full featured software development environtment. The learning curve is steep, but significant. It does not seem practical to me that you should be using LabVIEW for this small project. You should be learning your C++ to do this. Apart from the fact that that Labview is more intuitive, has lots of examples you can modify for just this sort of thing and (more importantly) they have already done it in C++ but using a keyboard. I think the most interesting conundrums will be when they want to interface the Labview to the rest of the existing system. There is no sane reason to use Labview for this trivial part of the project (and mixing languages is always more trouble than it's worth) when all they have to do is read the parallel port/digital IO or whatever interface they choose, directly from thier C++ program which is why I am lead to beleive this is a learning exercise. function alert(m) {}

2 laser switches and the Parallel port VI example. Move hand left, breaks beam 1. Move hand right, breaks beam 2.

If you were previously using hyper-terminal then your messages are probably line feed terminated. Make sure that the serial init is set to use a terminator and the term char is 0xA. Don't bother with the bytes at serial port property node and wire a huge number (say 1024) to the bytes to read of the Visa read.vi. The number has to be big enough to receive your longest message and don't worry......the read will automagically return on the term char if its less. There is a serial example in Labview. "National Instruments\LabVIEW 8.2\examples\instr\smplserl.llb". Notice they don't use the bytes at serial port!