BrokenArrow

QUOTE(PJM_labview @ Apr 6 2007, 12:47 PM) With THAT many bug fixes, they should have called it 8.3

QUOTE(Jim Kring @ Apr 9 2007, 01:11 PM) 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

I have noticed that, when building apps (exe's) in LabVIEW that use pictures (say, BMP's in a picture ring and a few JPG's for decoration), the picture files do not need to be mentioned in the build spec or even included on the target computer. My question is, where did these files go? Should I include the BMP's and JPG's in the distribution? 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:

QUOTE(Ben @ Mar 29 2007, 04:00 PM) I took 4 semesters of German in college, and all I can say is "where is the drug store? I've been horribly mangled in a train wreck".

QUOTE(Aristos Queue @ Mar 29 2007, 10:36 AM) Good point! Why update front panel indicators that aren't used? That's LabVIEW 101... And I'm on LabVIEW 102. Been there for 5 years....

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

QUOTE(Ben @ Mar 27 2007, 08:45 AM) 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

QUOTE(Mikkel @ Mar 27 2007, 03:41 AM) 'Latch When Pressed' doesn't leave the button 'pressed in', showing the user that that thing has happened.

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

QUOTE(tcplomp @ Mar 24 2007, 06:05 PM) 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... . I wonder why NI didn't suggest that? (the formatter, not the griping).

QUOTE(Mike Ashe @ Mar 24 2007, 01:59 PM) 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>

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

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

QUOTE(Mikkel @ Mar 23 2007, 01:58 PM) 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:

I can't find the attached Property Node: Front Panel:Origin, in 8.2. But, I can copy it from one of my older VIs, and it works fine. Any thoughts? Thanks.

Thanks PJM and everyone !! :worship:

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!

Thanks Aitor. Yep, SI may work, but the users will go nuts. It may be easier to lock it on 1 digit after the decimal and tell them to get used to it. This isn't going to go a long way in proving that the conversion to 8.2 is worth while.

QUOTE(Aitor Solar @ Mar 19 2007, 10:31 AM) 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.

OH! Clusters within a cluster, now I get it. Excellent, thanks.

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

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

PJM, that looks sweet. I didn't think to look in the [wiki]OpenG[/wiki] stuff. Since migrating to 8.2, I've been busy converting old programs, and haven't taken the time to install OpenG, VIPM, etc. My loss. Doing it tomorrow.

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?

Hello all, I was having problems with programmatically setting the precision of a numeric control in an old 5.1 app after conversion to 8.2. So I isolated the issue into a simple VI - now I'm getting errors that don't make sense. See attched VI - does it work for you? Thanks!