Leaderboard

With RS-232, you have to send a query to receive data. You might not see it, but that's what the manufacturer's software does. The same is true from Hyperterminal or LabVIEW. Now, I'm not used to HyperTerminal so I don't know why it bugs you, but with LabVIEW, make sure you check these things: To which COM port is your DMM connected? What is the command (query) to fetch data? (the manual is 55MB and takes forever to download, so I don't think I'll have the patience to finish the download) Have you installed VISA drivers from NI? You should get an error message like this if you didn't: Error -1073807202 occurred at Property Node (arg 1) in VISA Configure Serial Port (Instr).vi->Basic Serial Write and Read.vi Possible reason(s): LabVIEW: (Hex 0xBFFF009E) VISA or a code library required by VISA could not be located or loaded. This is usually due to a required driver not being installed on the system. Using the "Basic Serial Write and Read.vi" example you got from NI examples is exactly where you should start. To query the DMM, you've got to have both "write" and "read" switches to ON position. In the "string to write", put the query command. Then press the start Arrow and you should get the data in "read string". Make sure you have the right COM port selected in "VISA resource name".

Part of test driven development will always come back to design. One of the key benefits of unit testing in general is that it forces you to think of your code in terms of APIs. Your unit tests are actually testing the API to your internal code. If you can't test your code without hardware, you don't have a good API to your application logic code. There are different ways to enable simulation: Adding a simulation input (or property), using LVOOP and inheritance to create a simulation implementation of an abstract class, etc. Creating unit tests forces you to think about your code's interface at an early stage (or even at a later stage when you may need to refactor code and want to validate that it isn't broken). One thing that I think works particularly well in VI Tester is the ability to use the test harness (VIs that are called before and after each test) to do things like set a simulation flag so that your tests run your VIs in simulated mode. At JKI, we currently are able to do UI testing using VI Tester and are running these tests to validate certain VIPM features. Adding UI testing capabilities to VI Tester is on our roadmap. I really recommend that you investigate whether VI Tester would meet your needs, trying to create unit tests without a framework is a fairly arduous task and will ultimately cost you more time than investigating tools that already exist. You may as well leverage the years of effort that have gone into the existing tools rather than start from ground zero. Besides that, VI Tester is free, so there really isn't a barrier to entry

I prefer method 1 What I do instead of waiting in a loop is to pass an occurrence ref into it and then when the spawned vi is loaded it sets the occurrence which is the signal to the launcher that it can continue. Another advantage I like about method 1 is that you can include your vi within your code but have it cased out, so if it's broken you know about it at top level also you don't need to include it as a support file when you build, its already there. One trick you need to be aware of is that LabVIEW will strip the front panel of any vi unless you have the vi property "Show Front Panel When Called" set to true or you have a property node of a control in the code. I don't know the performance advantages of each method though.

Definitely hang out on the forums and ask many many questions. I would say that if you want to learn how to program LabVIEW, find something that you want to do that would be solved with a program and just program it up. An interesting example is something as simple as a contact management program. A more involved but useful program might be tracking expenses quicken like. Or if you have a few dollars to spend, grab a USB Multi Function DAQ card along with a few relays, sensors and motors and automate something in your dorm room. My personal favorite that never got implemented was just a basic door opener or re-inventing "The Clapper". Actually I did do the code for the clapper to be honest, but never hooked up the relay to my parallel port. And if you're too young to know what the clapper is, just youtube it.

If you don't have VI Analyzer toolkit, see if this can help you. With scripting available, we can now definitely build analysis tools of our own. Test_CheckAutoGrowOff.vi (LV 8.6, requires OpenG Rectangle tools)

From what I've been reading it sounds like this could be a scripting issue, perhaps even a right-click add-on: viz, to search the entire project for items beyond the boundaries of a structure and report that location, along with the number of items that are "hidden".

QUOTE (Antoine Châlons @ Dec 18 2008, 06:08 AM) There is probably no way to disable this completely. At least the first time you really do want to have this security check as otherwise every virus could connect to Skype and (ab)use it for whatever it wants. MS had this in the past that any application could conenct to Outlook over ActiveX and that was a perfect way for a Virus to harvest the entire email address list as well as using the Outlook credentials to send out tons of spam mails. So they had to disable unnoticed connection to Outlook over ActiveX with a security patch. Maybe that Skype will cache a once given acknowledgement for a specific application somehow so it won't prompt each time again but the first prompt you do not want to give up ever! Rolf Kalbermatter