Jump to content

AdamRofer

Members
  • Posts

    44
  • Joined

  • Last visited

    Never
  • Days Won

    1

Everything posted by AdamRofer

  1. Name: XNodes - A Crash Course (PowerPoint) Submitter: LAVA 1.0 Content Submitted: 03 Jul 2009 Category: XNodes LabVIEW Version: Not Applicable Version: 1.0.0 License Type: Creative Commons Attribution 3.0 Potentially make this available on the VI Package Network?: Undecided This was presented at the 02/22/07 LAVA meeting. Discusses the various aspects of both XNodes and External Nodes, shows comparisons, and shows example usage. I ended up skipping over two of the "Creating XNodes" pages since Aitor Solar's XNode Manager is a much better place to create your XNodes with. View the comments page Click here to download this file
  2. 3,481 downloads

    This was presented at the 02/22/07 LAVA meeting. Discusses the various aspects of both XNodes and External Nodes, shows comparisons, and shows example usage. I ended up skipping over two of the "Creating XNodes" pages since Aitor Solar's XNode Manager is a much better place to create your XNodes with. View the comments page
  3. 1,394 downloads

    Copyright © 2006, Adam Rofer All rights reserved. Author: Adam Rofer --see readme file for contact information Description: A couple of Picture datatype hacks to illustrate the structure of the (LV 6.1 - LV 7+ is untested) picture control. -- Main VIs -- Example - Show How Picture Is Made.vi: Main example, shows (incrementally) how a specific picture is generated by displaying the picture with each packet incrementally added. Good way to see how your own pictures display information. Opcodes.csv: Comma-delimited file explicitly describing the packet types and their requirements / uses. Tool - Picture concat.vi: Given two pictures, concatenates the data to create a single overlapped picture. Tool - Packets to Picture.vi: Given an array of picture packets (cluster), generates a picture. Tool - Picture to Packets.vi: Given a picture, generates an array of picture packets. -- Utility subVIs -- sub - 8-Bit string to 32-Bit number.vi: utility VI to cast a string to a 32-bit number. Typecast might work instead but this is more explicit. sub - Find Opcode: Given a picture data string that has the size header removed, this will extract an opcode from the front. sub - Strip top of and check picture.vi: Utility VI to strip the header (size) from a picture data string so that it can be scanned for packets. Change Log: 1.0.1: (11/13/06) Cleaned up code for LAVA requirements: - Renamed VIs for clarification of purpose - Fixed coercion dots - Added 0ms delays in all loops - Added error encapsulation in some subvis - Replaced local variable for cluster to constant in order to limit thread swapping between the user interface and code threads 1.0.0: (11/07/06) Cleaned up code from 6i 2001 version for submission.
  4. Name: Picture Hacks Submitter: LAVA 1.0 Content Submitted: 03 Jul 2009 Category: User Interface LabVIEW Version: 6.1 Version: 1.0.1 License Type: Creative Commons Attribution 3.0 Potentially make this available on the VI Package Network?: Undecided Copyright © 2006, Adam Rofer All rights reserved. Author: Adam Rofer --see readme file for contact information Description: A couple of Picture datatype hacks to illustrate the structure of the (LV 6.1 - LV 7+ is untested) picture control. -- Main VIs -- Example - Show How Picture Is Made.vi: Main example, shows (incrementally) how a specific picture is generated by displaying the picture with each packet incrementally added. Good way to see how your own pictures display information. Opcodes.csv: Comma-delimited file explicitly describing the packet types and their requirements / uses. Tool - Picture concat.vi: Given two pictures, concatenates the data to create a single overlapped picture. Tool - Packets to Picture.vi: Given an array of picture packets (cluster), generates a picture. Tool - Picture to Packets.vi: Given a picture, generates an array of picture packets. -- Utility subVIs -- sub - 8-Bit string to 32-Bit number.vi: utility VI to cast a string to a 32-bit number. Typecast might work instead but this is more explicit. sub - Find Opcode: Given a picture data string that has the size header removed, this will extract an opcode from the front. sub - Strip top of and check picture.vi: Utility VI to strip the header (size) from a picture data string so that it can be scanned for packets. Change Log: 1.0.1: (11/13/06) Cleaned up code for LAVA requirements: - Renamed VIs for clarification of purpose - Fixed coercion dots - Added 0ms delays in all loops - Added error encapsulation in some subvis - Replaced local variable for cluster to constant in order to limit thread swapping between the user interface and code threads 1.0.0: (11/07/06) Cleaned up code from 6i 2001 version for submission. Click here to download this file
  5. ABOUT FRIGGING TIME. That is all. Also, XNodes would be good to "release," like other people have said. Even if they need to be "cleaned up" for the "public." - Adam
  6. QUOTE(Aristos Queue @ Aug 3 2007, 12:29 PM) They sure can! Just pop in this bad boy (commence shuddering and fear): http://forums.lavag.org/Recursion-t9832.html' target="_blank">Rusty Nail Use caution with them, though. I am not perfect. NI will provide much more stability in this arena than I will with my rusty nails.
  7. This is a posting of code I haven't touched in a while that seems relevant. This was originally inspired by this forum posting by Norm: http://forums.lavag.org/Automatic-Recursion-t4318.html External Node: http://xnodes.lavag.org/externalnodes/recursion.html XNode (LabVIEW 8.20+): http://xnodes.lavag.org/xnodes/code/AHR_Recurse_xnode.zip This XNode is one that I demonstrated at the User's Group meeting a year ago. It's not tested much, and might need polish, but it seemed to work. Just make sure your VI is re-entrant for it to work. If you want to use the External Node, then make sure to enable them in your INI file. I'd recommend the XNode. Just be wary and save your files often when dealing with user-made XNodes!
  8. QUOTE(TobyD @ Dec 28 2007, 01:05 PM) http://en.wikipedia.org/wiki/Degree_symbol QUOTE On Apple Computer's Mac OS, the degree sign can be typed by Option-Shift-8 on most keyboard layouts, including Australian, British, Canadian and U.S. Extended layouts. (Option-K, on the other hand, is "ring above") On Microsoft Windows, the degree sign can be typed by ALT + 0176 on the numeric keypad. On Linux and other Unix-like systems, many keyboard layouts allow typing the degree sign with AltGr+Shift+0. Due to a similar appearance in some fonts in print and on computer screens, some other characters may be mistakenly substituted for it: the "masculine ordinal indicator" (U+00BA, º ), the "ring above" (U+02DA, ˚ ), "superscript zero" (U+2070, ⁰ ), superscript zero proper ( 0 ) or superscript letter "o" ( o ), and the "ring operator" (U+2218, ∘ ). So, like everyone said, but ALT+0176 is the only "proper" degree symbol (U+00B0, °) (I just learned this today). --- Adam Rofer
  9. Easy stuff: 1) Keep code optimized, fewest amount of other apps open, etc etc 2) There's tons of LabVIEW only stuff that you guys should list here that I can't think of 3) Keep your hard drives defragged, registry cleaned, etc etc 4) Get XP SP3 when it is released (assuming it doesn't break anything, who knows yet) -- 10% on average increase in application speed from what people have been saying Mildly advanced fare: 1) Force the application priority AboveNormal/High/RealTime using win32 dll calls (setPriorityClass) or a third-party app that can enforce application priority based on the program (like "Iarsn's TaskInfo"). This affects a single process quite a bit for performance. 2) Optimize your quantum/process background or foreground priority (e.g. big time chunk means less switching to other processes) [see the NI link/Tomi's post above] (and my details on the same thing) -- set this according to if your "target" application is in the foreground or not, and whether or not it will always be. 3) Buy a solid-state/flash hard drive (a lot faster for HDD calls and virtual memory paging) 4) Disable the Themes service (makes things ugly but faster) Super tweaks to (dangerously) try: 1) Disable Virtual Memory only if you can handle it and know exactly what this entails and sets you at risk 2) Disable services you don't need (sound, indexing service, etc) 3) Any of these depending on your needs Untested uber tweakage: 1) Play around with some fun win32 calls (I haven't used these): timeBeginPeriod LockSetForegroundWindowgetCurrentThread multiprocessor --> set thread to specific processor(s): setAffinityThread or setThreadIdealProcessor setThreadPriority 2) There's a way to make certain threads have realtime priority, apparently:http://kotaku.com/336552/windows-media-pla...wow-load-faster "...this is because media player is the only app known today that uses the MMCSS stuff it elevates the priority of threads in a process registered with MMSCS to the realtime level which cannot be done by an app itself only the MMCSS (a system component) can do that magic..." ...as long as those threads are "registered with" MMCSS, whatever that might entail. Gotta love the magic. Hope some of these (potentially dangerous) tweaks can help. Also, there might be something helpful for LabVIEW optimization here: http://wiki.lavag.org/LabVIEW_configuration_file/Unknown Likely not, though. --- Adam Rofer
  10. QUOTE(jed @ Sep 11 2007, 01:26 PM) I keep a shortcut on my desktop to "C:\WINDOWS\system32\shutdown.exe -a" which aborts any shutdowns that I notice quickly enough. I'm sure a Windows DLL alternative is out there but calling this should work as well.
  11. QUOTE(Aristos Queue @ Apr 30 2007, 02:12 PM) For me, I get: QUOTE Requirements: One of the following is required, please click an item to Purchase. The following membership(s): SIGPLAN Online Membership SIGPLAN Print Membership Sigplan-Fortran Forum The following subscription(s): ACM Digital Library Sigplan Newsletter Purchase this Article. A quick click on the "Terms Of Usage" below garners: QUOTE You may make digital or hard copies of the individual articles that you are entitled to access for personal or classroom use, as long as the copies are not made or distributed for profit or commercial advantage and they bear the ACM copyright notice. You may assemble and distribute links that point to works in the ACM Digital Library. Please do not republish these ACM works, or post them on other servers, or redistribute them to lists, without first getting explicit permission from ACM. Contact permissions@acm.org. Please do not abuse your access rights to the ACM Digital Library by wholesale duplication of all or substantial sections of the ACM Digital Library. It looks like a really cool article.
  12. Yes, AQ, I did intend for "new" to refer to "newly discovered." I also figured that Aristotle had not published without some discourse since, but I am always wary of the way of thought that "everything has been discussed" over these topics (or any topics). As the palimpsest uncovering seems to be from Alexander of Aphrodisias (the Wikipedia article needed updating), I thought that a fresh (counter) look from waaay back when this sort of stuff was just beginning to take fruit would be real nice since OOP has been mulled over in completely new context recently. In learning more about the old philosophies that brought about such conceptual advancements (as taxonomy), people with complaints and concepts targeting OOP can take a step back and say "ok, so this is a fundamental limitation to this way of thought" as opposed to "this is a bug." In reading what we have so far in the palimpsest, I have the same (shallow) response you do. I'm not as familiar with ancient Greek as I once was, but I do believe that when referring to feet one cannot assume that these feet will be able to move unless the context (namespace) of the type of object is inherent in the discussion. This sort of "same name" difficulty is what can make a language easy or hard to use, versus how fast you can communicate concepts. See it as language compression, if you will. Yes, "foot" means the same thing in that it usually represents something at the end of a "leg" that keeps an item up, and in that sense you can apply anything you want to that definition. I think the flaw is inherent to how you use it...if you say you went into a house and counted the feet you found, nobody could say if you meant animal feet or table feet. I've played the 20 Questions game several times, and as a result I almost thought about demanding some royalty fees...They usually got my items wrong, and whenever I provided them with what I am thinking of that information was stored. This stored information now helps them sell the portable units that have a stripped down version with probably pretty compressed data stored on the pucks that are sold. Wikipedia, Digg, del.icio.us especially, and virtually any Web 2.0 application has one intended purpose: taxonomy. Taxonomy simplifies thought and focuses efforts on core problems (in most cases, if done properly) and as a result one does not have to work as hard in the best situations of OOP as the same ones in non-OOP languages. I'm pretty sure we won't see anything that hasn't been asked before, but in this case we can certainly cut through the junk and get right down to the core OOP elements with this discussion (and more appropriately in your new direction here). I'm glad I could spark such an involved discussion on this topic...I've somewhat avoided OOP in the past! P.S. The article you link to looks awesome but I'm afraid a lot of people don't have a SIG or ACM membership, which appears to be required. Free web signup does not allow one to download this PDF.
  13. A new critique on the "object oriented" way of thinking has been uncovered within the Archimedes Palimpsest (article here): QUOTE This refers to Aristotle's Categories. From the article Categorization: "The classical Aristotelian view claims that categories are discrete entities characterized by a set of properties which are shared by their members." And yeah, I know quoting Wikipedia is asking for trouble.
  14. QUOTE(Pablo Bleyer @ Apr 12 2007, 02:03 PM) If you know the type of the control (such as Digital), you can use To More Specific Class and cast it to that strict type...Value then returns the the value in the type that the strict reference has. http://forums.lavag.org/index.php?act=attach&type=post&id=5486''>http://forums.lavag.org/index.php?act=attach&type=post&id=5486'>http://forums.lavag.org/index.php?act=attach&type=post&id=5486 If you don't know how to get a strict reference type, then do this: a) Find the control you want to get the strict reference type from. b) Right click on it and select Create Reference. c) Right click on the new reference and select Create Constant. d) Delete the item created in step b.
  15. QUOTE(dsaunders @ Apr 12 2007, 11:06 AM) App.User Interaction:Edit Icon is what you're looking for, just be sure to pass in valid icon data into "Color 256" or else it won't open. Attached VI works in LabVIEW 8.0 (and above, I assume).
  16. QUOTE(mballa @ Apr 12 2007, 08:52 AM) From what I can see, you're stuck with creating your own editor. Use the properties VI.VI Description, VI.Help:Document Tag, and VI.Help:Document Path. Don't forget to save your VI with the method VI.Save.Instrument before closing the reference. Of course, someone else might know how to pop up the LabVIEW VI Properties dialog, but I can't find any methods that do this.
  17. QUOTE(rolfk @ Apr 12 2007, 09:02 AM) The most efficient solution I found (no handle leaks or memory leaks, unlike VISA in LabVIEW 6.1) is to open a reference to the "lpt1" "file" and write to it. This is only used for raw text as far as I am aware, and it's definitely a Windows-only solution, but it works fantastically. No silly CMD stuff is necessary when the Windows API is everything you need. The attached file is written in LabVIEW 6.1 but it will work in all versions. Windows APIs used (pseudocode): Kernel32.dll: handle = CreateFileA("lpt1", GENERIC_WRITE=0x40000000, 0, NULL=0, OPEN_EXISTING=3, FILE_ATTRIBUTE_NORMAL=0x80, NULL=0) Error_if_zero = WriteFile(handle, string_buffer, string_length(string_buffer), &number_of_bytes_written, NULL=0) Error_if_zero = CloseHandle(handle)
  18. QUOTE(Ami @ Apr 9 2007, 01:46 PM) I gave it a shot and the same crash occurred. It's not like it was intended, but it seems that this functionality isn't available yet. The Add Event Method also doesn't seem to let you specify anything valuable. It seems the EventStructure has the exact same items as a MultiFrameStructure, so there's no special functions exposed with the type. Awesome.
  19. I know the licensing included in LabVIEW 8.0 and beyond has been a show-stopper for some customers. LabVIEW 7 on a computer with the NILM installed seems to be slower, although I don't have any benchmarks to back this up at hand.
  20. QUOTE(Ami @ Apr 7 2007, 05:23 PM) I only have LabVIEW 8.0 in front of me right now, but I found out that casting the Event Structure refnum to a Case Structure refnum and then writing to or reading from the "Frame Names" item crashes LabVIEW (now it's getting fun!). However, writing an array that differs in size with the existing number of Events causes an error 1302: "The size of the array passed in does not match the expected size of the array for the operation." Perhaps this works as of 8.2, 8.2.1, or future versions, but not in LabVIEW 8.0 at least. I'm guessing that "Frame Names" would be the desired property here.
  21. 1000 posts of impressive quality, as well. :thumbup:
  22. AdamRofer

    Macro

    QUOTE(DanyAllard @ Apr 2 2007, 11:51 AM) Thanks for the clarification Dany, I had that set from before so I forgot it was necessary. What happens when you drag the .vim from explorer onto a Block Diagram?
  23. AdamRofer

    Macro

    QUOTE(Aitor Solar @ Apr 1 2007, 10:55 PM) I'm not sure how far back this goes (probably as far back as the Macroizer thing exists), but this VI appears to run in one instance. Apparently you can have an automatic "macroization" of any VI you want. (This was tested in LabVIEW 8.20) Step one: take a VI "xx.vi", rename it "xx.vim" Step two: drag it onto the block diagram Now this VI is a subVI, but note you cannot double click on it to enter the VI itself. I imagine that all the other problems that plague External Nodes in general exist here also, which might be why this behavior is not advertised. You can still access the VI through the VI Heirarchy, although if you copy the VI around the Block Diagram then you might not see it listed as a subVI of that VI (?!?!). I'm sure a lot more "interesting" results can be found...I really don't know what purpose this could have, but then again the locked VI might have some more stuff in it than just this. Weird stuff.
  24. QUOTE(Gavin Burnell @ Mar 29 2007, 01:37 PM) I started off that way to try to find an answer to your question, and it tells you that it's a Node (surprise!). You can typecast a similar object to acquire a similar function that isn't necessarily exposed on that object, as Yen pointed out in this forum post: http://forums.lavag.org/How-to-get-reference-to-Text-of-StringConstant-t5791.html' target="_blank">How to get reference to Text of StringConstant? I couldn't get any probable casts to work, I thought Formula.Formula Expression would be the closest match. Decoration.Text.Vertical Arrangement is another property that should work but doesn't, possibly indicating that scripting on this object type is (for now) not possible in the way you need to. The most I was able to do is get Node.Style to tell me it was an "Expression Node" Keep trying, though, and let us know! :thumbup: EDIT: It looks like the setup is almost identical to UnitCast (Convert Unit) objects, but the UnitCast.Unit property still doesn't yield the Expression Node stuff. Decoration.Text.Vertical Arrangement on UnitCast items is also not possible, oddly enough.
  25. QUOTE(i2c @ Mar 25 2007, 03:23 PM) I have used quite a few ActiveX components in LabVIEW and I've discovered a few things over time: 1) In LabVIEW, always close your references; always close your references. Always close your references. If you don't then bad things might happen, like random hangs. 2) Variables (such as the TimeStamp in LV 7+, aka Date in VB6) don't always match up perfectly, so experiment before releasing stuff to other people. 3) Any problems in your ActiveX component (memory leaks, handle leaks) will still exist, so make sure you don't open a reference to a registry location without closing it. 4) If there's a "hidden" ActiveX Property/Method then you can't explicitly "call" it in LabVIEW like you might be able to in another language. 5) Using ActiveX in LabVIEW is pretty easy. 6) Play around a bit with the whole compatibility thing (binary, etc). If you upgrade a component that breaks compatibility then sometimes LabVIEW will make you go through and re-select every Property / Method you have wired up. You cannot have compatibility sometimes when you modify a Property or Method. LabVIEW will always force you to see that things have changed, so just be aware and listen to the Diagram Errors box when something won't run after you upgrade a component. 7) "regsrv32 abc.dll" and "regsrv32 -u abc.dll" are your friends (register and unregister AX components). If you don't explicitly ask VB6 or your C++ compiler to do this already, you have to make sure to (a) close LabVIEW, (b) unregister your old component, © open LabVIEW, (d) make sure things still work with the new version. As for tutorials, the help file should have some stuff about it, but http://zone.ni.com/reference/en-XX/help/371361B-01/lvconcepts/using_activex_with_labview/' target="_blank">Here is some information on NI's site.
×
×
  • Create New...

Important Information

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