Jump to content

BrokenArrow

Members
  • Posts

    257
  • Joined

  • Last visited

Posts posted by BrokenArrow

  1. QUOTE(Jim Kring @ Apr 9 2007, 01:11 PM)

    No, the picture is stored as a decoration inside the VI (by value, not by reference).

    That's very neat. I don't recall C++ or Basic being that friendly with regards to inclusion of graphics files. I guess my method of just keeping my BMP's in a development folder for the occasional edit or inclusion in another VI is valid then, i.e. without any real "linkage" to the VI they were originally put in.

    Thanks Jim.

    Richard

  2. FWIW, I genrally just drag and drop a picture onto the front panel or into a picture ring - i.e. I never load it with a picture drawing tool.

    thanks,

    Richard

    :beer:

  3. Yesterday, as a test, I put about 50 or so of these types of VIs in a loop. They were "working" in a true statement. CPU usage in false statement was 0 to 1%. In the true, 1 to 3%. Clicking buttons willy-nilly didn't seem to impact CPU much. As far as speed, I need to research that further, but I noticed no appreciable difference by the naked eye (looking at a loop counter).

    In 5+ years, I have never used the priority settings, aside from playing with them. I'll give that a try, thanks.

    -Richard

  4. QUOTE(Ben @ Mar 27 2007, 08:45 AM)

    A "First Call" node would make sure the first call of this sub-VI would work correctly.

    Very astute.. I am getting some flaky behavior with boolean_transition.vi upon startup, but until now, I haven't cared because my INIT routine takes care of a few seconds of startup anomalies. I think I'll add that, though. Thanks Ben!

    Richard

  5. For several years, I've been using variations of the Boolean Trigger.vi (OpenG boolean tool) and a similar type of thing from Bloomy called boolean_transition.vi (attached for those unfamiliar with it). Then there's Data Changed.vi, and many variations of that one.

    I've been wondering if, by over using these tools, I may be slowing down my apps, or wasting large amounts of resident memory. The VI has to open, run a little loop, and close, and do this over and over (asuming it's in another master loop).

    In a given application, I may use these one-time loop things 20 or 50 times. They are just SO much more convenient than shift registers (the Data Changed.vi comes to mind), and while the Event Structure was a huge plus back n 7.1, there's just no way I can convert my old code - with so many little mini-events nested deep down in sub-vi's.

    One example of where I think I'm overusing [a variation of Boolean Trigger.vi] is when a Push-On, Push-Off button is used to trigger a one-shot event, such as sending a command to a port. The alternatives are a LOT more work. Some of our old code, done back in the mid 90's, uses TWO buttons (one transparent) and two local variables to achieve the same thing.

    Any thoughts on these VI's, and the proper use thereof? Any warnings? Pitfals? Thanks!

    Richard

  6. QUOTE(tcplomp @ Mar 24 2007, 06:05 PM)

    If you are setting the precision to zero you could also use %d as the formatter, this will have the same effect.

    Ton

    That does work, and will likely be the way I go about it, but it involves changing a LOT of node types, and changing the 1's and 0's to %.1f's and %d's ..... it seems a lot less trouble to just gripe about the bug and wait until NI fixes it... :shifty: . I wonder why NI didn't suggest that? (the formatter, not the griping).

  7. QUOTE(Mike Ashe @ Mar 24 2007, 01:59 PM)

    At this point I'd start looking into whether you could use scripting...... .

    post-932-1159825841.gif

    Good idea if it were the math I was concerned about. These Precision nodes are simply receiving a 1 or a 0 depending on the press of a button (thus setting a decimal number control to 1 or 0 digits of precision). It's kind of a silly feature anyway. If a user is smart enough to know what the "Precision" button does, then they are smart enough to know what to do with that 0 after the decimal, if it were there all the time - which is going to be the case now. My boss will undoubtedly want it fixed (i.e. have the buttons back in place) when NI fixes the bug. <waste> :clock: <\waste>

  8. Here's the reply I received from NI. (Don't you love emails that start with Which bug.... are you referring to??..). This bug has cost me HOURS of re-doing some panels and diagrams for our main system -- then I'll have to Re-Do them when NI fixes it. Hundreds of property nodes. (yes hundreds -- it's not my code)

    Richard,

    Which bug with the precision property node are you referring to? Are you

    getting an error when trying to use this property node? Please be sure that

    you set the format property to a value between 0 and 8 before trying to

    write to the precision property node. The bug with writing a 0 to precision

    will be fixed in the next point release of LabVIEW which is releasing soon.

    Regards

    Zach Turner

    Applications Engineer

    National Instruments

  9. QUOTE(Mikkel @ Mar 23 2007, 03:38 PM)

    I always like it when it's not "me" that forgets where stuff is, although I hate when NI moves my stuff, so there's a conundrum for you! Thanks again Mikkel.

    Speaking of "where stuff is" (and this is off topic but I'm too lazy to start a new subject) -- I installed the OpenG stuff, and got a sub-palette called 7.1. Is that just a re-orginization of existing functions, or is there some new or old stuff in there? This is a cool feature, having used 7.1 for 4 or 5 years, but I guess it can be a crutch.

    -Richard

  10. QUOTE(Mikkel @ Mar 23 2007, 01:58 PM)

    Create a new property node, rightclick it, select 'Link to' -> 'Pane'. Click this property node, find 'Origin' and be happy :)

    -Mikkel

    Wow.. is that a 8.2 thing. I could have swore I "picked it" a different way in 7.1. -- but anyway, thanks a lot Mikkel.

    :thumbup: :thumbup: :thumbup:

  11. QUOTE(PJM_labview @ Mar 18 2007, 11:02 PM)

    I'm unsure how to read the value back into the controls - the outputs of the read VIs are variant data. I can read one key at a time, but that would take 50 or 60 key reads!

  12. QUOTE(Aitor Solar @ Mar 19 2007, 10:31 AM)

    Well, I haven't seen that behavior in your example, just a 1435 error code. In fact, when I open your VI, the numeric control already has 0 digits of precision. If I edit the Format and Precision options, I find no problem to put 0, 1, 2 or more digits of precision.

    The only problem arises when I try to modify programmatically the number of digits of precision AND the control has "Automatic formatting".

    Saludos,

    Aitor

    Odd! & you're running 8.2. Sure enough, when I try to put in a 0, it acts like it'll take it, then when I pop back in, it's set to 1. Just like the problem described by the guy in the [wiki]NI[/wiki] posting that I linked.

  13. QUOTE(Aitor Solar @ Mar 19 2007, 05:45 AM)

    That didn't do it. In fact, the Format & Precision propertes box won't let me put the Digitits of Precision to 0! When I enter 0, it always goes back to 1. On another computer, running 7.1, I finally got it to work, but not on 8.2. The property node is still broken.

    edit!--- I just found a reference to the bug (Digitits of Precision not staying on 1) on the [wiki]NI[/wiki] forums. I'm sure this has to do with the broken PN.

    http://forums.ni.com/ni/board/message?boar...d=93089#M204187

  14. QUOTE(PJM_labview @ Mar 18 2007, 01:41 PM)

    I just tried some of this stuff. While it's probably the bee's knees, I can't get it to work. The file is always empty. I probably don't fully understand what they mean by "section cluster". Any examples out there?

    -Richard

  15. Of the multitude of ways to save "settings" to a file, what is your preferred method? Keys (ini), Datalog, Spreadsheet, pure text, etc... they all have drawbacks. Typically, I need to save numeric and string and boolean data - flat or structured, 3 things to 50 or more. The "keys" method gets HUGE (real estate), although the resulting file is elegant. Datalog is simple - just bundle the stuff up and send it on - but the file is unreadable (by eyes) and making changes to the data types in the VI mandates changes to the "file writer" VI. Spreadsheet String to File needs to have numbers converted, then back again.

    Any tips? :throwpc:

×
×
  • Create New...

Important Information

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