jdunham

QUOTE (labviewnoob @ May 19 2009, 06:20 PM) Make sure you learn about auto-indexing of FOR and WHILE loops. There should be plenty of examples in the LabVIEW Examples folder.

QUOTE (shoneill @ May 19 2009, 03:19 AM) I also have to pipe up and say that some of this wouldn't be needed if the default probe information shown on an object's wire could be made visible on the VIs front panel. The relative difficulty of debugging is a serious barrier to adoption of LVOOP.

QUOTE (Gary Rubin @ May 18 2009, 09:35 AM) If you use the color picker tool, and type "F" you change the foreground color only, and then press "B" you will change the background color only. Those give the same behavior as your posted vi. I agree that what NI defines as "foreground" and what they call "background" is not intuitive, especially for booleans, but it has always been like this.

If you right-click on the pict ring you can import pictures from your clipboard.

You could also use use a subpanel control sized to fit the pane to the left of your splitter. Then make a new VI with the controls on the left side and put that VI into the subpanel. Then when you want to print, just print the new subvi rather than the main VI. You probably have to move some or all of your block diagram code into your new subvi, so this only works if your code is modular enough to change the block diagrams.

QUOTE (Michael Malak @ May 14 2009, 02:57 PM) One thing no one suggested was subpanels. It's kind of an advanced LabVIEW topic, and I wouldn't normally recommend it for a self-proclaimed new user, but I think it gets you closest to what you need. You can't have an array of subpanels, but you can drop 12 of them on your panel. First I would try it with two and see if it's feasible. Here's what you could do: 1. Drop the Subpanel controls on your front panel and arrange them. 2. Make a new VI with your graph on the front panel, and select Fit Control to Pane by right-clicking on the graph. 3. Make this VI reentrant in the VI Properties -> Execution. This will enable you to create clones of your panel. 4. Run Open VI Reference with Options = "8" once for each graph you need, and then pipe those references into the SubPanel nodes on your diagram. 5. Figure out some way to get the data into your cloned panels (there are lots of ways). You could use notifiers named for each clone name, or else you could obtain the control references for each with a few VI server calls and then send data into the Value property of those control refs. Oh curse the day I read your post, Michael Malak! It was an interesting problem, so I had to code it up. I didn't close any references (probably doesn't matter), nor handle any errors (there are none), and I only added comments where the code was completely obscure.

QUOTE (angel_22 @ May 14 2009, 05:40 PM) Well it looks correct to me, but it's just kind of unfinished. Though maybe you want the dehumidifier ON when humidity is high. So isn't there anyone at the university who is paid to help you figure out your homework project, like a Teaching Assistant? I'm not sure this board is the right place to get all the support you need.

Can you show us what you have tried already?

QUOTE (Aristos Queue @ May 7 2009, 12:16 PM) This has been bugging me lately and I finally put my finger on it. The autoconversion is neat, but really, 100% of the time, I know exactly whether I want a float or an integer, and it would be so much easier to have both on the FP and BD palettes rather than trying to trick LV into giving me the right choice. I'm not saying that you have to put all the possible numeric types on the palette, but putting all the most commonly used ones on (both of them!) would have been awesome. Trying to hide that stuff and be clever about automatic conversions is not that valuable to me. I think LV suffers from a bit too much of this in a 'don't scare the newbie' philosophy. Maybe it needs to be that way, but it would be great if there were more ways to get past that and end up with advanced palettes with more useful stuff for the advanced users. While we're waxing philosophical, why do the time formats always default to AM/PM? Who finds that useful?

QUOTE (Aristos Queue @ May 8 2009, 12:01 PM) But that doesn't work. If the STOP test returns false, the answer is off by one. Incrementing 'i' is easier. I knew you couldn't trust the "N" terminal any more (found out the hard way) but I figured that was by design. QUOTE (Black Pearl @ May 8 2009, 09:18 AM) To push that point a bit further, I think that for loops of iteration 0 are potential troublemakers. If you don't use a shift register, you might end up with default data instead of the real data (happend once to me with a reference). I'm shocked that only happened to you once. It's a huge problem and we make sure during code reviews that the error cluster and any refnums ALWAYS go through a shift register unless there is a commented reason. Often I don't take refnums out of for loops because its so unsafe. I just fork the wire before the loop. QUOTE (Gavin Burnell @ May 8 2009, 02:06 PM) Attached below is an XNode (LV 8.5.1) that implements this for all numeric types and also when the A input is an array. Part of me wants to say hooray! and part of me wants to cry. The latter part is the part that tries to defend LabVIEW as a 'real' programming language. Thanks for submitting!

QUOTE (Yair @ May 8 2009, 12:33 AM) QUOTE (TobyD @ May 8 2009, 07:17 AM) You could submit this as an OpenG candidate. Well the problem is I need it compatible with DBLs, I32s, I16s, Complex DBLs, XY points, and XYZ points, and arrays and clusters of all of those. It's easier to just do it with the plus and minus functions, but it can really make a mess. Obviously LabVIEW should allow functions with true polymorphic inputs, but while I'm waiting for that, I thought maybe they could throw in the PlusAndMinus for me.

QUOTE (Aaron L @ May 7 2009, 05:26 PM) There's no good way to add a label directly to a wire. The best thing to do is wrap your XML call in a subvi. Then the wire will take the name of the input control to your subvi. If you simply must change the label on a wire, you can use a typecast. This works fine, but it's more of a hack than something you should do regularly. http://lavag.org/old_files/monthly_05_2009/post-1764-1241747281.png' target="_blank">

QUOTE (Neville D @ May 7 2009, 12:19 PM) Thanks, I knew about that. But what I really want is this... (And I've already suggested it to NI, but you never hear back about that kind of thing). This construction comes up all the time if you use picture controls, or you do GUI arrangements, any kind of 2D coordinate stuff, or histogram bins, or limit testing... I know it sounds like feature bloat, but having a native function for this would lead to much cleaner diagrams.

QUOTE (Gary Rubin @ May 7 2009, 11:08 AM) No, you could change it with the Operate tool. But I guess that was non-obvious enough that it was easier to add a TRUE version to the palette than to try to educate people.

QUOTE (Gary Rubin @ May 7 2009, 10:09 AM) I remember changing the constant in front of someone who had used LV for several years, and he exclaimed ,"I never knew you could do that! I always put a NOT function after it." Maybe he wasn't the sharpest tool in the shed, but I'll wager he wasn't alone, so NI put both of them in the palette (in the old days there was only the False constant). QUOTE (neBulus @ May 7 2009, 10:30 AM) When we wire a error cluster to a case it puts the code in the No Error Case When we create an sub-VI with an error cluster the error in is optional while all other inputs are required. Insert node on a reference wires to the refence input instead of the error cluster... I thought these all got fixed from earlier versions when they were much more annoying, but I would agree, the changes were welcome. I wish that when replacing Multiply (for example) with Compound Arithmetic, then the multiply option would automatically be chosen. I also wish that when using Create SubVI... that the Error In and Error Out terminals would be named correctly. I wish there was a simpler Array Size primitive that just resized itself for the number of dimensions. I wish there was a simple PlusAndMinus primitive with two inputs and two outputs. I wish that Merge Errors.vi was a resizable primitive.

QUOTE (Black Pearl @ May 5 2009, 12:17 PM) It's my opinion that UML doesn't add much to LabVIEW development, but maybe I haven't given it a fair shake. While I realize LabVIEW and UML have different purposes, I feel I can design well enough in LabVIEW that I don't need to waste engineering resources (i.e. my time) on a second set of graphical program expressions. You may be right that you don't need to build your labview nightly, since it compiles all the time. But the underlying tenet is that you try to make sure your code (at least the trunk version) is nearly always in a state where it could be released, perhaps with many features missing, rather than getting into a pit where it is broken for weeks at a time. On our project we build an EXE, so we do have a nightly process to build it if there have been any SVN checkins. Ideally you will have automated tests running against the nightly version while you sleep. (Still working on that!)

Hey Cousin Pete: QUOTE (pete_dunham @ May 6 2009, 09:44 PM) First of all, you should generally use the conversion functions shown in place of a typecast. QUOTE (pete_dunham) 2)The same code as 1) but as a SubVI. This initially works...UNTIL I update the TypeDef. This results in a broken arrow ... So I infer from this code that the control reference is a static reference that is not dynamically linked to the control? Is this correct? This seems like a limitation from passing type def. control references through subVIs...as the Control Ref is not dynamically updated (the subVI sink is looking for a different source if type def updated). What you want to do is change the subvi control reference input to a more generic class: Then you can pass any data type in there, and just check at runtime to see whether it contains any booleans.

