Bryan

You can use a property node for a VI class and select the "Front Panel Window >> State". I don't remember, but I think LV6.1 has this function.

Nice trollish first post. :thumbdown: If you're using LV7, and it's crashing, it sounds to me like poor or inefficient programming style may be to blame which may have lead a memory leak or massive use of memory somewhere (i.e. unknowingly building massive arrays inside of a loop). I've been using LabVIEW for 5 years, and the only version I've ever used that sometimes crashed was LV5.1 when running NT4.0. I would suggest that you either take a look at your own programming ability/style, maybe read up a little on LabVIEW and look at what you yourself could have done wrong before pointing the blame at someone else. Who was it that had in their signature something to the nature of: "Software Development is a race between software developers creating more idiot-proof programs, and the universe creating more idiots"?

By what delimitation are you trying to split the string? Are you trying to break it up into pieces by finding spaces, commas, etc? If you're trying to do the above, you can use the "Spreadsheet to Array" function which will provide an array of each "piece" of your string that's separated by a character (i.e. comma, space, tab, etc). Or use the "Scan from String" function.

Has anybody programmatically changed a computer's IP Address using LabVIEW? I'm in a situation where I will have a LabVIEW App running on a computer having a few ethernet adapters. What I would like to do is somehow identify the adapters and programmatically set the ip addresses and subnet masks of each adapter and apply the settings without having to reboot. Sort of like how you can change the IP and implement the changes manually by viewing local area connection properties. Extra tidbit of info: we're going to be using W2k/XP machines. I'm thinking it's probably going to be a register-level implementation, which we would like to try to avoid. If anybody is able to at least point me in the general direction, I would greatly appreciate it.

Remember, aside from the application that YOU built, the installer creates files that actually perform and install your application and parts/shortcuts/etc onto the target computer(s). I'm not an installer guru by any means, so I don't know how much it SHOULD take up, but the idea that your built application + installer is larger than your application alone just makes sense to me.

You can create them with Adobe Imageready too, but the Adobe packages cost mucho dinero. You could also do a search on shareware or on sourceforge for something like that. That's normally how I find things anymore.

... I'm working on MY LAVA shirt...

Congratulations!

After your talk about backdoors and easter eggs, I thought you had read that book because they're mentioned in there. I had done a very simple one that popped up a comical error message when a particular user logged in. Back at the time I didn't know they were called "easter eggs" until I read that book.

I would definitely check with your management as far as easter eggs are concerned. If it's something that would contribute to the use of system resources, you might want to rethink it. Back doors, depending on what type of software you're running can be a good things often times for support and troubleshooting. I've done easter eggs in the past on applications that stay in-house. I have yet to create a back door in anything I've written. You just got done reading Digital Fortress didn't you? yaorouseveethncs wecgewhyaaiortnu (<-- If you read the book, you'll get that)

Application builder has provisions for using a custom icon file (*.ico) for your built EXEs. To build these "*.ico" files, one would have to have a program capable of providing such files. It would be neat to have Application builder automatically use the top level VI's icon as the icon for the exe, OR have a utility built into LabVIEW that allows you to create your own custom EXE icon.

I believe you should be using a property node to set the control value. It sounds to me like you're not passing the correct (if any) control reference to the node, or you don't have it linked to the desired control. You can get a control reference by right-clicking on a control, and going to CREATE >> REFERENCE. Then using that reference with a property node to set/get control values. Additionally, you can right click and CREATE >> PROPERTY NODE which essentially creates one that's already linked to the control reference. The only way I see you needing to use the first method is if you're passing the control reference to a subroutine.

http://forums.lavausergroup.org/index.php?showtopic=605

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.