Phillip Brooks

Note: Uses vi.lib\analysis\1siggen.llb\Ramp Pattern.vi (Full Development System required)

I see that there has been a ?!@*-ton of spam on the OpenG General Discussion forum this weekend. Just a thought; maybe the discussion forums could be moved to LAVA? It might provoke a bit more involvement in OpenG in general and the more robust forum software would stop the spammage (is spammage a word?)

I'd offer you my tinfoil hat, but then I'd be exposed to the radiation falling from that missile launch on the west coast last week.

Plugged the USB receiver into the back of the Wii last night (on a whim) and it worked reasonably well! Now I need to find a micro-USB to USB socket adapter to try plugging it into the new Apple TV 2.0.

Buzz kill?! It appears the whole thing is dead... we've decided to remove the LabVIEW Add-ons Idea Exchange and merge the ideas posted there into the LabVIEW Idea Exchange.

Thanks, that makes sense. Now I officially have 500 posts

I had 502, now I have 498. I'm still a member of the 500 Club. One more post and my conscience will be clear... This post shows 503, now I need to check my profile... EDIT 499 in my profile. where did the other posts come from (or go?)

Why not store the files on a common server? \\servername\AppName\StationName1\Datafile1.dat \\servername\AppName\StationName1\Datafile2.dat \\servername\AppName\StationName2\Datafile1.dat \\servername\AppName\StationName2\Datafile2.dat The files can be backed up by IT, and access is defined by network, not local account names and shares. Local networking shares with read/write access is one of the most common methods that viruses (virii?) spread...

I think most databases are going to offer the same core functionality. The most important thing is to identify your data relationships and minimizing duplicate data. When we designed our database long ago, we started by using "Database Design for Mere Mortals" by Michael Hernandez. I see that there is a new edition, I don't know what has changed. I still browse through the old edition once in a while when I question what I'm doing. If you get your database design right and use the Database Connectivity Toolkit, it shouldn't matter which DB you end up using.

Funny, I just recently posted a vi (on the dark side) that I wrote awhile back to remove HTML tags from TestStand HTML reports. Maybe it will help you. There are some other regex nuggets in the thread... http://forums.ni.com/t5/BreakPoint/Regular-Expressions-Board/m-p/1269088#M14343

You might consider using the function "Check if File or Folder Exists" instead. The path may not be empty, but that doesn't mean the file exists. Use the file or folder exists? output to control your case statement and use the dup path for the read file function.

I commented on an idea located here. What I added to the idea was that Probes should have a Probe Manager window that allows the user to record a timestamp for selected probes. The advantage would be that you could measure time across VIs as well as within, without creating sequence structures. If you like the idea, vote it up, point me to a duplicate or help define the idea better. I just like the concept and want to see the probes improved a bit...

If you have a valid connection reference, use the DB Toolkit vi located at: vi.lib\addons\database\Auxilliary.llb\DB Tools Select All Data.vi This vi returns a 2D array of string that you can write to the ItemNames property of a MCL or the Values of a table control. If you have a recordset reference, you can use the sub-vi inside the one above called vi.lib\addons\database\Auxilliary.llb\DB Tools Fetch Table Data.vi No special coding or libraries required. You can use the VIs NI gives you (they are not on the palette though )

I recall that the Agilent GPIB interfaces need an extra piece of code / dll to be used from LabVIEW; I think it's referred to as a 'tulip' driver. I Googled and found some app notes on the Agilent site: http://www.home.agil...029&pageMode=AN Look at the document titled "Tips in Using Agilent GPIB Solutions in National Instrument’s LabVIEW Environment"

Completely unrelated, but would this microphone do?

There is a new LabVIEW SQLite library just recently made available in the uncertified section of the LAVA Code Repository. The requirements listed are Windows and LabVIEW 9.0, but I believe the author of the library included the possibility to use with other platforms such as RT. Try asking your question in that thread ... If you have the time or inclination, you may be able to help add Linux support!

RFC 1149 ( A Standard for the Transmission of IP Datagrams on Avian Carriers) had the idea 20 years ago, I just thought it was time we had a new way to pass data in LabVIEW...

I discovered the addition of this new area at the bottom of this HDF5 Idea Exchange entry. From the new Idea Exchange page: The LabVIEW Add-ons (VIs and tools) Idea Exchange allows you to submit ideas for new LabVIEW Add-ons. These Add-ons can range from a set of VIs and functions to development tools for particular application areas and industries. It is also a place for LabVIEW Add-on developers to find new and valuable product ideas. The ideas on submitted on this page have the potential to become LabVIEW Add-ons. Do you have an idea for a LabVIEW Add-on? Browse by label or search in the LabVIEW Add-ons Idea Exchange to see if your idea has previously been submitted. If your idea exists be sure to vote for the idea by giving it kudos to indicate your approval! If your idea has not been submitted click Post New Idea to submit your idea. Be sure to submit a separate post for each idea. Watch as the community gives your idea kudos and adds their input. If an Add-on developer begins to implement an idea, we will update the status of the idea. Give kudos to other ideas that you would like to see made into a LabVIEW Add-on.

Are you averse to any polling, or just polling in your top level (UI?). Maybe define a 'monitor' task that is run at start and receives an event ref and notifier. Pass your task VI instances via the notifier (or queue or functional global or carrier pigeon) to the 'monitor'. The monitor would periodically evaluate the array of task VI refs by checking the Execution.State property of each ref; generate an event for each vi that is not 'Run top level'. I smell an Idea Exchange suggestion in this problem...