It seems like the VI Analyzer will make short work of your attempts to hide code, so personally I would choose a different approach for keeping secrets secret. At the very least make sure there is lots of other stuff on the diagram, but in general, steganography is never as secure as cryptography.

QUOTE (Black Pearl @ May 6 2009, 09:37 AM) Umm, what problem are you trying to solve? If its for fun or are you looking for the best way to hide some intellectual property?

Maybe its for bigger groups, but I would start with http://www.amazon.com/Software-Project-Sur...5705&sr=8-1 There's probably 10,000 books like it. Also make sure you score decently on the Joel Test

If you can access this via VIs then you have all the hooks you need to have a build vi that sets the conditionals and calls the .exe builder you want, or even the full sequence for a complete build. Sweet! You might want to check out this post (message#2)

QUOTE (ShaunR) I don't know all the details of LabVIEW threading, but I learned a lot from these forum discussions: http://forums.lavag.org/Parallel-execution-t10870.html http://forums.lavag.org/Templates-t13200.html QUOTE (ShaunR) Indeed. From this thread I have gleaned that UI events (and indeed labview events in their entirety) aren't really have what I would consider "proper" events. My definition would be that defined by NI VISA as the callback event. Visa Events in NI Visa QUOTE (http://www.ni.com/support/visa/vevents.pdf) It is important to note that because of the dataflow programming structure of LabVIEW it is not possible to use the callback mechanism of event handling in LabVIEW. That's an interesting quote. I think just shows that the NI VISA team is not on the forefront of LabVIEW development (to be fair, I don't know how old that doc is). Their API could easily accept a VI reference and invoke VI.Run on it when the event happens. They could also accept an occurence or a queue refnum, but I think it would make more sense to do the VI reference. Then inside that VI you could invoke whichever queues or notifiers or occurrences (or polled globals) you need to interact with your running processes. LabVIEW with a callback (which you can also implement in your own code with a private notifier or a VI reference) is no less event-driven than C code with a callback. Jason

QUOTE (manojba @ Apr 29 2009, 03:45 AM) 1) It's better to make the boolean transparent instead of matching the background. Then if you are using system color or if you change the background, it will always work 2) Use the boolean's "Boolean Text" property rather than just a string overlaid on your boolean. Then the whole thing will be clickable.

Here are two other ideas: One is to enable "update while typing" on the string control. Then you will get the value changed event after the first letter. Maybe not quite what you want but easy to do. The other is to cover the string with a transparent boolean. When the user clicks the boolean (thinking they will click into the string underneath), you hide the boolean (visible=F), set the string's Key Focus to true, and then show the virtualkeyboard. Whenever the virtual keyboard goes away, you make the transparent boolean 'visible' again.

Please don't feed the 'bots.