Rolf Kalbermatter

Excluding very old LabVIEW versions, you can assume that the first 16 bytes of a VI are always the same. In fact any LabVIEW resource file has the same 16 byte structure with 4 out of those 16 bytes identifying the type of file. 52 53 52 43 RSRC 0D 0A 00 03 <version number> ; this value since about LabVIEW 3 4C 56 49 4E LVIN or LVCC/LVAR 4C 42 56 57 LBVW Anybody recognizing some resemplance with the Macintosh file type resource here ;-)

Or you could simply specify a range. Works for strings too! "HELLO ".."HELLO!"

Callbacks in LabVIEW itself are, although possible since 7.0, indeed an anachronisme. But there are situations where it would probably make sense to use them. Callbacks in low level drivers are an entirely different issue. They are one way to allow an application to use asynchronous operations in a way without having to rely on interrupts or such things, which in modern OSes are out of reach of user applications anyhow. For cooperative multitasking systems this is basically the only way to do asynchronous operations without directly using interrupts or loading the CPU with lots of polling. Another possibility to handle asynchronous operations on multtasking/multithreading systems is to use events. LabVIEW occurrences are in fact just that. Eventhough LabVIEW wasn't a from begin on a real multithreading system, for the purpose of its internal diagram scheduling it came as close as it could get to real multithreading. Asynchronous operations are indeed inherently more difficult to understand and handle correctly in most cases. Especially in LabVIEWs dataflow world they seem to sometimes mess up the clear and proper architecture of a dataflow driven system. But they can make a big difference between a slow and sluggish execution where each operation has to wait for the previous to finish and a fast system where multiple things seem to happen simultanously while a driver waits for data to arrive. With the more an more inherent real multithreading in LabVIEW this has become less important but in my view it is a very good and efficient idea to use asynchronous operations of low level drivers if they are avaialalbe. They way I usually end up doing that in the past is translating the low level callback or system event into a LabVIEW occurrence in the intermediate CIN or shared library. Of course such VI drivers are not always very simple to use and synchronous operations should be provided for the not so demanding average user. They can even be based on the low level asynchronous interface functions if done right. But as long as you stay on LabVIEW diagram level only, callback approaches seem to me in most cases a complication of the design which is not necessary. As you have properly pointed out, having a separate loop in a LabVIEW diagram handling such long lasting operations is almost always enough. That is not to say that Jims solution is bad. He is in fact using this feature not strictly as a callback but more like a startup of seperate deamons for the multiple instances of the same task, a technique very common in the Unix world. In that respect it is a very neat solution of a problem not easily solvable in other ways in LabVIEW.

Basically during development directories are a lot better. For distribution llbs may be handy. Library structure Pros > * Unused files are automatically removed from library at save time. This is not true. You have to load the top VI and selecte Save with Options to create a new directory structure or library which only contains the currently used VIs. This is the same for LLbs and directories. > * Upgrading your software to newer LV versions is easy because libraries can hold all the device drivers as well I think you talk about instrument drivers. Keeping them in a subdirectory to your project dir would achieve the same. * Moderate compression of maybe 10 - 30 %. Nothing really to write home about.With harddisks costing dollars per GB and the fact that decompressing will also take performance everytime LabVIEW needs to load the VI into memory. For archiving purposes it is a good idea to ZIP up the entire source code tree anyhow. Cons > * Returning the files to directories can't be done, or at least I don't know how. Wrong as pointed out. > * Referencing a file inside the library might be possible, is it? I think not. With VI server for sure. If you talk about accessing in in Explorer this is possible too. LabVIEW 7 and later has a feature in Options which installs a shell extension which allows you to browse LLB files (and see the VI icons of any LabVIEW file in the Explorer) > * If naming is not done correctly, it can be a drag to find a certain file from large library. Again with above shell extension (assuming you use Windows ;-) this problem is eased upon. * Source code control won't work easily. Directory structure Pros > * Easy to group logical set of files to different directories Yes! > * With dynamic calls, run time editing is possible No difference to LLBs. You just have to consider that LLBs are handled by LabVIEW like an additional directory level with the LLB name as directory name. * Source code control is much more effectively possible Cons > * Upgrading LV version changes device drivers to new version also. They may but more probably may not work. No difference to when using LLBs. You will need to keep the instrument drivers together with your project for that to work, but that is also what is happening when they are copied inside the LLB. LabVIEW has also no preference to use VIs in an LLB instead of in a directory. It simply will try to load the VI from where it was last located when the calling VI was saved and if not found will start to search its standard paths indifferent if they are in LLBs or not.

As long as it is about retrieving version information for executables and dlls you should try to look for the GetFileVersionInfo() and VerQueryValue() functions. Not really sure if they are in user32.dll. MSDN says they are provided by version.lib which would usually mean there should be a version.dll somewhere. Changing this information on existing files is a VERY bad idea as it will screw up installers which you might try to use to upgrade or uninstall existing applications. Accessing property pages of other Explorer namespace objects is very difficult to do without COM (the base of OLE) object handling.

I have meant to try to get something done but never got around it. And yes you can't do without DLL or CIN. Georgo Zou has however in his Toolkit functions to just do that. Rolf Kalbermatter

Another idea might be to use sub panels for this. Create the control as a subVI with all the code you might feel necessary and allow some sort of communication to the main VI for instance through user registered events or queues. Then whenever you need the control insert it with a simple call into a sub panel control. Rolf Kalbermatter

Well that is not entirely true. It's only true because you usually don't have folders with endings but if you name your folders for instance Folder.dir a search pattern of *.dir will return those folders. Of course I agree with you that looking for particular file patterns is a nice feature and I thought the OpenG version does that also. The problem with this is the requirement of the two List Directory Nodes for each hierarchy level which will almost take double the time than one node does. I think with preallocating the arrays and such one can win another few percent but the real time spent is in the List Directory node.

And I'm positive that they actually use some cryptographic algorithme such as MD5 or similar to protect the password so trying to fake the password is a rather difficult if not useless approach. The only way I could see is in patching the LabVIEW executable bij removing the password check altogether. But that is beyond my abilities.

Your approach will work too, but since your data is really a 16 byte short in big endian format you could take advantage of the fact that LabVIEW's flattened stream format is also normalized to be in big endian. Just pick out the interesting bytes and wire them to the Type Cast function in Advanced->Data Manipulation. Wire a int16 constant to the middle terminal e voila you get your numeric 16 bit signed value. This is simple fast and will work on any LabVIEW platform independant of the underlying endianess of the CPU, since LabVIEW takes care of the necessary (if necessary) byte swapping for you. If the number in the stream would be in little endian format you would just have to add a Byte Swap node from the same palette to the wire after the Type Cast. Really swaps bytes twice on little endian machines (only Intel CPUs ;-) but it's most probably still faster than doing the byte extraction and joining on your own.

Hi Michael I just took a look at your List Directory and thought there would be something to improve. Look at the attached version. On my computer it is almost two times faster in enumerating large directory trees even if it is called first in the timing test to not give it advantage through Windows directory list caching. Download File:post-10-1081496463.vi