Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by JackDunaway

  1. That's not OCD, that's a fantastic way to ensure your syntax can be synthesized by a measly human. CTRL+Scrolling through your diagrams, the human eye can handily diff similar cases. I'd gladly inherit your code anyday, sir. (I bet, you even understand why "Make Space" inside a structure is reserved only for Sinners)
  2. Does the offending VI contain a Diagram Disable structure? While you're checking, do an object search on the entire hierarchy for Diagram Disable structures, and missing VIs in disabled cases. Likewise, search your project by right-clicking the root node and selecting "Find Missing Items"
  3. Would you elaborate on what was broken? I'm intrigued. (One of the usual suspects for code that works in the IDE but a build that fails is to check the hierarchy for Diagram Disable structures. If the structure contains disabled but missing SubVI, App Builder will fail. This is typical on EXE builds but not installers, so I'm curious to learn more about the failure mode you fixed!)
  4. Here we are a year later; I no longer consider Community scope as a tool in my API design toolbox, for reasons in this thread, but more importantly for reasons in this thread. Making the change from "Community" to "Public" caused more mental/academic anguish than practical problems (i.e., it felt improper and dirty, but I've yet to find even a single negative ramification).
  5. Agree on use of "Application Directory" (it looks like a primitive on the File Constants palette). I prefer to structure my dev environment file structure the same as the deployment file structure for scenarios like this; e.g., a folder called "Support" at the same level as the LVPROJ in the dev environment, which maps to the same relative directory as "Support" (or "data") sitting next to the EXE in the deployment environment. However, in your case, since this the development of a COTS product; you may consider implications of statically linking this DLL rather than dynamically linking, so that App Builder takes care of the rest for your API end-users building EXEs. Since this toolkit is probably installed into vi.lib (rather than your project directory, i'm just guessing here), that's one minor level of complexity more than the method described above of straight mapping between dev/deployment environments.
  6. Austin: if the library is statically linked to your application, App Builder should suck in the library as a dependency during the build -- the LabVIEW API would be bundled into the EXE, and the statically linked DLLs referenced by the API would by default go into the support directory "data" next to the EXE. Perhaps, you're dynamically linking or lazy loading this API? If this is the case, consider marking the file as Always Included from the EXE build spec properties dialog.
  7. Under VI Properties >> Window Appearance, is "Show front panel when loaded" checked?
  8. Have you heard that joke about UDP? You might not get it... (But seriously; just subscribing here for the emails out of interest on this topic)
  9. Favorite feature: LabVIEW Web Services in 2013 -- the R&D Team nailed it with the all-new LVOOP API
  10. For those of you joining us at NIWeek 2013: Regular Pricing is available only three (3) more days -- grab your tickets here: lavag.org/bbq-tickets And if you would like to sponsor a door prize but have not yet decided what to get, bring a couple of these and become everyone's favorite person ever:
  11. Special thank you to Jon at JGCode in Australia for sponsoring this gift even though he is unable to come to NIWeek this year. It's very generous, and we're glad to have him a part of the LabVIEW community.
  12. The general term for this is "object relational mapping".
  13. Did you happen to catch the announcement a while back (LV2010 era) that LabVIEW source was being compiled to DFIR (DataFlow Intermediate Representation) and then to LLVM IR (Low Level Virtual Machine) before being compiled to target-specific machine code? Let's look at LLVM a moment; it's exciting. This acronym is not just some LabVIEW R&D mumbo jumbo; the LLVM compiler is something that has cause quite a stir in the programming community for some time now. In 2012 -- two years after NI R&D publicly announced that LabVIEW was leveraging LLVM -- LLVM won the ACM Software System Award. Who else has won this yearly award given to only one project? Ever heard of, say, UNIX? Java? The World-Wide Web? Eclipse? Apache? Shite -- i guess this makes LLVM A Big Deal. A couple top-notch articles I've caught recently include: "IR is better than assembly": https://idea.popcount.org/2013-07-24-ir-is-better-than-assembly/ "Kaleidoscope and the Lexer": http://llvm.org/docs/tutorial/LangImpl1.html And my favorite, for the dear memories and sheer genius of this guy: "Statically Recompiling NES Games into Native Executables with LLVM and Go": http://andrewkelley.me/post/jamulator.html This stuff is blowing my mind, and I'm really glad to know LabVIEW has hitched its wagon to LLVM. Keep it up, Compiler Team -- chime in here and tell us more.
  14. Maybe someone in Austin wins it and *I* am lucky! (Psstt -- split it with you, fellow Austinite, if you want to double our chances of winning some BBQ!) On second thought... sad times... as one of the organizers I'm disqualified from being in the drawing :-(
  15. Wirebird Labs will sponsor two (2) Leap Motion Controllers. Announced yesterday, a new marketplace for Leap Motion software has opened at airspace.leapmotion.com, featuring 75+ applications. See you at the BBQ! Screenshot from https://www.leapmotion.com/product
  16. Not a stupid question at all! We have a complete roster of everyone signed up, so you should not need to bring anything. It would not hurt to have an email of the receipt on your smartphone, just in case. But certainly, no need to print. The only thing we would strongly suggest bringing is your NIWeek Name Badge. Not so much for identifying yourself at the registration table, but so you'll feel more comfortable meeting new people and networking. Pro-tip: the badge holder is a perfect place to stash 8-10 biz cards.
  17. Friendly bump before many of you go away for the US Independence Day long weekend: Early-bird pricing ends this Friday, 05 July 2013 at midnight, Austin time. After that, ticket prices go up $5USD. Register today, and bring that extra Abe for the cash bar! (*an Abe is a $5 bill)
  18. Of course! http://lavag.org/topic/16930-lava-bbq-2013-door-prizes/ And for those planning on sponsoring door prizes: there's a field during ticket checkout where you can enter information about intent to sponsor a prize. Feel free to mirror that information on the public thread linked. Between both channels, I will be sure to follow up with you prior to the BBQ to ensure we've got all the details.
  19. Hi KJ, there's a board devoted to this on the NI forum, there you'll likely get a quicker turn-around on LAVA -- http://forums.ni.com/t5/Version-Conversion/bd-p/VersionConversion -- good luck!
  20. Are deployed systems guaranteed internet access and the ability to ping a license server?
  21. +1; incidentally, for the good article; fundamentally, for what's in the pipeline.
  22. Bingo. Sounds like you'll be fine, since this Launcher VI remains reserved for execution as long as the top-level VI remains running. But just to watch out for in the future, here are two places this can get tricky: When shutting down your application: If the top-level loop stops before the clones stop, the Event Ref will go invalid since its lifetime is tied to the top-level loop. Fortunately, the Events API grants immunity against this, because the Event Registration Refnum can have a different lifetime than that of the Event Ref. In your example, the event ref lifetime is tied to the static call chain of the Launcher up to the top-level state machine, while the Event Registration Refnum is tied to the lifetime of the Clone (presumably, if the Clone is calling the Register For Events method). For this reason, it's OK for the top-level loop to send a final "Shutdown" message and then immediately close the Event Ref -- even though the Messenger is now gone, the Mailbox remains valid with the final Shutdown message in its queue. When you're running the Launcher directly from the IDE in order to troubleshoot/develop the clones: If you were to run this VI directly, it would launch the clones, but the User Event references would immediately die as this Launcher is no longer running or reserved for execution. Common misconception -- even though it remains in memory (since the panel remains open), and even though we passed the references to VIs that are currently running, references created by this VI go invalid once the VI finishes execution. One way to circumvent this, is to create a trivlally simple "Debug Launcher" VI that makes a static call to the launcher and remains running until a simple event (shown below):
  23. Not related to the VI Clone Refs per se, but while we're on the topic... Since the User Events are created by this launcher SubVI, this SubVI must remain reserved for execution (or running) for the User Event Refs to remain valid. One common misconception is to think that keeping this VI in memory is sufficient, or that once passed to the clones the User Event Refs tie their lifetimes to that of the clones. The lifetimes of these User Events are tied to the static call chain of the diagram that creates the references. This gets tricky when clones start launching clones.
  24. +1 for a good question. Playing devil's advocate, I appreciate LVClass, LVLib, and LVProj underlying representations as XML -- source code control infrastructure (including diff/merge) generally just work way better with text formats. (It would be super slick if all LV filetypes likewise were represented as XML, or JSON, or... not binary) In terms of editing the class definition on a diagram, can you provide some examples? Sounds neat.
  25. Greetings Friends of LAVA, colleagues, cohorts, and partners in crime! tl;dr: LAVA BBQ tickets on sale now, limited numbers on Early Bird pricing, get your tickets here: LAVA BBQ 2013 Event Page (lavag.org/bbq-tickets) LAVA BBQ 2012 in the Scholz Garten Biergarten (Photo by Norm Kirchner) It’s that time of year -- getting NIWeek approval, booking flights to AUS, and being the first to nab your LAVA BBQ ticket! For those of you who have never been to the kind of LAVA BBQ we're putting on, it's a time to get to know “the people behind the avatars” over BBQ and beers. Everything you need to know is on the LAVA BBQ 2013 Event Page, including time, a link to a map, a checkout to buy tickets today ... but we’ll violate the SSOT principle and make a data copy of the BBQ2013.lvclass object below: Date: Tuesday, 06 August 2013 Time: 7:00-10:00pm CDT (after the NIWeek Block Diagram Party. You won’t miss any NIWeek official events) Time for @LabVIEW_BORAT (and other ISO-8601-compliant robots): <EventBeginTimestamp>2013-08-07T00:00:00.000Z</EventBeginTimestamp> Location: Scholz Garten, 1607 San Jacinto Blvd, Austin, TX 78704 (1 mile from Convention Center) Cost: $30 Early Bird (until July 5th) $35 Regular Admission (Until Aug 6th) $40 At the Door Who: Everyone is welcome, including spouses travelling to Austin with you. Even if it’s your first time, expect to recognize many faces/names from the forums and NI R&D What to wear: I’ve seen everything from flip-flops to evening gowns to... leather hats. (The vast majority leans toward casual clothes suited for the 1mile 95°F 7pm walk) If you plan to sponsor a Door Prize, there is a form field with your name on it during checkout. (See existing Prizes) If you prefer a Vegetarian option, we’d love to have you; there is a form field with your name on it during checkout. Hope to see you there! Chime in on this thread (and the comments section of the Event Page) once you buy tickets.
  • Create New...

Important Information

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