orko

QUOTE (jjurbanus @ Dec 3 2008, 03:50 PM) Thanks, although it is not uncommon in large applications to have a lot more than that. That number should really be upped to 800+, which I'm sure can be topped by many posters here

QUOTE (jjurbanus @ Dec 2 2008, 08:01 PM) The quick answer is: yes. Data has to be wired somehow to the new terminal, so in your example you would be adding new control terminals to the calling VIs of the lower level subVI and wiring it all together. Now, what you may want to consider is how you are organizing the subVIs in your hierarchy. If you look at the project as a whole, there is probably a way to design it a little bit better an get rid of some levels. Creating a subVI for the sake of creating a subVI will get you into this "deeply nested" scenario in a hurry. And if you are putting too much functionality into your subVIs, you will find the nest (hierarchy) will get pretty "tangled" and interwoven. Functionality starts becoming inter-dependant this way which leads to bad juju. The two questions I like to ask myself are, "Does this subVI serve a defined purpose?" and "Will I be using this subVI anywhere else?". If either of the answers is "no", then it may be time to lay the design on the table again and rethink how things are organized. Just my 2c. Hope this helps.

In the array pallete, you will find the Build Array function. Wiring your array and the element you want to add as inputs, you will get what you are desiring here. Another way would be to use the Insert Into Array function, where you have more control of where you would like to add the element in the array. Look in the LabVIEW help for examples and more descriptions of these and many other native LabVIEW functions. Hope this helped get you on the right track.

What??? There are people developing on one monitor still? :laugh: I've been in many different places of employment, and have always made it a top priority to whine until I got my second monitor. Seriously though, having one monitor to handle project windows, front panels, mail, IM, etc, and another to develop the block diagrams makes life *so* much easier. The only beef I have is that as far as I know, there isn't a way to have LabVIEW default to try opening BDs and FPs in your monitor of choice (when available). I would love to be able to always open up FPs and project windows in monitor 1 and BDs in monitor 2, for example. As it stands, each VI appears to have the monitor it was opened up (saved in?) last as it's default.

I recall reading somewhere that LabVIEW doesn't store the "old" picture when it writes a new one with the "erase first" option unchecked. This makes sense, since you wouldn't want every picture to be stored historically in memory (this could be considered a leak), but instead just storing the "flattened" result of all writes. This makes me wonder if LabVIEW is accomplishing the "Erase First" behavior by masking the unused bits of subsequent writes with the background on each write? If so, then masking with a transparent bit (0) would make all of the unused bits transparent, regardless of what was there before. Just a wild stab... I'll be curious to see what NI says.

Congrats, Norm! I'm glad you were able to find a new "home".

QUOTE (Justin Goeres @ Nov 26 2008, 06:22 AM) Perhaps this will help... Several ports of Which are available here. I think that the first one demonstrates how to use the For Loop expansion variables ("%~"), so you could probably just extract out that piece and call a one-liner directly via System Exec.vi.

