eaolson Posted December 15, 2007 Report Share Posted December 15, 2007 I don't know how many times I've needed to stop a while loop based on several booleans, as well as an error structure. It's a little thing, but it's kind of annoying: I'd love to see some way to combine the Compound Arithmatic node (in boolean mode) combined with the Stop/Continue node. That would be especially useful if it could be used in conjunction with error clusters as well, rather than having to unbundle the status element first. You can already wire up the error cluster directly to the Stop node, but often that's not quite enough. Something like this: Quote Link to comment
Eugen Graf Posted December 15, 2007 Report Share Posted December 15, 2007 Good idea! Quote Link to comment
Dan Bookwalter Posted December 15, 2007 Report Share Posted December 15, 2007 QUOTE(Eugen Graf @ Dec 14 2007, 11:41 AM) Good idea! I have made that very suggestion in all the Beta programs i have been in , but , the payoff for NI probably doesnt warrant the work to change every boolean operation to accept the error cluster, especially since it isnt such a big deal to insert the unbundle by name , but , damn'it , us programmers are lazy by nature , and thats one of the reasons we use LabVIEW ;-) Dan Quote Link to comment
Justin Goeres Posted December 15, 2007 Report Share Posted December 15, 2007 You can already get 90% of the way there with a subVI. OR Mode: Download File:post-2992-1197654380.vi AND Mode: Download File:post-2992-1197654385.vi Adapting these for the "Continue" side of things and/or bundling them into a polymorphic VI is left as an exercise to the reader . As a side note, something like this might make a good OpenG VI. Quote Link to comment
Mark Balla Posted December 15, 2007 Report Share Posted December 15, 2007 My version of the while loop stop is posted here as well as others Quote Link to comment
tnt Posted December 15, 2007 Report Share Posted December 15, 2007 Hi, what I would also like is to have the option to use the right mouse -> invert boolean in-/output dynamically on EVERY boolean in-/output of the connectorpane. In this way you practically never need to use the invert vi... In Mathlab you can drop a function with 1 input and 1 output on a wire to insert the function in the wire, so you don't need to connect/disconnect the wiring to insert the function. Bye, TNT Quote Link to comment
Aristos Queue Posted December 16, 2007 Report Share Posted December 16, 2007 QUOTE In Mathlab you can drop a function with 1 input and 1 output on a wire to insert the function in the wire, so you don't need to connect/disconnect the wiring to insert the function. Try popping up on a wire and selecting "Insert" in LabVIEW. Does exactly what you're looking for. QUOTE(tnt @ Dec 14 2007, 02:20 PM) what I would also like is to have the option to use the right mouse -> invert boolean in-/outputdynamically on EVERY boolean in-/output of the connectorpane.In this way you practically never need to use the invert vi... We implemented this once in a test version not too many years ago. Push back from many testers, enough that we abandoned the idea, was that the inversion dot is too easily overlooked when reading diagrams and they preferred the visibility of the Not function. If the negate was easily available to VI authors it would create a challenge for VI readers and just add one more item to the list of "practices to be avoided" list Feedback from that test was a major reason why Insert popup menu item was improved to have a shortcut to the datatype palette instead of always going only to the top-level palette.QUOTE(eaolson @ Dec 14 2007, 10:36 AM) Something like this: The compound input to the loop terminal has also been talked about, but it always ends up in the same discussion as wiring the error cluster directly to the compound input. Allowing that raises the hackles of those who favor the existing strong type system of LabVIEW. That idea gets brought up and killed once every couple years. The compound input was debated recently when the For Loop got its upgrade to have an early exit terminal. The ease of getting to the compound boolean function (by popping up on the stop terminal and dropping from the shortcut palette there) was felt to be sufficient. There's a lot of worry about loading up the complexity of the loop structures that are so commonly used by new LV programmers. The For Loop's break is a mode you turn on. We could add a compound mode to the stop terminal, but a that point you've gone through just about the same number of mouse clicks as needed to drop the compound boolean function anyway. Quote Link to comment
Val Brown Posted December 16, 2007 Report Share Posted December 16, 2007 QUOTE(Aristos Queue @ Dec 14 2007, 07:20 PM) ...The compound input was debated recently when the For Loop got its upgrade to have an early exit terminal. The ease of getting to the compound boolean function (by popping up on the stop terminal and dropping from the shortcut palette there) was felt to be sufficient. There's a lot of worry about loading up the complexity of the loop structures that are so commonly used by new LV programmers. The For Loop's break is a mode you turn on. We could add a compound mode to the stop terminal, but a that point you've gone through just about the same number of mouse clicks as needed to drop the compound boolean function anyway. Is there any particular reason to not use the sub-VI approach recommended above? FWIW I like that approach as it retains some "form" consistency, can be reused pretty easily and can be searched for within a project, etc. Quote Link to comment
Aristos Queue Posted December 16, 2007 Report Share Posted December 16, 2007 QUOTE(Val Brown @ Dec 15 2007, 05:00 AM) Is there any particular reason to not use the sub-VI approach recommended above? FWIW I like that approach as it retains some "form" consistency, can be reused pretty easily and can be searched for within a project, etc. No reason not to use it that I can think of. It's a fine approach. In LV8.5, I would strongly recommend that the VI as written be marked as "Reentrant -- share instances". That recommendation will be even stronger in future LV versions as the clone pool managment improves. Basically, there's no reason for this subVI to cause friction between VIs, and yet you don't want the memory overhead of each subVI call having its own instance. The shared clones is a spectacular compromise position for VIs like this one. Quote Link to comment
Tomi Maila Posted December 16, 2007 Report Share Posted December 16, 2007 This is one of those features that can be implemented with XNodes.... Simply use AugmentSelf ability to connect your XNode to the stop terminal of a loop and even place your XNode on top of that stop terminal so that it hides the original stop terminal. Quote Link to comment
gb119 Posted December 16, 2007 Report Share Posted December 16, 2007 QUOTE(Tomi Maila @ Dec 15 2007, 03:37 PM) This is one of those features that can be implemented with XNodes.... Simply use AugmentSelf ability to connect your XNode to the stop terminal of a loop and even place your XNode on top of that stop terminal so that it hides the original stop terminal. I was thinking about an XNode replacement for the compound arithmetic element that would handle mixed boolean/error clusters and also array versions of either. Should be relatively easy to implement. It would even be possible to put back the optional input invert. Add it to my list of XNode projects... Quote Link to comment
Norm Kirchner Posted December 16, 2007 Report Share Posted December 16, 2007 Well I know it's not as flexible as Mark's or as integrated as an xNode But it's still handy, and worth noting Download File:post-208-1197744021.vi Quote Link to comment
eaolson Posted December 17, 2007 Author Report Share Posted December 17, 2007 I should have known that someone would have already had this idea in this crowd. Heh. Quote Link to comment
tnt Posted December 19, 2007 Report Share Posted December 19, 2007 QUOTE(Aristos Queue @ Dec 15 2007, 03:20 AM) QUOTE(tnt)In Mathlab you can drop a function with 1 input and 1 output on a wire to insert the function in the wire, so you don't need to connect/disconnect the wiring to insert the function. Try popping up on a wire and selecting "Insert" in LabVIEW. Does exactly what you're looking for. I knew that already, but I'm mainly talking about actions like for example - data-conversions where several wires need to become SGL in stead of DBL or - several BOOLs that have to be inverted. Then you could use the insert into wire once and then CTRL+drag onto all other wires that need to be changed as well. Grtz, TNT Quote Link to comment
Justin Goeres Posted December 19, 2007 Report Share Posted December 19, 2007 QUOTE(tnt @ Dec 18 2007, 01:17 AM) QUOTETry popping up on a wire and selecting "Insert" in LabVIEW. Does exactly what you're looking for. I knew that already, but I'm mainly talking about actions like for example - data-conversions where several wires need to become SGL in stead of DBL or - several BOOLs that have to be inverted. Then you could use the insert into wire once and then CTRL+drag onto all other wires that need to be changed as well. I kind of like that idea. Programming in LabVIEW involves a lot of dropping of things into other things, like whenever you put a subVI or terminal into a Case Structure or Sequence or While Loop. It would save me quite a few clicks, pretty frequently, if I could, e.g., drag the Invert primitive out of the Boolean palette and drop it right onto an existing wire instead of doing right-click >> Insert >> etc.. :thumbup: That would be especially handy since I usually have several subpalettes pinned open for easy access. Drilling down through the Insert >> route involves a lot of wasteful acquire & track mouse motions when a pinned palette just like the one I need is already on the screen. In fact, I would go so far as to suggest that I currently avoid using Insert >> when the palette I need already pinned, because it takes me longer to drill down than it does to just get the new function I want wire it up by hand (and the Insert operation will just hose up the connections anyway, but that's a heuristic problem ). Quote Link to comment
Aristos Queue Posted December 19, 2007 Report Share Posted December 19, 2007 QUOTE(Justin Goeres @ Dec 18 2007, 01:39 PM) In fact, I would go so far as to suggest that I currently avoid using Insert >> when the palette I need already pinned, because it takes me longer to drill down than it does to just get the new function I want wire it up by hand (and the Insert operation will just hose up the connections anyway, but that's a heuristic problem ). I never pin palettes, so drop vs insert weigh equally for me. But that's my personal take. The stuff I posted earlier is LV's general findings from users. Quote Link to comment
Rolf Kalbermatter Posted December 20, 2007 Report Share Posted December 20, 2007 QUOTE(Aristos Queue @ Dec 18 2007, 06:52 PM) I never pin palettes, so drop vs insert weigh equally for me. But that's my personal take. The stuff I posted earlier is LV's general findings from users. I do pin them down occasionally and intend to keep them there. But I also have a habit to close as much windows as possible so automatically, that whenever I need that damn pinned palette again, it is already gone Rolf Kalbermatter Quote Link to comment
Justin Goeres Posted December 20, 2007 Report Share Posted December 20, 2007 QUOTE(rolfk @ Dec 19 2007, 04:49 AM) But I also have a habit to close as much windows as possible so automatically, that whenever I need that damn pinned palette again, it is already gone I, on the other hand, tend to forget where I put them, and end up pinning open duplicates of palettes! Quote Link to comment
LAVA 1.0 Content Posted December 20, 2007 Report Share Posted December 20, 2007 Its the end of the year and I've been thinking about my library tools (or lack there of). I wanted to brush up on palette and reuse skills, so I expanded on Norm's Error_OR vi. I made it polymorphic to accept combinations of instances and/or arrays of error clusters/booleans. I also added a merge vi that can be dropped in the while loop to include the polymorphic VI and a compound arithmetic node. Download File:post-949-1198081203.zip (LabVIEW 8.0) Quote Link to comment
Norm Kirchner Posted December 20, 2007 Report Share Posted December 20, 2007 QUOTE(LV Punk @ Dec 19 2007, 10:20 AM) so I expanded on Norm's Error_OR vi. I made it polymorphic to accept combinations of instances and/or arrays of error clusters/booleans. Thanks! I was supposed to put the comment that it should be made polymorphic to allow for array inputs. Guess I don't need to now! Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.