Leaderboard

I have seen this error a few times when the application builder has not managed to successfully built a valid executable but hasn't returned an error either. Last time I saw this error was when there was not enough memory in the build machine for LabVIEW to build a proper executable. As a result the executable didn't really contain anything and the final size of the executable was too small. When executing it, you got this error, which was natural because the executable was corrupted. The problem really was in LV application builder. We fixed the issue first time by getting LabVIEW to address more memory in 32-bit machine during the build and the second time by moving the 32-bit LabVIEW used for building to 64-bit machine.

Along the lines of what Ben suggested, I believe you can simply add a second plot with x=0 for all y values and simply use that plot as the fill baseline for the first plot. I'd do the similar thing for the horizontal rendering (y=0 for all x) so you do not have to futz with the fill baseline via property nodes and can always fill to plot 1.

I posted a small tidbit of useful info over on ni.com for those of you who like to squeeze every drop of performance out of your LV code. This tidbit involves avoiding data copies when doing type testing on objects: http://forums.ni.com/t5/LabVIEW/Performance-tweak-for-LV-Classes-and-quot-To-More-Specific-quot/m-p/1760322/message-uid/1760322#U1760322

*laugh* Can I add that to the list of advantages from large icons for new users? :-)

The feature I'm imagining will only snap to a possible position when it is within a couple of pixels. This should be small enough that is will act to help the programmer align things exactly as he/she wants. So, if you want the tops of subVIs to line up instead of straight wires then no problem. Want bend the wires in a readable way, no problem. Basically, you place the item where you want and the program helps with the micro-positioning. You would have to place the terminal within two pixels of aligned to trigger the snap-to; nothing is forced on the programmer. Now, if you actually wanted the terminal one or two pixels off alignment with another, you would need to hit the arrow key once or twice. Hopefully, such situations will be rare. If not, there would be the ability (including a hot key) to turn the feature on/off. Unfortunately, it's hard to verbally communicate the advantages of CAD-like guides. -- James

WOW, this is a hot topic. I may as well add my two cents worth. I much prefer small terminals, not icons. Mainly because you can position them much closer, and it keeps the block diagram much neater. I think NI use Icon terminals by default, for beginners or amateurs of LabVIEW. ie. People who may not know the data types too well.

There are two sources for this error. The most probable is a bug in LabVIEW of some sort. The less probable, but worth checking, is a Call Library Node in your own code that is calling a poorly written DLL or a poorly configured Call Library Node that doesn't match what the underlying DLL is doing. The memory manager can be messed up if a DLL modifies a piece of memory that LV did not expect it to modify. If you aren't using DLL calls or if you already checked them for correctness, then it's probably an issue inside LV. The correct action at that point is to contact an NI Application Engineer (through the forums or by phone if you have a support contract) and see if they can debug what's going on. They can escalate a CAR and may be able to provide a workaround.

I bought the Samsung, and I love it. I like the flexibilities that Android Honeycomb is offering and I can copy and paste files from my network server with the file browser, and of course the best of all, I don't need to use ITunes :-) //Mike

Terminals, definitely. It's one of the handfull of settings I immediately change with a fresh LV install. (Along with branching dots, constant folding, and a few others.) I disagree. Emphasizing the inputs and outputs distracts me from what I'm really interested in, which is what the code is doing. Terminal icons are too similar in shape and size to sub vi icons, and to a lesser extent class constants. When I look at the diagram you posted it's hard to quickly identify where the vis are. The first couple times I glanced at it I didn't even notice the final Msg method outside the case structure--it was lost in the noise. In contrast, I easily identified all the sub vis in Shaun's diagram.

Yep. The password can't encrypt the diagram. The whole point is that the diagram is still readable so that it can be recompiled. If you want security, you have to save your VIs without diagrams and give up the ability to recompile for different platforms and different LV versions.You're just lucky no one has build an equivalent of Reflector for LabVIEW. It can regenerate C# source code from the binary compiled DLLs or EXEs, even without the debug info being included. In the modern world, you have three choices: don't share your code in the first place only give it to users who aren't dedicated to getting into your code or for whom it is cheaper to buy it than to crack it get a lawyer to enforce your copyright and terms of use. Small claims court is your friend here. Those are your options. Let's just say his next PXI chasis will be "calibrated differently" and leave it at that.