Jump to content

eaolson

Members
  • Posts

    261
  • Joined

  • Last visited

Everything posted by eaolson

  1. 897 downloads

    Copyright © 2007, <Eric Olson> All rights reserved. Author: Eric Olson --see readme file for contact information Description: Handles ID3v1 and v1.1 tags from MP3 files. Tags can be read, written, and deleted from files. This package does not handle the more complicated ID3v2 tags. Dependencies: Requires oglib_file and oglib_error available from www.openg.org. Change Log: 1.0.0: Initial release of the code. 1.0.1: Added Validate ISO 8859-1 String to distribution zip file.
  2. Name: MP3 ID3v1 Tags Submitter: LAVA 1.0 Content Submitted: 03 Jul 2009 Category: Database & File IO LabVIEW Version: 8.2 Version: 1.0.1 License Type: Creative Commons Attribution 3.0 Potentially make this available on the VI Package Network?: Undecided Copyright © 2007, <Eric Olson> All rights reserved. Author: Eric Olson --see readme file for contact information Description: Handles ID3v1 and v1.1 tags from MP3 files. Tags can be read, written, and deleted from files. This package does not handle the more complicated ID3v2 tags. Dependencies: Requires oglib_file and oglib_error available from www.openg.org. Change Log: 1.0.0: Initial release of the code. 1.0.1: Added Validate ISO 8859-1 String to distribution zip file. Click here to download this file
  3. eaolson

    Game of Life

    1,262 downloads

    Author: Eric Olson --see readme file for email address Description: Conway's Game of Life is a fun little simulation of a group of cells. How new cells are born and how old cells die is decided by a simple set of rules, but can lead to complicated behavior by the entire colony. I've always found this simulation to be interesting and I thought coding it in LabVIEW would be a fun exercise. Comments and critiques of either the game or of my coding style are always welcome. The basic rules are simple: 1. A cell that has one or zero neighbors dies of lonliness. 2. A cell that has four or more neighbors dies of overcrowding. 3. An empty cell that has exactly three neighbors containes a new cell in the following generation. A thorough explanation of the Game can be found at http://web.archive.o...7s_game_of_life . Dependancies: This uses the OpenG time, file, and variantconfig libraries. They are not included. Download them via the OpenG Package Manager: http://web.archive.o...p?showtopic=233 Change Log: 1.0.0: Initial release of the code. 1.0.1: Include readme.txt in the zip file. 1.1.0: Added Open and Save As functions (in the menubar). Added an About dialog. Removed the Exit button (redundant to Close). 1.1.1: Forgot to include the .rtm file in the distribution. Rows/columns now update when opening a .gol file.
  4. File Name: Game of Life File Submitter: LAVA 1.0 Content File Submitted: 02 Jul 2009 File Updated: 02 Jul 2009 File Category: General LabVIEW Version: 7.1 File Version: 1.1.1 License Type: Creative Commons Attribution-Share Alike 3.0 Potentially make this file available on the VI Package Network?: Undecided Author: Eric Olson --see readme file for email address Description: Conway's Game of Life is a fun little simulation of a group of cells. How new cells are born and how old cells die is decided by a simple set of rules, but can lead to complicated behavior by the entire colony. I've always found this simulation to be interesting and I thought coding it in LabVIEW would be a fun exercise. Comments and critiques of either the game or of my coding style are always welcome. The basic rules are simple: 1. A cell that has one or zero neighbors dies of lonliness. 2. A cell that has four or more neighbors dies of overcrowding. 3. An empty cell that has exactly three neighbors containes a new cell in the following generation. A thorough explanation of the Game can be found at http://web.archive.o...7s_game_of_life . Dependancies: This uses the OpenG time, file, and variantconfig libraries. They are not included. Download them via the OpenG Package Manager: http://web.archive.o...p?showtopic=233 Change Log: 1.0.0: Initial release of the code. 1.0.1: Include readme.txt in the zip file. 1.1.0: Added Open and Save As functions (in the menubar). Added an About dialog. Removed the Exit button (redundant to Close). 1.1.1: Forgot to include the .rtm file in the distribution. Rows/columns now update when opening a .gol file. Click here to download this file
  5. Version 1.0.0

    1,407 downloads

    Author: Eric Olson --see readme file for email address Description: This driver is an implementation of the Microsoft two-button mouse protocol, for using a serial mouse or trackball. It polls a specified serial port at a specified rate, and reads any data waiting there. This has been tested under LabVIEW versions 7.1.1, 8.0.1, and 8.20 under Windows 2000 and Windows XP, and under LabVIEW Real-Time 7.1.1 and 8.0.1. This driver contains components created using the dqGOOP toolkit to enable object-oriented programming. Note: When using a serial mouse under Windows, it is important that Windows not auto-detect the existence of the mouse (e.g. upon bootup). Otherwise, the operating system will intercept the mouse input and LabVIEW will never see it. Dependencies: None Version history: 1.0.0: Intial release of the code License: University of Illinois/NCSA Open Source License (view license.txt for complete verbiage).
  6. Name: Serial Mouse Driver for LabVIEW Submitter: eaolson Submitted: 01 Jul 2009 File Updated: 03 Jan 2011 Category: Hardware LabVIEW Version: 7.1 License Type: Other (included with download) Author: Eric Olson --see readme file for email address Description: This driver is an implementation of the Microsoft two-button mouse protocol, for using a serial mouse or trackball. It polls a specified serial port at a specified rate, and reads any data waiting there. This has been tested under LabVIEW versions 7.1.1, 8.0.1, and 8.20 under Windows 2000 and Windows XP, and under LabVIEW Real-Time 7.1.1 and 8.0.1. This driver contains components created using the dqGOOP toolkit to enable object-oriented programming. Note: When using a serial mouse under Windows, it is important that Windows not auto-detect the existence of the mouse (e.g. upon bootup). Otherwise, the operating system will intercept the mouse input and LabVIEW will never see it. Dependencies: None Version history: 1.0.0: Intial release of the code License: University of Illinois/NCSA Open Source License (view license.txt for complete verbiage). Click here to download this file
  7. QUOTE (lal @ Dec 12 2008, 02:27 PM) None of those are booleans. It's not quite clear what you're doing here. You can pass out all of the values from inside a loop by right-clicking on the tunnel, and selecting "Enable indexing." Then you'll have all the values and can do whatever you want with them.
  8. QUOTE (kaarthik_kaarthik @ Dec 12 2008, 12:19 AM) You should be able to open, edit, and save the html file like any other text file. Read it in as a string, find the flashVars/volumeLevel variable and change it, then write it back to the file. It would then be the responsibility of the browser or of Flash to notice that the file had changed and to adjust the volume level accordingly.
  9. QUOTE (neB @ Oct 2 2008, 07:43 AM) I've only ever found and reported a couple of LabVIEW bugs, but I do have to say the sheer variety in the number of places where they are posted is annoying. You've got the general NI forums, the NI bug forum, the LAVA bug thread, and who knows where else. Finding out if a bug is a known issue or not is actually fairly difficult and means searching in several different places. (Why on Earth, when you are reporting bugs, would you collect them by the month in which they were discovered?) Personally, I just with NI would have something publicly available like Bugzilla, but that's probably bad PR.
  10. eaolson

    Alfa String

    QUOTE (alfa @ Oct 1 2008, 02:07 AM) So it's kind of like Nevada?
  11. I've been fascinated by Stack Overflow lately. It's a neat way to get answers to any simple programming question you might have, or just to probe the opinion of a number of professionals. But the way the whole site works is unlike anything I've used before, too. It's like Usenet meets a wiki crossed with digg. There's not a lot of LabVIEW content there at the moment, however.
  12. I've got a typedef tab control, and when I open the VI, the contents of the first page are displayed in the control, even though the first page is not the active tab. I've attached an example VI. When test tab.vi is opened, you'll notice the String page is active, but the Boolean control is visible. This persists even when the VI is run. Switching pages makes the correct controls display. This only seems to happen when the tab control is a typedef, but I haven't done any thorough testing. Already reported to NI, CAR #127705. Crossposted from the dark side.
  13. QUOTE (ASTDan @ Sep 18 2008, 01:06 PM) I read his Style Guide a while back, but forgot he mentioned this sort of thing. That's a very thorough file template. There's also a good Project Specification template at the same location.
  14. QUOTE (Shaun Hayward @ Sep 19 2008, 04:43 PM) Why not? You could always just create a branch of the first project for the second project. Or, you could also export a copy of the first project and use that as the starting point for your second.
  15. QUOTE (crelf @ Sep 19 2008, 12:03 PM) I think there's a lot to be said for (a) organization and (b) consistency. One of the advantages of style guides is that they push you to doing both. E. g., there's no particular reason for OpenG to use that particular shade of green for its VIs, but it's a lot nicer than if those palettes were a rainbow of different colors.
  16. eaolson

    Alfa String

    QUOTE (rolfk @ Sep 19 2008, 05:14 AM) Wasn't this the exact premise of a Monty Python sketch? Oh my god, alfa is really John Cleese!
  17. I'm always looking for better ways to organize my work and other tips that can make me more productive. So the other day I was wondering how people organize their different LabVIEW projects. I'm a lone developer, so my stuff is probably on the small scale side of things. Lately, every project I've been working on gets its own folder, everything is Subversion controlled, and I'm trying to standardize on how I organize the subfolders: the project root directory gets an overall .lvproj file and the top-level VI, along with any INI file that will be loaded subVIs - all subVIs under the top-level VI go here. If the number of files becomes large, it gets divided further by category. typedefs - for typedefs used by the subVIs controls - for custom GUI components docs - non-LabVIEW documentation for the VI HardwareDriver1, etc. - reusable components like hardware drivers are separate projects and are checked into their own directory using svn-externals build - (unversioned) EXE builds and installers get generated into this directory. For some reason, LabVIEW seems to want to build into the parent of the project by default, which seems confusing to me. Components that I know are going to be used by other projects get handled similarly, but there's a "Hardware Driver Class" subfolder that holds the reusable part. That way I don't have to check out the .lvproj file and the test suite in projects that use the driver. (Note: I discovered too late that there's an annoying limitation to Subversion that you can't check out files into a directory that has a space in it.) So I was wondering how everyone else handles project organization. I know Package Manager has recently undergone some updates that might handle some of this for me, but I haven't had a chance to look at it much and, frankly, I just don't need another tool.
  18. eaolson

    Alfa String

    QUOTE (alfa @ Sep 15 2008, 01:57 AM) Yes, because you're applying it to a situation where it does not apply. You can throw around sciencey sounding words like "wave function" and "strings" but that doesn't mean you're doing science. Just because you can write an equation with Greek letters in it doesn't mean it's science. Wave functions don't apply because people aren't waves. They don't diffract, interfere, have phase or group velocity. QUOTE … because they looking for your money! Says the guy selling the books.
  19. QUOTE (pallen @ Sep 11 2008, 01:50 PM) Works for me. Could you maybe post your example? Have you tried turning on Highlight Execution and watch what's going on? I also just wanted to say I don't think this is a particularly good approach. If (Req - Output) is not an exact multiple of Rate, you're in trouble. What happens if Output = 0, Req = 5, and Rate = 2? You'll get an oscillation.
  20. QUOTE (sukhiray @ Sep 10 2008, 11:42 PM) Why not? It sounds like you already have X(t). So multiply that by your constant A, display it, and save it. Other than that, it's not really clear what your problem is and you haven't shown us what you've already tried.
  21. QUOTE (jdunham @ Sep 9 2008, 12:58 PM) I have to agree. Adding error handling to every VI whether it needs it or not is unnecessary and overly-complicated. Adding unnecessary error handling inputs/outputs is syntactically equivalent to just putting everything inside a sequence structure. It's just that it looks tidier because the icon is smaller than the structure.
  22. It would be nice to have Focus Gained and Focus Lost events for front panel objects. I was writing a simple application with a string control that I wanted to always have focus, so the user could just type and not have to worry about whether the cursor was actually in the string control. It's easy enough to give the control focus with the KeyFocus property, but if the user interacts with another control (e.g. a button) the string loses focus. In my event structures, I have to create dummy ValueChanged events in case the user interacts with a control.
  23. QUOTE (Daklu @ Sep 4 2008, 02:18 PM) Think of it as a reference to a different repository. So when I check out BigProject, it sees a reference to LittleComponent v1.0, and checks out a copy of that, too. It's nice because it means the BigProject repository just needs a reference to LittleComponent, and so it doesn't actually contain duplicate copies of the LittleComponent files. And because I specify a particular version of LittleComponent, if I check out a copy of BigProject a year from now, after LittleComponent has gone to version 2.0, SVN will check out the version of LittleComponent I know is compatible.
  24. QUOTE (Daklu @ Sep 3 2008, 11:28 AM) I was doing something similar lately (though I was using directories tagged with the version number, not individual files) and it's not a good solution. It doesn't scale well and changing versions is a nuisance. What I've been doing lately* is making sure I get some reusable component into decent shape (adequately tested, debugged, etc.) then tag it in SVN with some unique tag name. Then when I have a project that needs to use that component, that tagged version of the component gets checked out into the project's directory using svn-externals. This means that future revisions to the component do not affect the project, since I've checked out a particular version of the component. * Note: I'm a single developer, am still working the details out, and may not know what I'm doing. Use at your own risk.
  25. QUOTE (ASTDan @ Aug 21 2008, 11:27 AM) It's been a while since this was originally, but what immediately comes to mind is taking the http://en.wikipedia.org/wiki/HSL_and_HSV' rel='nofollow' target="_blank">HSV color representation, picking N equally-spaced values for H, and keeping S and V at 100%. This should work for any N. Then convert to RGB for LabVIEW. They may not be the most aesthetically pleasing colors, but they would be guaranteed to be distinct. Is there an HSV-to-RGB converter out there for LabVIEW? If not, it should be pretty easy to create.
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.