Bryan

A good book I used in College was entitled "LabVIEW for Everyone". I'm sure there are better books out there now. But, just like you, I had some basics courses and learned the rest on my own. I feel that this is a very beneficial way of learning LabVIEW, however it often leaves 'gaps' in LabVIEW knowledge if your self-teaching doesn't lead you down all of the possible patchs.

I've done analog output before (I'm currently doing it now), but I have never had to generate an adjusable output waveform, so I may not be able to help much. As far as the software suggestions, DAQmx and tradidional DAQ are very similar except for the fact that DAQmx has everything sort of combined at a higher level. Some hardware may require you to use DAQmx, while others may be compatible with both Traditional and DAQmx. Also, I looked through my Traditional and DAQmx DAQ functions and it appears that you can specify the actual waveform to write, not just tell it frequency and amplitude. There are also functions (in DAQmx I know for sure) where you can start a read/write buffer for faster reading and writing. If you use all of this together, and put your write function in a loop, you should be able to wite your waveform (adjustable via your own code) to the output buffer and so long as you're adding enough samples to keep the output buffer filled, theoretically you shouldn't have any glitches or hiccups. I ran into my problem with DAQmx and my DIO inputs glitching and hiccuping, but that was because my DIO card is static and not buffered. So long as you have a buffered analog output card I think you should be okay. Once again, like I said, I've never actually written an adjustable DAQ analog output waveform program before, but this is what I would look at if I were given the task. As far as DAQmx or Traditional, if you're "forced" to use DAQmx like I was, there will be a learning curve in there since it's relatively new and there isn't a whole lot of in-depth information out there on it yet I've found. I'll try to help you out anyway I can based on what I've learned about it so far if you have any questions you want to ask me. It's early in the morning here, so if any of the above doesn't make sense, feel free to harass me about it. At least I'll be prepared this time unlike when asked what I would do if a system was just plopped into my lap. Haha!

Awesome! Works great! With LV 7E I normally wire up a few that I use and set the rest of the outputs to return a default value. But this guy will DEFINITELY come in handy. I'm so glad I found this board.

Really? I actually didn't know that. I've always done mine like you suggested below: That reassures me that I'm programming wisely. I've never had a whole lot of interaction with other LabVIEW programmers, I've learned all I know right now pretty much on my own and have worked independently with LabVIEW (most places I've worked, I have been the only LabVIEW programmer in my department). It's great to get confirmation from seasoned LabVIEW programmers that I'm going down the right path.

If you go to the very last button to the right on the tool bar, (the one that contains "move forward" "group" "ungroup" etc.) There's a selection called "Lock". Just select all controls that you want to lock in place and go up and select "Lock" and there ya go.

I would make it a long password too. Not too long ago I was browsing the NI Developer Zone and came across a VI that cracks password protected VIs via the brute force method. The longer the password was, the longer it took. I have a 10 or so character password that I apply to some of my VIs and I didn't have the patience to wait around long enough to see if it could crack them.

This link looks promising maybe: http://cp.literature.agilent.com/litweb/pdf/5989-0153EN.pdf I don't have time to look through it completely. Most of the information I've found for devices I've interfaced with I have found in the manual or command reference guide. (RS232/GPIB)

FILE >> SAVE WITH OPTIONS >> CHANGED VIs >> REMOVE DIAGRAMS Make sure you keep a copy with the diagrams, if you don't you won't be able to make changes to it later.

