Jump to content

crelf

Members
  • Posts

    5,759
  • Joined

  • Last visited

  • Days Won

    55

Everything posted by crelf

  1. QUOTE(Jeff B @ Jun 14 2007, 01:29 AM) No need to apologise at all Jeff - that's what LAVA is here for Thanks for the update.
  2. QUOTE(Ben @ Jun 13 2007, 10:56 PM)
  3. QUOTE(rolfk @ Jun 13 2007, 02:23 AM) I agree that the performnace improvement can't be particularly significant, so my questions become: why was it mentioned in a NI Developer Days presentation? Was it added as filler? Is there a platform where it does make a significant difference that we're not thinking about? Why was it mentioned at all? Why does anyone care about Paris Hilton's jail time? All true mysteries of life...
  4. QUOTE(Michael_Aivaliotis @ Jun 13 2007, 05:58 PM) Dsamn straight - you've gotta know what's important in life...
  5. QUOTE(rolfk @ Jun 13 2007, 03:31 AM) I had one of these babies - the Commodore 128. Unfortunately, not many of my friends could play the games I wrote, since they all had 64s...
  6. QUOTE(Ben @ Jun 13 2007, 01:32 AM) That's just crazy enough to work!
  7. QUOTE(h1voltage @ Jun 13 2007, 12:52 AM) Hi Zack - unfortunately, there is no native way of setting an individual control's transparency, and I'm pretty sure there's no non-native method either.
  8. QUOTE(rolfk @ Jun 12 2007, 05:10 PM) I agree, but I'd like to know whether it is nanoseconds, as you suggest...
  9. QUOTE(Michael_Aivaliotis @ Jun 12 2007, 12:08 PM) :thumbup: Sweeeet!
  10. Well said Rolf :thumbup:
  11. QUOTE(Ulrich @ Mar 9 2007, 12:52 AM) Your colleague is ignorant: LabVIEW allows you to be as close, or as far away, from the hardware as you are comfortable with.
  12. QUOTE(Michael_Aivaliotis @ Jun 12 2007, 02:44 PM) I wouldn't miss it.
  13. QUOTE(orko @ Jun 12 2007, 05:20 AM) Congratulations orko! Ready for the CLA?
  14. QUOTE(JFM @ Jun 12 2007, 03:50 AM) Thanks! Although my reader filtered posts in this thread, the "new posts" counter would still increment, so I'd get excited that someone has posted a new knowledge nugget, only to see nothing there That said, it seems that the thread has turned for the worse with a bit of personal attacking going on over here: I leave you all along for a few days, and look what happens!
  15. QUOTE(PaulG. @ Jun 12 2007, 01:07 AM)
  16. QUOTE(alfa @ Jun 11 2007, 02:54 PM) Push out the stress, return with the beachball...
  17. QUOTE(Ben @ Jun 11 2007, 10:41 PM) That's what I'm trying work out
  18. QUOTE(Aristos Queue @ Jun 11 2007, 01:58 PM) Thanks Aristos - do you, or anyone else you can find at NI, have anything to add about the "required" vs "recommended" terminal debate? I think, without inside knowledge, the rest of us are just guessing at this point...
  19. QUOTE(Wolfram @ Jun 9 2007, 12:56 AM) http://forums.lavag.org/index.php?act=attach&type=post&id=6052''>http://forums.lavag.org/index.php?act=attach&type=post&id=6052'>http://forums.lavag.org/index.php?act=attach&type=post&id=6052 I might make it a bit more comprehensive and upload it to the LAVAcr...
  20. QUOTE(yen @ Jun 8 2007, 06:20 PM) I remember about a year ago someone posting a .NET method of doing this... (?)
  21. QUOTE(Jim Kring @ Jun 8 2007, 02:02 PM) Doesn't "SOFTWARE" mean LabVIEW itself? Are the VIs we create part of that? QUOTE(tcplomp @ Jun 8 2007, 02:07 PM) I think Ben means that is you want to make good (and) fast use of in place work on data that goes in and out (like an +1 operation) it is best to set the terminals on the bare block diagram. Meaning not inside any structure (like an error testing case structure). I see - yep, that makes sense... QUOTE(Tomi Maila @ Jun 8 2007, 05:33 PM) Let's see what could happen under the hood of LabVIEW. If we have a subVI with a required connection, LabVIEW compiler knows that it always has an input buffer connected to the required terminal. On the other hand for a VI with a recommended or optional terminal LabVIEW doesn't know at compile time if a buffer is connected to the input terminal. So LabVIEW needs to insert a snippet of code to allow both options. That makes sense to me. QUOTE(yen @ Jun 8 2007, 06:43 PM) See Greg's (!) explanations in this thread. That's a most-excellent thread - thanks for the link! :thumbup:
  22. QUOTE(Jeff Plotzke @ Jun 8 2007, 11:53 AM) Nice job Jeff - just as I expected. I wonder why the people I spoke to today saud they'd all heard the NI employee say it? I hope it was just some sort of misunderstanding...
  23. QUOTE(Ben @ Jun 8 2007, 06:54 AM) What does that mean? QUOTE(Tomi Maila @ Jun 8 2007, 07:11 AM) In theory required inputs can be optimized better at compile time of the VI. For not-required inputs VI needs to create a memory buffer for the particular input. For required inputs VI can more easily reuse the input buffer. Can you flesh this out a little more Tomi? I *think* I know what you're trying to say, but it's not completely clear... QUOTE(crelf @ Jun 8 2007, 06:30 AM) ...NI Developer Days session comment that changing the status of a connector pane terminal from "Optional" or "Recommended" to "Required" made it more efficient... Anyone form NI care to comment on whether this is in a NI Developer Days session?
  24. I just heard an interesting tidbit at a local LabVIEW User Group meeting: one of the attendees said that he'd heard an NI presenter at a recent NI Developer Days session comment that changing the status of a connector pane terminal from "Optional" or "Recommended" to "Required" made it more efficient (I'm not sure if that meant memory or speed or both). Anyone heard of this one?
  25. QUOTE(Jeff Plotzke @ Jun 7 2007, 03:33 AM) I get a big dose of fiction some times when I read customer "requirements"
×
×
  • Create New...

Important Information

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