Bryan

I'm doing TONS with Tcp/Ip right now, but I'm mostly passing binary strings in a protocol with header and checksum. You don't have to have LabVIEW on 2 machines to communicate via tcp/ip, but one machine needs to be set up as a server, and the other a client. Just so long as you have a program on each PC that can act as one or the other, and be able to connect to an IP address and port as well as have the ability to accept the strings it receives you should be able to. I have a LabVIEW program acting as a data acquisition host on a PXI chassis. Using TCP/IP, I can connect to that PXI chassis from any computer that can access it's IP and specified port. I've run LabVIEW as a host, Tcl as a client and vice versa as well as various combinations without problems. So, to answer your question, no, you don't have to have LabVIEW on both machines, BUT you have to have a program on your PC without labview that's able to connect to your PC with labview via ip and port and send/receive strings. I believe you could use hyper terminal for that, I think it's standard on most PCs, but I've never used it so I couldn't tell you what to do. EDIT: I just opened hyperterminal on my computer and tested it with my program here at work. You can create a new connection via TCP/IP, specify an IP and Port and it will run as a receiver, displaying the ascii representation of what it recieves, but I don't know how to send things back to it. It provides the ability to send/receive files and text files, but I don't know how it works. I couldn't do it with mine because my LabVIEW program communicates with our own proprietary in-house protocol, it will reject normal text sent to it.

Found my answer... Create an application property node, KIND >> Run Time System.

I'm sure there's a better way to do this, and I'm relatively new to Application Builder. I've noticed in my EXEs that when the top level VI completes execution, the VI stops and the run button, etc becomes visible, but the EXE doesn't close. I could add the "Application Exit" function to the program, but when I'm developing, I don't want it to completely exit when the VI completes execution. Is there a function or property (I haven't been able to find it, perhaps I"m not looking hard enough) that indicates whether the current VI is a VI or EXE? Currently, what I've been doing is parsing the top level VI for its filename extension and exiting only if it finds an EXE. It seems to me that there should be a better way to do this and I've just been missing it. Thanks guys!

Well, if the user double-clicks on a row, the selected value should be able to be accessed. To get the value on a double click, you'd have to have it recognize the double click as an event to generate the event, then just get the value they selected, not the double-click value. The row would be selected on the 1st click anyway... right? I might be missing something though. I haven't used double-clicking much.

I'm glad I could help! Just something to add. If you set a value of a control or indicator, right click on it and go to DATA OPERATIONS >> MAKE CURRENT VALUE DEFAULT and save your VI, it'll use that value as the default value when you use that function I showed you. So you don't always have to have, say, a numeric control reset to 0. You can also programmatically set the default value of controls by creating and using property nodes for the desired control. I hope I didn't tell you stuff you already know, but I just thought I'd add some extra stuff in that realm for you to ponder. Enjoy!

You can select an "Invoke Node" from the diagram palette under "Application Control". Right click on it and select "SELECT CLASS" >> "VI SERVER" >> "VI" for it's class. Then right click on it again and go to "METHODS" >> "REINITIALIZE ALL TO DEFAULT". That should do it for ya.

I know the feeling. LOL At my current and previous jobs, I was considered to be either THE or ONE OF THE resident "experts". I never considered myself to be, but, just like we've all experienced, if you're the one, or one of a few people that know a little about something, suddenly everybody thinks you're an expert.

So having an ini file is mandatory? Granted, as I've said, most of my applications have been used in VI form, but of the ones I have made into an EXE, I have never seen anything actually entered in that file. It always uses it regardless? There's no way to have it NOT generate one? When I get a chance, I'll look at the App Builder documentation. Right now I'm currently busy trying to figure out to create a Tcl Interpreter in LabVIEW, so believe me... I'm getting my fill of documentation. :headbang:

I've noticed that when an EXE is created, it generates an INI file with the same name as the EXE program. Now, does this INI file serve some sort of purpose? I don't write anything to it nor read anything from it, so it appears to me as a useless file, or does it store information after multiple uses? If it stores nothing, is there a way to have it NOT generate an ini file? Forgive me if this question has been asked before. Most of my labview experience has been in developing for applications where there isn't a need for an EXE version of the VIs.

I think I understand what you mean Todd, but I'm going to hit on breakpoint behavior in general as I understand it. From your tools palette, you can select a breakpoint tool. Judging by what you've said, I think you already know how to set them. To clear a breakpoint, you just click on the same wire/area/etc where you set the breakpoint and it will clear it. When a breakpoint is reached by the code, all it does is set the VI in debugging mode which pauses the VI and enables you to step through the execution of each component in your diagram. If you want to abort the current pause, just hit the pause ( II ) button up by your run buttons and it will let your VI finish, but it doesn't clear your breakpoint. Instead, the next time your VI is called, it will run until it hits the breakpoint again. To clear your breakpoint, click on it with the breakpoint tool from the tools palette. This can be done at runtime or when your VI isn't running. I think you were asking how to continue the vi again from it's currently paused breakpoint without having to manually step through every component to exit the routine...right?

I've just always been into cars, ever since I was a little kid. Taking a drive is relaxation to me, driving a car with power and/or handling is just plain fun at times (so long as you're safe and sensible with it). My chevelle was a father/son project that started when I was 15. 10 years later, I still have plans in the works for additional things to add, or things I can't afford at the moment (i.e. new engine). There are also a lot of other vehicles I'd like to have as projects. Primarily older ones. For some reaosn, taking something old and neglected and fixing it up new just seems so rewarding upon completion and enjoyable in-process. Especially when you have someone working on it with you. That's why I like working on cars and doing home improvements, etc. Working on cars is also theraputic for me, even if it's not my own. It always has been for some reason. I've done work on friends' vehicles and only charge money for parts and ask for something to drink and possibly something to eat when I'm done.

When I worked at Corning Inc., I used it for automating passive and active measurement and calibration processes for free space and fiber optic devices... mostly controlling GPIB and RS232 instrumentation and collecting data (I then used VBA macros I wrote for Excel to format that same data). I've also used LabVIEW for machine vision and data acquisition. Currently, I'm using it for input simulation and output montioring for embedded software verification.

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!