Hi everybody! *Response: Hi Dr. Nick!* (I'm a Simpsons fan) I'll start this off with telling a little about myself: My name is Bryan and I live in Southern California. I was semi-involuntarily relocated here from my home-state of Pennsylvania by my former employer Corning Incorporated. When they decided to cut back involvement in the telecommunications industry, I was laid off after 5 months of living in California when they closed their Fountain Valley plant in Feb, 2003. Now, I work for Balboa Instruments as an Associate Software Test Engineer. I know a couple of languages, but my most proficient is LabVIEW. I have worked with NI Data Acquisition, NI Vision, RS232 and GPIB instrument control and monitoring as well as PXI and a little VXI. Other languages from most to least provicient are: VBA (Excel) automation, Visual Basic, Tcl/Tk, PHP/MySQL, MS SQL as well as some HTML/JavaScript thrown in there. All of the internet-related languages I use in my free time helping a friend with his little web-development business. My interests are as follows: About anything automotive or on wheels. (I have a 72 Chevelle that began as a father/son project). Carpentry/home improvement and electronics. Music - Vocal and instrumental (Guitar, Trumpet, Drums, Bass, Piano) Spending time with my wife, family and friends (I don't have any kids... yet) Learning anything to enhance my skills and abilities. I'm also a member of a couple of automotive enthusiast boards (admin on 1, moderator on another), and I find them as a great source of information which is why I looked for a LabVIEW forum and stumbled into LAVA.

I believe the write labview measurement file function is a higher level vi that opens, writes to, and closes a file each time it's called. Opening and closing every time sucks up computer resources. If you can open the file at the beginning, pass the reference to your loop with the write function inside, then close it after loop completion, you'll get faster logging. If you're set on using that function and your current method, and you're not using a delay in your loop, then I'm afraid you'll be limited to your computer's processor speed.

I thought he was talking about the path TO his ini file. I didn't know he was talking about using a file path that he was reading from an ini file. Agreed, I would hope that he would store and read it as a path instead of a string.

Wow, that's strange, I've never tried it that way. I've always put paths in as: c:/dir1/dir2.../file.ini I've never omitted the forward slashes or backslashes. Regardless of how you fixed it, I'm glad to hear you got it working!

Use probes (Right click over a wire and select "probe") to make sure that the correct file path is getting to your "Open File.vi". Also, I see that you're using "\" in your file paths. While that's the windows native method of specifying paths, I have always used "/"s when specifying file paths in LabVIEW and it has always worked for me. Using a "\" is the native method of specifying a file path in your address bar and in some programming languages, but I believe that using "/", which is used for relative paths is what's used in LabVIEW. I'm not sure if LabVIEW accepts the "\" character as anything other than when specifying a literal character. Give that a shot, converting all "\"s in your file paths to "/"s and see if that helps, I hope it works!

No problem on the confusion. I'm more familiar with the lower-level LabVIEW programming because when I first started using LabVIEW, there wasn't a whole lot of higher level things for me to play with, and the ones that were there lacked some desired functionality, so I ended up in "trial-by-fire" situations where I HAD to learn the lower level stuff. Sorry I couldn't be much help.

Well, there is a write file command in the example I provided, but it's not one of the higher level ones like "Write Characters to File.vi". That function opens, writes to, and closes a file each time it's run. My example image illustrates opening a file, keeping it running while you want to write to it, and closing it when you're done. This method is faster and uses less redundant actions that will take up processor time. You could use the "Write Characters to File.vi" if processing time and speed are not an issue. At what time iterations are you wanting to log data? I'm getting kind of lost as to what exactly you're wanting to do.

I've saved data on NT machines in CSV format before and never had a problem. Windows 2000 is NT based, so I don't understand why it would do it for one and not the other. Now, the file system structure might be different. Did you put your path for your new file in a constant in your diagram, or are you prompting for it, or specifying it at run time? Would you be able to provide a screen shot of your code so that we can look at it for you?

What I always used to do was to store my collected data in a 2D array (if there wasn't a LOT of it) and then use the "array to spreadsheet string" function to convert it to a string and then write it to a file. If it's tab delimited, you can call it a ".xls" file and Excel will open it, or call it txt, etc. I've attached an example using a "Get Date/Time String" and 3 random number generators stored into a 1D array to kind of give you an example. I hope it helps. If you're collecting data faster than once per second, you might want to use the "Get date/time in seconds" function and format it to your liking. That function will give you a timestamp with millesecond precision. Edit: I noticed you're running LabVIEW 7.0, so I included a vi for you. The difference between the vi and the image, I included an indicator for loop iterations, and removed the file path constant, so it will prompt you to save it somewhere. Hope it helps!

What function(s) are you using for writing the data to file? If you're using one of the high-level VIs such as "Write Characters to File.vi", that VI opens, writes and closes the file every time you run it. If you're continually saving data in a loop, it's inefficient and unnecessary to keep opening and closing the same file that you're writing to in every iteration. A better way to do it is to use the more advanced file functions. Use "Open/Create/Replace File.vi" to open/create a file refernce outside of your loop and then pass the file reference into the loop. Use the "Write File" function to write your data to the file reference inside the loop. Then after your loop, use the "Close Reference" function to close the file reference when your logging loop has finished running. Note: The Write File function doesn't actually write the data to the file immediately, but merely buffers it until (I believe) either the buffer gets full or you close the reference, you have to use the "Flush File" function to actually write your data to the file, but it may add time to your iterations. I haven't tried it personally, but maybe you can use the "Flush File" VI in a parallel loop to actually write the data to the file reference at timed intervals?

There aren't any text commands in labview for setting control properties. If you right click on a control, and select CREATE >> PROPERTY NODE. You can use the property node to change any property of that control from visibility to value to color, etc. You'll have to "CHANGE ALL TO READ" to set property values. If you're using the property node in the same scope as your control terminal, you don't have to feed it a refnum. If it's in a different scope (i.e. a different subVI) then you will have to pass control reference from the desired control to the subroutine that will change the property. To create a control reference simply right click on the control, and CREATE >> REFERENCE. I've attached an image with both methods using flat sequence nodes just as an example and changing the value of the control. As I said before, there are many other control properties you can control with these methods as well.

Yes, with a state machine, you can keep coming back to your "timer case" so that you don't have to put multiple instances of the timer in between each piece of timed code.

It could be possible if he's using locals or property nodes, that he's resetting the values before his processes have completed execution, so they're reset while they're being written to, but not at the end. I would say to check your execution, ensure that you're resetting the values AFTER your processes have completed. Like I said, it would probably be easy to figure out if we could see the code itself.

Can you provide an image or example of your code for us to see? I have a couple of ideas of what you're doing in my head, but don't know which one you're using.

You 'picky bastard'. I actually don't use notifiers much and normally do the same, stop loops by destroying the reference, but for something I put together quickly for an example I just did it that way. In my actual programming I would have done it much better.

Hello! I think I have an idea about what you're asking, I'll give it a shot and hopefully it's what you're looking for. 1. You are creating a VI that will start a test process and return the results. 2. You are creating a VI used solely for interface functions (display and control). You have to be careful with globals sometimes when it comes to reading and writing to them from different (simultaneous) processes. Globals can become hard to keep track of if you use them liberally. If you have a scenario where you get 2 processes writing to the same global at the same time, you'll end up with a race condition and the value of the global will not be reliable. If you're exclusively reading from a global in one process, and writing to it in the other, then you should be okay. As far as telling the test process to "go", you can use occurrences for that, and then have the process update the global values which you can then read from your user interface routine. If you haven't used occurrences before, check in the 'Examples' provided with LabVIEW 6, they should give you a good idea on how they work. Using queues is another good method for communication between running parallel VIs, but gets a little more involved if you're not familiar with their use. If you need any further clarification, or maybe an example, just let me know. EDIT: I had updated an example LLB, but remembered that you're using 6.0 (I'm using 7 Express). Here's a screen capture of an example I put together for you. I hope it helps. It shows multi-loop control using notifiers. The red sequence node represents your "process" VI and the bottom while loop represents your interface update routine.

If nobody can answer that, can someone at least tell me if and how I can set the sampling rate on this PXI-6509?