Phillip Brooks

Lets say you have a very large file that you want to verify (the LabVIEW 2011 image ) Before extracting and installing, you might want to verify the file. The time to generate the MD5 from the downloaded file may be significant. If you are going to compare the results of a time consuming operation with an invalid string, you will be wasting time (by re-downloading a file that may be good). It is not easy to visually read or count the characters of an MD5 checksum...

The RFC states that it must be lower case... http://www.ietf.org/rfc/rfc2831.txt Let HEX(n) be the representation of the 16 octet MD5 hash n as astring of 32 hex digits (with alphabetic characters always in lowercase, since MD5 is case sensitive).

There is a function in LabVIEW to generate a GUID. See this post. Maybe an OpenG wrapper VI to call this function?

Since you are waiting for your hardware, this would be a good time to think about your environment and how to trigger. Your environment sounds different than an automated assembly line with controlled lighting and a constant rate. The environment will define how you place your camera, your trigger(s) and possibly require lighting control (additional lighting or screening to prevent glare).

Just a quick observation. Does this design trade memory for speed? If so, would this function ever be used in a memory constrained environment such as RT or FieldPoint? It appears that two copies of the string data (as U8 arrays, one reversed) are created to iterate over. Is the LabVIEW compiler is smart enough to only use one buffer for the U8 array data? What does LabVIEW Profiler tell us about the buffer allocations? I don't have 2009 installed, so I can't play with the examples. If there are two buffer allocations for the U8 array data, would there any difference in performance if the 'end trim' loop were to use the same U8 array and simply index from the end of the array (N-i-1) until a hit was found?

Considering that my math skills are roughly those of a 5th grader, I wanted to know where it came from. This wikipedia entry has the history and some details... http://en.wikipedia.org/wiki/Hearing_the_shape_of_a_drum This begs the question, can I smell the color of a fruit?

Jim has a nice one; http://lavag.org/topic/14745-lava-gets-an-upgrade/page__view__findpost__p__88542 More LAVA, less blabla

Where the hottest LabVIEW ideas flow... lava, LabVIEW, (data)flow... get it? I got nothin'...

Only foolin'. But... The DisplayLInk drivers for iPad work as advertised. You can use your iPad as an extended display under Windows... Set the iPad screen as my primary to move the Window toolbar to the iPad... http://itunes.apple....d411678720?mt=8 Install the PC client, and also install the app from iTunes (currently free!)

It was still showing LV 2010 when I posted this morning. The pages must be slowly rolling over to 2011 versions.

http://zone.ni.com/w...doc/p/id/wv-157

You know, I used to get all excited when the latest version came out; but lately I feel more like "The new phonebook is here! The new phonebook is here!" Its bigger, heavier and changed just enough that I can't find what I'm looking for. Still using 8.6 here, and from some of my friend's experiences with LV and TS 2010; I think I'll stay where I'm at for now. Guess I just got up on the wrong side of the bed today...

I think the device responding properly is a function of sending navigation keystrokes while the device is updating the output. Like I said, the LV library is dodgy at best. As for the device, it is ours, it is old and the chances of getting a CLI are < zero. I might spend some time thinking about a LVOOP solution (still haven't deployed any LVOOP, just experimenting), but it is summer time and the weather is too nice to worry about such things...

I'm looking at two devices that I need to interface with from LabVIEW that have no command line control. They both use a interface that is RS232 based. The menus require a VT-100 terminal type and use a fair amount of cursoring (goto x-y and write text with this color and bkgrnd color) and highlighting to show the current location. I have some legacy code that I don't care for much that polls the com port and strips all the VT-100 control codes out. It works, but the device doesn't respond 100% of the time to control codes (send arrow up or arrow down). If the LabVIEW com library I'm using gets stuck or lost, it has to navigate back to a known position and then navigate the menus again to ensure that the instruction given is correct. Sort of a dead reckoning problem; sometimes its easier to reset the device than to figure out the current location in the menu hierarchy. I can just suffer with this library, but I would like to automate some new tests. If there is an existing LabVIEW library, architecture or technique I can use, I would likely pick that over this existing steaming library of... Anybody?

It isn't documented, but I think the implementation is a red/black tree to allow for fast searches. This requires the list to be rebalanced (resorted) whenever an item is added, so it is stored sorted (by attribute name). If the function returns a list of items when the name is left blank, it makes sense that the list would always be returned sorted. NI could certainly change this behavior, but I'd bet that this would break a bunch of NI code. See the dark side: Darren's Weekly Nugget 10/09/2006 http://forums.ni.com/t5/LabVIEW/Darren-s-Weekly-Nugget-10-09-2006/td-p/425269

Another great place for getting connection string info: http://connectionstrings.com/ For dBASE examples; http://connectionstrings.com/dbf-foxpro

I recently read about planking, then the Thai version called pubpeab, and now I think that we need a LabVIEW version.