eaolson

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

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

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

QUOTE (lal @ Dec 12 2008, 02:27 PM)

As i said on my last post i would like the states changes automatically.I convert the boolean states to integer.

My states are 10000, 1000, 100, 10...So my values are 16, 8, 4, 2.

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.

QUOTE (kaarthik_kaarthik @ Dec 12 2008, 12:19 AM)

thanks for the prompt reply,i have a HTML file which i will be opening in LabVIEW.I have attached the HTML file here.There is a property/variable called as flashvars,which i want to access and change the volume level value.Which in turn will be accessed by flash player and display it in the web browser.

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.

QUOTE (neB @ Oct 2 2008, 07:43 AM)

How do we close the loop and get the original thread here on LAVA to reflect the NI follow-up?

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.

QUOTE (alfa @ Oct 1 2008, 02:07 AM)

Everywhere here in Romania you see only animals, prostitutes...

So it's kind of like Nevada?

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.

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.

QUOTE (ASTDan @ Sep 18 2008, 01:06 PM)

Peter Bloom of bloomy controls has a file template that is a very good starting point for project organization. I think he also talks about this in the LabVIEW style guide.

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.

QUOTE (Shaun Hayward @ Sep 19 2008, 04:43 PM)

yeah, its hard to find out what would be the best as I think in reality they all could work, although we have decided that the ability to a customers earlier project to form the basis of a new project is too valuable to have 1 repo per project.

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.

QUOTE (crelf @ Sep 19 2008, 12:03 PM)

Style is, to a certain degree, subjective - by definition there can't be a definative test, and that's why most people describe such books as "style guides".

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.

QUOTE (rolfk @ Sep 19 2008, 05:14 AM)

Assassinated by a georgious half naked woman? Sounds almost like the ideal way to go from this physical world! Definitly much better than dieing from cancer.

Wasn't this the exact premise of a Monty Python sketch? Oh my god, alfa is really John Cleese!

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.

QUOTE (alfa @ Sep 15 2008, 01:57 AM)

What is not scientific here? My wave function?

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

Says the guy selling the books.

QUOTE (pallen @ Sep 11 2008, 01:50 PM)

Can anyone tell me what's going on here?

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.

QUOTE (sukhiray @ Sep 10 2008, 11:42 PM)

After plotting with modified X axis, I could not able to take any output from graph to write it in Excel file.

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.

QUOTE (jdunham @ Sep 9 2008, 12:58 PM)

Error handling is great, and we use it just about everywhere, especially if there is any I/O or any chance for invalid arithmetic results. But if the routine does not have any need for error handling, then I think it is counterproductive to add it.

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.

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.

QUOTE (Daklu @ Sep 4 2008, 02:18 PM)

We don't use svn so I'm not familiar with the terminology. What are svn-externals?

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.

QUOTE (Daklu @ Sep 3 2008, 11:28 AM)

Are there better/easier ways to deal with module versioning?

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.

QUOTE (ASTDan @ Aug 21 2008, 11:27 AM)

I need an algorithim that can give me 32 different colors to plot in the waveform graph (Current graph only gives you 8 by default). I could set this up manualy but I was hoping for a more elegant solution.

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.

When I saw the subject for this thread, what briefly popped into my head was:

public class Cruise {    private List passengers;    private City departingFrom;    private City destination;    
    public void sendSos();
    public Person kingOfTheWorld();
}

Sigh.

QUOTE (Darren @ Aug 22 2008, 10:23 AM)

P.S. - In his defense, though, given the huge amount of initialization required in the 3-button dialog VI, I'm curious how others would design it that it would look so different. Is the issue purely one of modularization? Would y'all be happy if he simply used more subVIs? Because regardless of how it looks, there's no way around the fact that all that code does need to run before you get to the event structure...

I think that all that big mess o' code is a good example of one of LabVIEW's greatest weaknesses: it's hard to build a GUI. Yes, there are lots of great, feature-rich widgets, but it's really hard to put them together in a meaningful way. Compare with Java's http://en.wikipedia.org/wiki/Swing_%28Java%29' rel='nofollow' target="_blank">Swing, for example, then realize that Java is 40% younger than LabVIEW. A simple, four-element window just shouldn't have to build its own layout manager from scratch.

QUOTE (Michael_Aivaliotis @ Aug 21 2008, 02:51 PM)

Actually, I don't see the point in all that code before the exit. You are exiting. Hiding the panel makes no difference. Just put the exit and that's it. Simplify.

Nope, in fact I went back into that VI and added that code for a reason. It's in a fairly simple application I'm building that will be compiled to an executable. The top-level VI does not display the menu bar or the tool bar (and therefore, it doesn't display the VI icon, either). If you just use Exit, what happens when the VI stops is that (a) the VI stops, (b) the tool bar, menu bar, and icon are redisplayed, and ( c) then the VI window closes. That means that closing the VI or some programmatic closing of the VI causes the window to flicker and resize itself before it closes. I found that unattractive and possibly confusing. It also draws attention to the fact that this is a program written in LabVIEW. (Not inherently bad, just unecessary.)

So this version first hides the window from view, then closes it, and there is no flickering issue.