ShaunR

I do have a developer suite which on a SSP, and no. I don't get a single license for all the packages. Apprently thats only for a volume license agreement...I've tried!

Can reproduce it too. If you resize the window it sorts itself out. Looks like a refresh problem. I can get round it by writing to the bounds property of the vi (i.e forcing a refresh). But that doesn't enable you to "restore".

QUOTE (Neville D @ Apr 13 2009, 09:03 PM) I have also used cFP for testing Train Valves, machine control and factory monitoring (many moons ago now). I disagree you are paying for robustness and ease of use. I think you are paying a premium for the NI name. For most of my applications it's the channel count vs cost that is prohibitive. I find dumb 32channel Gigabit Ethernet digital/Analogue IO is far more cost effective and easier to manage (IP65 compliant @ £600 all in) than any of the NI solutions. Even a PLC is 1/3 the price if you really must have real-time. QUOTE Again, your mileage may vary but I regularly use wireless connectivity to view camera output for alignment and calibration in a vision application in a saw-mill. The distance to wireless node is about 50m through lots of steel walls with no problems. I get about 9 frames/s but thats good enough for my application. This is using a regular laptop with 802.11g with commercial OTS networking hardware (nothing fancy, custom or expensive). Does it matter if you lose a frame now and then? I looked into using wireless camera's for checking rogue parts from from several bowl feeders that were feeding an assembly line. The process line was spread out over a 180sq ft factory floor with the operator in a cubicle at the end (wireless was an ideal solution). From testing, we randomly lost 1 in 30 frames on average and this went up to 1 in 12 if someone used bluetooth near the furthest feeder. Another example was a wireless remote alarm system that would feed back monitoring info to a central monitor. We had so many false alarms because the IT department had whitewashed the place with their wireless APs (it was cheaper than wiring and.....typically, they wouldn't let us near them!), just so the sales guys could wander around with their laptops and still have internet (although we did cause them grief as well ). I regularly VNC into machines wirelessly, but wouldn't trust it for serious remote control or acquisition. QUOTE I guess the ultimate choice of hardware depends on needs as well as budget. Neville. NI PCI cards are cheap, reliable, have high channel counts, easy to use and I go for them every time. But for remote acquisition there are far more cost effective and better solutions out there if you have the courage to step away from the warm fuzzy NI bubble. QUOTE (crelf @ Apr 13 2009, 09:21 PM) Make sure there is a requirement to go wireless - some sites specifically rule-out wirelss (military, standards comissions, etc). Amen!

cFP are not cheap. You start at about £1,000 just for the controller and once you've added the backplane, and IO you are generally looking at about £2K+. RIO's (as far as I'm concerned) are just repackaged fieldpoints. Considering you will have multiple end points, you will need a controller for each point (NI will love you a lot). DO NOT GO WIRELESS!!!! (especially if you are in an industrial environment) unless you really have to. There aren't many pro's but shedloads of cons.Wires don't drop connections and interference is rife in the 2.4GHZ band. Also solid structures (like walls, cabinets and even people) attenuate the signal immensely. Just search the net for problems people have getting a signal from one side of their house to another let alone 200m!.

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!