Darren

QUOTE (TiT @ Mar 20 2008, 02:02 AM) Good point...I can't believe I never wrote a nugget about this. That situation has been remedied...see http://forums.ni.com/ni/board/message?board.id=170&thread.id=310317' target="_blank">here. -D

QUOTE (PJM_labview @ Mar 19 2008, 07:49 PM) Sorry, I should have been more clear. You know how if you right-click in the diagram to bring up a temporary palette, when you pick something on the palette, it puts the object on your cursor to drop? Well, if you ctrl-right click instead and do the same thing, instead of dropping the object, it opens the panel of the VI (if the object you picked off the palette is a subVI). All I was saying was that it's an alternative to right-clicking on something in the palettes and choosing "Open VI", as was suggested earlier. -D

QUOTE (Aristos Queue @ Mar 19 2008, 04:35 PM) I agree with Stephen...the established method for creating new VIs from a template is the New... dialog. How many times in a LabVIEW editing session are you guys wanting to create a new VI based on a template that resides in the palettes? Also, instead of the right-click > Open VI method, you can also have the diagram of a VI on the palettes open if you shift-right click to bring up the temporary palette (instead of just regular right-click). -D

QUOTE (Aristos Queue @ Mar 19 2008, 10:36 AM) Yeah, of the 19 games for which I legitimately acquired the high score, 17 of them were removed. I'm not feeling incredibly motivated to go reclaim my top spot in the arcade, for fear of another unexpected reset at some point in the future. On the bright side, I do like the fact that there are more word-based games now. -D

I'm normally a pretty gracious loser, but I just noticed that all my high scores in the LAVA Arcade (and there were 19 of them) were miraculously beaten within the past day or two by a new user named "SweetVictory". I'm suspicious as to the validity of these victories, however, as some of these scores were attained in 45 seconds on games that have an average play time of about 20 minutes (see the high scores on Plumber 2 as an example). The only valid excuse I would accept for this incident is if we discover that SweetVictory hacked the LAVA arcade using LabVIEW. -D

Uncheck the Tools > Options > Block Diagram > Place front panel terminals as icons option. -D

QUOTE(rolfk @ Feb 21 2008, 02:28 PM) I probably shouldn't have used a double-negative in my response. I was trying to say that the format will almost certainly change significantly between two x.y versions (i.e. 8.2 to 8.5). It almost always changes between two x.y.z versions too (i.e. 8.2.0 to 8.2.1), but I'm pretty sure there has been at least one instance in the past where an x.y.z upgrade did not result in a version bump in the save format, which means the save format *could* be the same between those versions. But regardless, I still advocate using the Get VI Version method over any sort of sifting of the binary itself. -D

I wouldn't bet on the binary source not changing significantly between two x.y versions of LabVIEW. Perhaps two x.y.z versions... But if I were in your shoes, I would write a utility that uses the Get VI Version method (of the Application class) and the Save.For Previous method (of the VI class) to programmatically accomplish the task. -D

QUOTE(Thang Nguyen @ Jan 30 2008, 10:04 AM) As I mentioned in my previous post, this property requires access to VI Scripting. Search around on the LAVA forums for more information on VI Scripting. -D

QUOTE(BrokenArrow @ Jan 8 2008, 08:05 AM) Here's the description of the Arrays and Strings in Loops test from the VI Analyzer: Checks loops to see if they contain Build Array or Concatenate Strings functions. Avoid using these functions in loops because each call to them requires a dynamic resizing of the array or string, which can affect memory and processor time. This test does not check Timed Loops. Although there are cases (as illustrated in this thread) where repeated calls to Build Array inside a loop will not cause a performance degradation compared to other methods, there certainly are many cases where performance will be hindered. As a general rule, the VI Analyzer will point out *potential* performance problems, leaving it up to the user to assess the situation and determine whether the code does in fact need to change. -D

QUOTE(PJM_labview @ Oct 24 2007, 03:41 PM) The XDataNode is the "ear" that sticks off the side of the Timed Loop. The Timed Loop itself is a native LabVIEW structure. I'm fairly certain that there currently exists no way to create a G-based structure. -D

I've had long save/load times, along with temporary hangs in the editor, when using SCC with LabVIEW and the SCC server I'm connected to becomes unresponsive... -D

After I did some investigating, it seems like a breakpoint in a callback VI *should* be fired whenever debugging is turned on and reentrancy is turned off on the callback VI. Unfortunately, this isn't happening. I've filed a CAR (4EH9RQF2) on this issue. For now, I see three possible workarounds: (1) use the BDWin.Open property to open the callback VI diagram and probe wires on non-initial runs, (2) stick file I/O in the diagram of the callback VI to write debugging info to disk when it executes, and (3) the callback execution recorder utility posted earlier. -D

