mike5

Basically the "trick" is that Variant data type has two completely unrelated uses: It can be used as a "wrapper" for any other data type It can function as a "hash table" And it can be just one (x)or the other, not both at the same time.

Hi Ned, I'm not sure you know exactly what's going on here... UDP is a connectionless protocol, "UDP open" will never connect to the server. What I think it does it tries to bind a local UDP port. This is the port that will be used as "source port" in "UDP write". Maybe the timeout happens because it is unable to bind that port. My question is, do you need to bind a specific local port? The way you have written the application, it will send a datagram from source port 5000, to destination port 5000. You could just as easily leave the source port to be assigned randomly, especially since you do not expect top receive a response. Br, Mike

It is in the help file if you know what you're looking for http://zone.ni.com/reference/en-XX/help/371361H-01/lvconcepts/type_descriptors/ See section titled String, Path, and Picture Data Types. Br, Mike

Ha, the "classic" mistake. Goedel's incompleteness proof shows exactly that it is impossible to separate the syntax from semantics, even for something as simple as adding natural numbers. Br, Mike

Phew! For a moment there I thought this is gonna turn into a lolcat thread . Luckily it went the other way.

Looking for *what*? The property you mention is not displayed in the picture. OTOH, where does the "Get Text Rect.vi" come from - just in case I ever need to know... Br, Mike

In most languages the Booleans are stored as bytes. Memory is cheap. Also, to store a single Boolean on any modern computer, it will always use a byte. It is the smallest addressable piece of data on any computer. Even for arrays it would not pay to pack the Booleans into bits. As I said, memory is cheap, and having to do arithmetic to read a single Boolean value is a bigger waste of resource than memory space is... In the end, you usually want it simple and fast. Br, Mike

Hi all, a while back I was thinking about the how bad the LabVIEW debugging really is. The single stepping is a nightmare, as soon as your project has more than 3 VIs. Add to this the re-entrant VIs and multiprocess application, and you are soon lost in a sea of windows. I even posted this idea on the idea exchange, but it is not really thought through. So I was thinking - why don't we all come up with a good solution to this problem. Something that would address most of our needs and propose solutions for these problems that we would like to see. THEN we submit this proposal to the idea exchange and also promote it with our kudos. How does that sound? So, my problems are: too many windows open at once. Each function opens 2 windows, front panel and block diagram. Once you step through the function, the windows remain open. You don't have a clear idea where you came from (the trace in the drop-down is not really helpful). You don't have a quick access to the input parameters. not seeing all the blocked threads in a multiprocess application. If you set a break point which gets hit in multiple processes, LabVIEW opens all those windows for you, and it only adds to the clutter. You start debugging one instance, and all the other instances are blocked. Even if you click "continue" in those other instances, the windows stay open. If one of them hits a break-point again, you don't know this. In short, it's a mess... (This is not indented in the editor) The best way to overcome all this that I can come up with is and overview panel. It would contain a hierarchical list of all functions (call stack) all VIs where the execution is currently blocked would be marked all VIs that contain a breakpoint would be marked you could easily get to the input parameter values for each function you could disable breakpoints in some threads/processes only concentrating on the instance that is of interest to you you could combine this with an "auto-close" functionality that would automatically close the windows that were not explicitly open (like parents of function you are currently tracing) show the watched wires (to combine this with the problems of the watch window) Unfortunately I currently don't have the time to create a mockup picture, but I hope my description is good enough to get us started. Please add your own ideas and discuss. Thanks, Mike

How about checking attributes of each file I'm extracting? IIRC ZIP archive stores all file information at the end of an archive. Because I'm not reopening the archive for each file... Anyhow, all this has got to do with the folder separator on PXI-RT (discussed here), so we'll patch the OpenG ZIP library to do this correctly, and the problem should go away... Br, Mike

It appears it was "my bad" - or was it. I had a VI that extracted "all files one-by-one" instead of calling the OpenG "Expand ZIP". But I don't understand where the difference comes from (20 seconds vs X minutes). On inspection my VI didn't have any errors that would account for such a difference. Is "Extract single file from ZIP" really that much slower? Br, Miha

Hello, we're finding the ZIP library extremely slow on the PXI-RT. Is this normal, expected? Anything we can do to speed it up? We just need it to UNZIP the archives. Thanks in advance, Mike

I usually solve this problem in LV2010 with Ctrl-Alt-"Run Arrow" (Or is it Shift-Ctrl- ?) and/or Tools/Advanced.../Mass recompile Br, Mike

There's an error in your code... She very cute. Congratulations to you and your wife! Mike

Thanks, I didn't notice this. It will be most useful. Br, Miha

sachsm: I've set the Variable class to almost everything possible, and still the picture looks like this: Br, Mike