Leaderboard

(crossposted to NI Forums) I'm seeing a behavior where LabVIEW's List Folder primitive returns incorrect results for a folder on a mapped network drive, if the folder contains a file whose name starts with any of: <space> ! # $ % & ( ) + , - (I suspect it's actually any ASCII character whose value is less than or equal to 0x2D, but some of those are illegal and/or unprintable). OS: WindowsXP LV Version: LabVIEW 8.6 and LabVIEW 2009 Steps to Reproduce (1) Map a network drive to a drive letter (I'm not sure that a mapped drive is necessary, and the network drive in this demonstration is a samba share from a Linux system). (2) Create a file in a directory on the network share from #1, e.g. "Z:\list-folder-bug\file.txt". (3) Note that LabVIEW's List Folder function returns correct results when listing the folder you just created. (4) Rename the file you created in #2 above, changing its name to !file.txt. (The key is that the filename must start with !, or any of the other characters listed above.) (5) Note that LabVIEW's List Folder function now returns two elements in folder names that don't really exist. Why This Is Important This is important because these phantom directories "." and ".." are expanded to "current directory" and "parent directory," which means LabVIEW thinks that the target directory contains a copy of itself and its parent. This produces an infinite recursion when listing directory contents recursively. In particular, the OpenG function List Directory Recursively is affected by this bug and enters an infinite loop when run on the directory shown in #5. Bonus Information Note, also that the dir command at the Windows Command Prompt sorts the file list in an odd way for files that begin with the aforementioned characters, but only on network shares.

If your devices are on your local subnet and respond to broadcast pings, you can ping the local broadcast address (x.x.x.255) which should cause your PC to cache the MAC addresses of all the devices that respond. I'm not sure it solves your problem at all but maybe it helps.

if you are running windows then you can go to a command prompt and type in "arp -a". It will give you the IP to MAC mapping that your PC knows about.

How about also adding a refnum glyph to the banners of these classes (e.g. a folded page or a zigzag line)?

Dear audience, There is a certain very long string (1-100 MB). It contains 16bit integers in little-endian format. I need to convert them to the proper i16 array. I am using Windows, x86. 2 solutions come to my mind: Use typecast to i16 array and then swap the bytes, since first typecast assumes big-endian order. Use unflatten from string, specifiying the right order. In actual BDs there is a constant instead of the control for array2 (this is what LV2009 changed when I created snipplet) One might think that avoiding an extra pair of byte swaps in the second case would make it faster. Not really, see the attached graph. It has size of the string along the X-axis (in MB) and time required to get the conversion done along the Y axis (in ms). The dependence is quite linear, so something extra is done on each byte of the data in case of unflatten from string. What is it? Why number 2 is slower? It does not depend on LabVIEW version (8.6 vs 2009) and does not depend on 32/64 bit. (crosspost from http://www.labviewpo...t=1367&start=0)

So the real solution would then be to add an endianess selector to the Typecast? Running and hiding! Rolf Kalbermatter

That is correct. The answer was D and here's a VI demonstrating a case where there's no buffer allocation - you can single step through it to see that only 16 MBs are allocated. Make sure to do a "save all" on the VIs before running and to have the subVI closed, though, because if you don't you will get allocation for the front panel terminals. The most correct answer of the four given, IMO, is that the types are consistent. It's not a technical term, but its meaning is clear. That means that if D was correct, then B should not have appeared as an option, because it's too close to the truth. I understand why whoever wrote the question got it wrong, but that just shows you that knowing a lot can sometimes hurt you when doing these exams. No Allocation.llb

Here is a slightly different version which would solve his original issue of converting a number with greater than 32 bits on an earlier version of LabVIEW that did not have U64 integers. This vi will take an arbitrarily long decimal string and convert it to a hexadecimal string.