-
Posts
257 -
Joined
-
Last visited
Content Type
Profiles
Forums
Downloads
Gallery
Posts posted by BrokenArrow
-
-
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
-
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:
-
-
-
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)
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
-
QUOTE(Mikkel @ Mar 27 2007, 03:41 AM)
Why are you not using the button with 'Mechanical Action' set to 'Latch When Pressed', as far as I can tell, this would provide the same functionallity (if I understood the above correctly)?-Mikkel
'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)
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... . I wonder why NI didn't suggest that? (the formatter, not the griping).
-
QUOTE(Mike Ashe @ Mar 24 2007, 01:59 PM)
At this point I'd start looking into whether you could use scripting...... .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)
It changed in LV8.0 - here is an older thread on this subject:http://forums.lavag.org/index.php?showtopic=3079''>http://forums.lavag.org/index.php?showtopic=3079' target="_blank">http://forums.lavag.org/index.php?showtopic=3079
I remember myself going nuts trying to find it for the first time in LV8
-Mikkel
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)
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:
-
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)
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.
-
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 think you should investigate using [wiki]OpenG[/wiki] code. There are [wiki]VI[/wiki] that makes writing ini files setting trivial with no real estate use (see screenshot below of the help for a vi that takes a cluster for input and does all the hard work for you).http://forums.lavag.org/index.php?act=attach&type=post&id=5227
Below is the screenshot of the palette.
http://forums.lavag.org/index.php?act=attach&type=post&id=5228
PJM
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!
LabVIEW 8.2.1
in LabVIEW General
Posted
QUOTE(PJM_labview @ Apr 6 2007, 12:47 PM)
With THAT many bug fixes, they should have called it 8.3