Rolf Kalbermatter

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

So I guess the ability to add code to custom controls isn't a huge distance away.

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

One thing Michaels' code allows to do is to be able to add the capability to define file patterns.

If you pass anything but *.* or leave unwired you will not get back any Folder names.

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.

      Temperature (MSB)      19

      Temperature (LSB)          20

      "numbers relate to the byte number in the packet"

these are raw data and if i want to convert them I've to do some operations on them.

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