Hi Danny, I'm not sure what the problem could be...I just tried following my own procedure in the previous post and it worked fine. Double-check that the folder you created under LabVIEW Data is called "VI Analyzer Tests" (must be spelled correctly and use spaces as shown). Also, I noticed that when I tried to save the LLB from the LAVA site, it tried to stick underscores on the LLB name (Find_VI_Calls.llb). Those underscores cannot be there...the filename should be "Find VI Calls.llb" with spaces instead of underscores. Also, you may have a problem if you try to put multiple copies of the same test in different test folders, so I would remove the one you put in the project folder...that folder should only contain the shipping tests. I can't think of anything else that could be a problem. I tried it out in LabVIEW 8.2.1 and had no problems running the test. Keep me posted, -D

I'm trying to figure out why the breakpoint isn't being hit when the callback VI executes. In the meantime, I found a potential workaround (that requires access to scripting). You can put a BDWin.Open property in the callback VI to cause its diagram to open on the first call of the callback. On any subsequent calls, you can probe wires and the probes will return the wire values. This method won't work if you are only interested in debugging the first call of the callback VI. I'll post here when I find out more about why the breakpoint doesn't work. -D

What kind of "callback" VI are you referring to, i.e. how specifically is the VI being called? -D

Seems to work fine on other apps, too. Any reasons we should use this approach instead of just killing the desired process from Task Manager? -D

I'm seeing the unsaved changes prompt on my 8.5 project, too. In my case, it's because I'm using auto-populating folders. I filed a CAR on this, maybe the one referenced by the previous poster. I haven't seen the weird Semaphore/Rendezvous thing, though. -D

QUOTE(dwisti @ Sep 22 2007, 10:08 AM) To my knowledge, if you have the FPGA module installed, you can use fixed/bounded arrays in FPGA VIs or in normal VIs. -D

QUOTE(Jim Kring @ Sep 21 2007, 05:16 PM) Yup, but those VIs are only working with the type of the variant...they don't do anything with the value. And I don't suspect that will change. Remember that these VIs are the next generation of the type checking VIs that used to work on the I16 type array, they just use a variant now. I agree, though, that it would be helpful for the context help to indicate the specific behavior of the "size" output in relation to the "type" input. In fact, I'm pretty sure I was the one who did a code review with the author of these VIs before he added them to LabVIEW back a few versions ago, so I'll take partial responsibility... -D

QUOTE(Jim Kring @ Sep 21 2007, 01:35 PM) Hi Jim, I don't own these VIs, and I haven't seen the CAR, but my guess is that the "size" output is only valid for Fixed/Bounded arrays. Notice the "Type" output in the "Array Lengths" cluster of this VI. If the Type is Fixed or Bounded, I'd imagine you'd see a size there. Since these VIs are only analyzing the type data of the variant, they would have no way of knowing the size of a standard array in LabVIEW (returned as the "Variable" Type in that cluster). But for Fixed/Bounded arrays, the size is part of the data type. Hope this helps, -D P.S. - Fixed/Bounded arrays are a feature of the LabVIEW FPGA Module, as discussed http://zone.ni.com/reference/en-XX/help/371599B-01/lvfpgahelp/creating_fixedsize_arrays/' target="_blank">here.

For posterity, an easy way to create a new VI is to just use Open VI Reference on an empty template VI. Then you can do Open FP, or whatever other operations you wish, with the new instance of the template VI you just created. -D

That was good for a laugh...thanks, guys. -D

QUOTE(Justin Goeres @ Sep 8 2007, 12:24 AM) Yup, I love cryptic crosswords. The only place I've seen them is GAMES magazine. Usually takes me a couple of days of off-and-on work to finish one. -D

Ok, hopefully this will make things easier. The menu item I hijacked was Tools > Measurement and Automation Explorer. I don't know what version of LabVIEW this option was introduced in. Probably 8.0 if I had to guess. Anyway, I never use this menu option, so it was a good candidate for my prototype. This menu option launches project\max.llb\MAX Launcher.vi. If you replace that VI with your own VI, then whatever key combination is assigned to Tools > Measurement and Automation Explorer will launch your VI instead. In my case, it launches my Quick Drop prototype. I changed the key assignment (with Tools > Options > Menu Shortcuts) to Ctrl-Space which is easy for me to type with my left hand, and isn't currently assigned to anything in LabVIEW on Windows. Hope that helps, -D