Phillip Brooks

Add some sort of instrumentation I/O. One of LabVIEW's strengths is the large collection of instrument drivers for acquiring data.

............................................________ ....................................,.-'"...................``~., .............................,.-"..................................."-., .........................,/...............................................":, .....................,?......................................................\, .................../...........................................................,} ................./......................................................,:`^`..} .............../...................................................,:"........./ ..............?.....__.........................................:`.........../ ............./__.(....."~-,_..............................,:`........../ .........../(_...."~,_........"~,_....................,:`........_/ ..........{.._$;_......"=,_......."-,_.......,.-~-,},.~";/....} ...........((.....*~_......."=-._......";,,./`..../"............../ ...,,,___.\`~,......"~.,....................`.....}............../ ............(....`=-,,.......`........................(......;_,,-" ............/.`~,......`-...............................\....../\ .............\`~.*-,.....................................|,./.....\,__ ,,_..........}.>-._\...................................|..............`=~-, .....`=~-,_\_......`\,.................................\ ...................`=~-,,.\,...............................\ ................................`:,,...........................`\..............__ .....................................`=-,...................,%`>--==`` ........................................_\..........._,-%.......`\ ...................................,<`.._|_,-&``................`

There is an optional toolkit called DSC (Datalogging and Supervisory Control) that contains code and front panel objects for creating this type of display.

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...