A common misconception (and a mistake I still make) is to think that by toggling the "Data Change" boolean, you are telling the Xcontrol to execute the "Data Change" event case. The "Data Change" event case only executes when the value terminal is written to by wiring (or using property nodes, or local variables) to the Xcontrol itself on the VI it was placed on. As far as I know, toggling the "Data Change" boolean value in the Action cluster (and someone will correct me if I'm wrong here) will tell LabVIEW to refresh the control values that were loaded inside the Xcontrol. Think of it as a flag for "hey, one of my internal controls has changed it's value." or "Refresh, please." So to make this all work for your application, you would either use local variables to load the two listboxes with their respective values inside each case in which you want to modify them (left/right arrow value change), or perhaps simply move the code that you have in the "Data Change" event case to the "Timeout" case, since that case always executes. I'm no expert when it comes to Xcontrols, but I have had the same problem you had and that is how I was able to get around it. Others may have better suggestions.

QUOTE (yonatan.tidhar @ Nov 25 2008, 08:02 AM) Could you please edit this link? It's currently pointing to your reply to this post

QUOTE (mballa @ Nov 21 2008, 10:00 AM) Unfortunately I haven't used this tool yet. I remember seeing mention of it a while back, but for some reason never got the chance to try it out. I'll see if I can give it a go this week.

QUOTE (km4hr @ Nov 20 2008, 09:30 AM) Ah. A picture is worth a thousand words Yes. Your example is a modern graph that has its border painted transparent, exactly like Ben and normandinf are describing.

Thanks for the link to Jing...I like it! :thumbup:

Thanks for these. 11th place has a special place in my heart...since I used to work in a shipyard and know the mentality behind the "buddy system".

QUOTE (km4hr @ Nov 20 2008, 06:58 AM) Look in the Classic->Clasic Graph palette. They are hiding in there. QUOTE (km4hr @ Nov 20 2008, 06:58 AM) I also see LabVIEW screens that have controls grouped together inside nicely chiseled frames with rounded corners. The frame is a thin line that surrounds the controls. The frame might have a label inside a gap on the upper left-hand corner of the chiseled line. This looks great. How is it done? Try System->System Recessed Frame. I think this is what you are referring to. Placing a System->System Label over the top of this deco will give you that "floating inside the gap" look you are referring to.

QUOTE (asbo @ Nov 20 2008, 06:55 AM) Sometimes when something doesn't make sense, it's because it doesn't make sense My interpretation was that the guys inside were not done loading the truck, but the truck driver thought they were... Classic example of miscommunication....

Outstanding! Good thing they weren't hauling retail! I mean, how are you going to make those carts wobble more? :laugh:

QUOTE (crelf @ Nov 19 2008, 05:31 PM) That would (for the most part) take care of the wire bends and placement, but not the weird conpane and labels. I think I remember a developer from NI (can't remember who) semi-apologizing to me for that tool. Something about it being written ages ago and in great need of a re-write. That was a couple years ago...

QUOTE (Ton @ Nov 19 2008, 12:00 PM) I guess two outs really do make an in... Oh, and I just love the way it makes my wires bend to and fro on the calling block diagram... </sarcasm>

QUOTE (jcarmody @ Nov 19 2008, 03:07 AM) The "Create SubVI" tool has been a thorn in the Edit menu for a long time now. There is no way to control the behavior of this tool, so I only use it to get a subVI started. It is often more of a pain to fix the funky connector pane, un-necessary wire bends, weirdly named labels, and general mess that this tool creates than it would be to just cut and paste the section of code you want into a new VI block diagram.

Hello fellow LAVA members, There has recently been positions opening up as a vendor in the Microsoft Xbox group in Redmond. They are currently looking for multiple people to fill the following roles, and I don't want anyone to miss these great opportunities: LabVIEW Hardware Test Engineer and/or Developer RF Design Engineer Working as a vendor in the Xbox group has been a life-changing experience for me. If you are interested, please respond to this post or PM me your resume and I will directly forward it to people who can give you more information, and are presently eager to fill positions with LabVIEW/RF experienced engineers. I am not a recruiter, but I have direct contact with these people weekly. So I figured, why not give back to the community that has helped me out time and time again? LAVA is full of intelligent, talented people. Exactly the kind of people I want working in my team. ;-) Here is a brief description of Northwest Contract Services: Northwest Contract Services partners with our customers in the development of significant consumer electronics devices. Our employees work on each project until it is on the marketplace and then move on to other newer projects. Our employees enjoy company paid medical, dental, vision, long term disability and life insurance as well as a 401k program. Joe "orko" Sines

QUOTE (orko @ Sep 22 2008, 06:25 PM) QUOTE (PJM_labview @ Sep 24 2008, 10:21 AM) so look at this thread for the VI. Oh yeah...that's where I remembered it from! :-) Thanks for the link, PJM.

Ah. I see. Well, in that case... nope.

I seem to remember that the built in symbols were accessible just like the custom symbols, but with indexes of 0-39 (0 being blank)..as long as you didn't over-write them with your own symbols at runtime. Is this not the case? See here.

I agree that this would be helpful, although I'm not sure of a sane way to implement required inputs for clusters inside clusters. Basically, I would want to be able to either wire each control inside a subcluster up one by one, or be able to wire the "All Elements" in one shot. I suppose it's possible to enforce that all elements are wired. Just not as easy to implement as it first sounds.

QUOTE (pdc @ Sep 18 2008, 01:24 PM) No wonder it seemed like something I hadn't seen before :-)