Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by Darren

  1. 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
  2. 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
  3. 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
  4. 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
  5. What kind of "callback" VI are you referring to, i.e. how specifically is the VI being called? -D
  6. 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
  7. 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
  8. 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
  9. 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
  10. 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.
  11. 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
  12. That was good for a laugh...thanks, guys. -D
  13. 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
  14. 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
  15. QUOTE(yen @ Sep 3 2007, 01:57 PM) For my prototype at NI Week, I didn't need to do any polling. I'll give you a hint...I found a VI-based utility that you can launch from a keystroke in LabVIEW, and I hijacked it by putting my Quick Drop VI in place of the existing utility. -D
  16. ...and I'll throw in some parsley to garnish the gruel for an explanation of the two Always Copy and Swap Value nodes to the left of the "Do Not Delete" Sequence Structure. -D
  17. QUOTE(eaolson @ Aug 16 2007, 05:45 PM) I ran into this problem in a recent project...I was able to work around it by changing my picture control into a 2D array of picture controls, where the picture control element in the array had no border (so the pictures in the array all sit next to each other, and it *looks* like one big picture). Turns out using the built-in scrollbars on the array control looks fantastic, with none of the redraw headaches I had before with the single picture control. The only drawback is that scrolling the array takes place in an incremental fashion. For me this isn't a big deal since the UI I was constructing was more or less a grid in the first place, so scrolling in increments of one grid space (i.e. one element of the array) actually looks pretty nice...never have to worry about half a grid row/column being visible in the UI. -D
  18. QUOTE(Tomi Maila @ Aug 8 2007, 10:44 AM) Well alrighty then...let me know if/when you guys want me to write a VI Analyzer test for this, and what specifically it should detect. Another idea I had was that the test could have a configuration option that would return a failure for *any* Value property on the diagram, as long as there is something wired on the conpane. That way you could sift through them yourself to make sure none of the non-implicit ones would cause the problem. Also, I noticed the Val(Sgnl) property also demonstrates the bug. -D
  19. QUOTE(Ben @ Aug 8 2007, 07:30 AM) I read through this thread a few times to get a better grasp on the problem. It seems to me that you would want a VI Analyzer test that detects whenever the Value property is written for a control that is wired on the connector pane. Does that sound right? I could write a test that would detect this case for implicit property nodes pretty easily, but for property nodes with control references wired to them, that's a different story. I could detect the Value property on a property node that is wired directly to a control reference, but once you start getting into cases where the control reference is passed through a loop border, a subVI, other property nodes, etc., it becomes much more difficult to develop. So as it stands, I could pretty easily write a test that would detect implicit property nodes (or property nodes wired directly to control references) that are writing the Value property for controls on the connector pane. Would that be useful? Please let me know if I missed the mark and the test should detect something different. -D
  20. One of my favorites is Aristos Queue's scrolling LED XControl. -D
  21. Maybe try clearing your browser cache? -D
  22. I have a few suggestions for you. First of all, don't select all 4 Office support options in the installer, all that does is install each of them one at a time, where each subsequent selection just overwrites the files of the previous one. For installation purposes, you should only select whatever version of Office you currently have on your machine. If the version of Office on your machine changes, you need to uninstall/reinstall the toolkit to update your Office version-specific files. We are looking into ways of alleviating this confusion in future versions of the toolkit. Next, I assume you're building executables of your application for distribution? If so, you should follow the instructions for building executables in the Report Generation Toolkit User Guide. I have attached the latest User Guide (version 1.1.2) to this post, since it has the most updated instructions regarding building EXEs with the Report Generation Toolkit. Now if you are distributing the EXE to users with multiple versions of Office, you will need to create an EXE for each different Office version. Even though only the Office 2003 files are installed on your computer, when you build the EXE, you can include the dynamic VIs for any Office version by accessing the version-specific files in the "Compatibility" folder on your Report Generation Toolkit CD. Finally, I should point out that the latest version of the toolkit is 1.1.2. It is a free upgrade for users of version 1.1.1. It includes various bug fixes, along with support for Office 2007. The installer for version 1.1.2 only supports Office 2000, XP, 2003, and 2007. But the "Compatibility" folder on the RGT 1.1.2 CD still contains the Office 97 support files. Please let me know if you have any other questions. Again, we're working on ways to make this a much easier experience in future versions of the toolkit. -D
  23. QUOTE(LV Punk @ Jun 21 2007, 12:56 PM) Wow, I'm impressed. I tried to reverse-engineer the palettes a few months ago with that method and I didn't get nearly as far as you. Looks like your images are correct other than the coloring, which is a lot farther than I was able to get. Anyway, here's a hint I learned...if you write the U8 "image" array of a palette object to a binary file, you'll have a .emf file that contains the palette image of that object. I studied the .emf file format and was able to extract all the header information in G, but I gave up when I tried to start parsing the actual .emf drawing commands that appear in the file after the header. At that point I looked around for a G-based EMF file reader, and the only one I could find was in George Zou's G Toolbox. And at that point, I actually took a different direction in the project and didn't need to take the EMF approach anyway. Nice work, -D
  24. There's the Palette API posted on the NI Community website...this would be a good place to start if you've already got .mnu files that you want to present to the user in your own manner outside of the LabVIEW palettes. -D
  25. QUOTE(jlokanis @ May 24 2007, 06:17 PM) Methods 2 and 3 (property node ref and This VI ref) are functionally the same if you don't wire the output of whatever property you're reading. They return a "Self Reference" to the VI that does not need to be closed. Instead of dropping a control ref and re-linking it to the VI, you can drop a "This VI" reference from the Application Control subpalette. Ooh, now that I think about it, that reference may drop as "This App" instead of "This VI"...I don't have LabVIEW open right now. Either way, This App/This VI are the top two choices on the top of the list when you operate-click the reference. Hope this helps, -D
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.