Daklu

QUOTE(T_Schott @ Mar 5 2008, 05:34 AM)

Hi,what about creating sub vis for each "block diagramm group"making the code more readable -timo

QUOTE(BobHamburger @ Mar 5 2008, 09:23 PM)

*Ding* You're it! I'm looking forward to seeing what you come up with.

QUOTE

Ctrl-shift-drag makes a copy of whatever is selected. Selecting an item in a group selects the entire group. Therefore, ctrl-shift-drag copies the entire group, just like what happens on the front panel. (That's how I would deal with it anyway.)

It would be handy if I could set front-panel like groups on the block diagram. It would make laying out readable code a bit easier. Not a huge deal, but a nice touch.

Makes me wonder about the "seasoned" programmers the OP mentioned--especially the one who insisted NI's answer was wrong.

Moral of the story: When in doubt, ask LavaG.

Just in case anyone was waiting for this to start... I've decided this idea isn't a worthy Labview challenge. It was ridiculously easy for me, a certified Labview noob, to implement a Graham scan and find the convex hull. Optimization techniques might be a bit interesting, but then I have to worry about differences being lost in the noise and perhaps optimizations working better on some computers than others. The Graham scan was so easy to implement any attempt to created a "Limited" class would be like running a Formula 1 race with no tires. Boring.

Ah well, I keep thinking about the Labview challenge... maybe something good will come to mind.

QUOTE

However, I have event cases in two different, parallel while loops...

That's a problem. Why do you have two different event structures? Best bet is to restructure your program to eliminate the second one. Regarding your specific question it sounds like you might have branched something and one of the loops is operating on a copy. Beyond that I'd have to see your block diagram to see what you are doing.

QUOTE(crelf @ Feb 19 2008, 12:11 PM)

So you want a diagram disable structure that disables the code outside the structure, instead of inside it? That's a freakin' awsome idea! :thumbup:

Wish I could lay claim to it, but that's actually the op's idea. It's a little difficult to explain what I'm asking for. I want to be able to select or otherwise indicate the code segment I am interested in. All the code is executed but only the selected code is "debugged." Any non-selected code that executes while I'm stepping through my selected code isn't highlighted, doesn't display values, doesn't change my view to that to that location, etc.

I created a vi that illustrates the problem I'm hoping this would address. Open the block diagram, click Highlight Execution, and step through the math loop.

QUOTE(gmart @ Feb 19 2008, 03:10 PM)

We've tossed around separating a data change versus a display change for typedefs. More feedback from the community sure helps in decision making.

How much more feedback do you want? I can copy and paste the post as many times as it takes to convince management. :laugh:

I'd like to see a way to have block diagram constants take up way less space. I'll create large cluster typedefs and use them to initialize arrays, with Bundle by Name, or with Variant to Data. Sometimes I'll have real values in them but usually I'm just using them as a typedef. The problem is they take too much space on the block diagram. I know I can change Autosizing to None, which I do; however, every time I make a change to the typedef Autosizing resets to Size to Fit and I have to go back and resize all my constants. I even had to turn off the Auto Grow feature because I got tired of having my block diagrams blow up.

Something like a control-sized icon specifically for constants or typedefs would be fabulous.

QUOTE(PatNN @ Jan 31 2008, 06:28 PM)

Ability to run selected section of the block diagram without having to run the entire VI. This would be a useful debugging feature.

I'd be thrilled if I could simply ignore sections of code while I'm debugging. For instance, if I'm stepping through code that contains parallel loops I'm constantly being shifted around the block diagram to view the next code step when I'm only interested in the code in *this* loop. It gets frustrating.

Late response, but what the heck...

QUOTE(robijn)

I don't get the comparison. Visual studio does not have this limitation, neither has LabVIEW. The view of both are limited by what fits on the screen. You have to scroll in both if the code is too large.

True, the comparison is not perfect. Keeping procedures and block diagrams smaller than one screen are both considered best practices. However, the nature of sequential text languages means having to scroll through code is not as much of a hinderace as scrolling through a block diagram.

Text is easy to digest in pieces. Reading a book isn't difficult even though the text is split across 400 pages. Images are difficult to digest in pieces. Imagine trying to play a game of chess with the restriction that you can only view a 2x2 block of squares at any given time. The game gets much more difficult. The graphical and data flow nature of Labview requires a better understanding of the entire vi--you need to have a better grasp on the "bigger picture" so to speak.

Generally speaking the consequences for violating this best practice are more severe in Labview than in text languages, which equates to Labview effectively enforcing a specific coding style.

QUOTE(robijn)

The current limitation doesn't stop people from writing bad code. It can certainly make understanding bad code harder though. I suppose the question ultimately comes down to whether you think the language should enforce coding conventions. Personally I don't think it should.

One other area zooming would help me is when I'm changing my block diagram layout. Often once I get a VI to be functionally correct I see ways to change the layout to make it more readable. Having to scroll around the screen to find my code segments as I'm repositioning them makes this more difficult.

QUOTE(TobyD)

Currently contracting near you on the east side of the lake. This particular coworker actually brought in his own monitors. He also brought in two of his own computers, his own binocular microscope, his own Metcal soldering station, and various other personal tools. I guess that's a benefit of being 45+ and single... too much disposable income. :laugh:

QUOTE(AQ)

I appreciate the difficulties you mentioned in the previous thread and certainly believe you. Let me refine my request by saying I'd like to see *much* better window management. Perhaps instead of throwing icons all over the taskbar there could a "Windows" tab in Project Explorer with a with a twist down "Show Project Explorer" button on the toolbar.

QUOTE(neB)

we* can get you incontact with someone inside NI that can make it official.

Official? And here I thought it was just a loose, casual competition between forummers. You're going to scare me away with talk of 'officialness.'

QUOTE(neB)

I'll sponser it but it will take me a bit of time to formulate the rules. I'll try to have it ready for kickoff by the end of the month. Off the top of my head here are a few things I am thinking. ('Contestant' refers to the person submitting the VI; 'Competitor' refers to the VI itself.)

• Have two classes for competitors. An open class where anything goes (Wikipedia here I come!) that I'm guessing will end up being a contest of who can squeeze the most performance out of their VI, and a limited class which will include some sort of restrictions that require us to use less optimal solutions. Maybe only allowing a certain number of sub VIs or structures, or ... ? (Consider this a request for ideas.)
  
• Patterns will consist of a few randomly generated patterns created by me at the time of the contest and crafted patterns submitted by each contestant. Open patterns and limited patterns will be kept separate. I will publish the random pattern generator prior to the contest.
  
• Each contestant will be allowed multiple competitors in either class, however each contestant is only allowed to submit two crafted patterns per class.
  
• No special sequences allowed to identify your own patterns. Your VI must evaluate your patterns honestly.
  
• Scoring will be rank based with points awarded to roughly the top half of the competitors. VIs that do not produce the correct answer will not be eligible for points.
  
• An upper time limit will be imposed based on a general brute force algorithm. Any competitor that does not finish within the time limit will not be eligible for points.
  

The number of points in each pattern is a open question. I have no idea how long these VIs will take to run. Ideally the easy patterns will be ~5 seconds with the difficult patterns in the 30 second range. I also have nothing to offer as a prize. I might be able to create a trophy icon or some such thing, but it's unlikely to be anything a person would be proud to put in their sig.

Correct, this is not the travelling salesman problem. I didn't want to do something that had been analyzed to death.QUOTE(Yuri33 @ Feb 14 2008, 11:16 PM)

Off the top of my head, you can drastically reduce the amount of points you need to test by only using those that lie on the "convex hull" of the shotgun pattern. After that, it's probably a matter of determining the longest axis of this polygon and testing a few pairs. This approach would scale very well with vast numbers of points.

Well see, now you're spilling all your secrets. I suppose there are already algorithms on the internet to determine the convex hull, which makes the challenge less interesting. That's part of the reason I suggested having people submit crafted patterns; if you can create a pattern that confuses the common algorithms while making your own robust to it you have an advantage. Maybe this isn't so much a "coding challenge" as a "critical thinking challenge with coding." Can you identify weaknesses in the algorithm and overcome them to improve it?

Mostly though, I'd really just like to see another coding challenge--whatever it is. I got my start in Labview by stumbling across the Tic Tac Toe challenge on the internet in '06. I thought it was fun and find it a way to keep things fresh and interesting.

[Edit]

Eh... after googling "convex hull" I discovered I failed in my quest to choose something that hadn't been analyzed to death. The best thing about the internet is the amount of information instantly available. The worst thing about the internet is the amount of information instantly available. Have all the interesting problems (that don't require a PhD in mathematics) been solved?

Very, VERY cool. Keep it up!

I'm sure you meant the name to be said as, "VI preview." At first glance I read it as "Viper View," with viper being spelled as vipre. (For non-native english speakers, a viper is a general term for a snake.)

This is a problem I've been thinking about for a while and as far as I know there aren't any canned routines to solve it, making it a potentially interesting Coding Challenge problem.

Imagine an XY plot of any number of points placed arbitrarily; something like a shotgun blast pattern. The goal is to find the maximum distance between any two points. Simple, eh? For 10 or 20 points, yes. For 100 points, not bad. What about 1,000 or 10,000 points? The brute force method is an O(n^2) function; can you find something better?

I'm thinking of throwing several random patterns with various numbers of points at each algorithm as well as having each person submit a pattern of their own choosing. It could be random or it could be created specifically to take advantage of weaknesses in other algorithms. For scoring I would probably advocate some sort of ranked based scoring as opposed to cumulative time.

Comments?

Great article Jim! That earns a printout and permanant thumbtack on my cubicle wall!

QUOTE

What folders do you sync?

I've set up sync links with my user.lib directory and the directory I use for working on projects. When I come across a need for a general purpose vi I code it up, add it to a _MySolutionsForEverything directory, and add it to the subpalette I want. Since I'm still a Labview noob my personal toolkit changes quite often. Mostly adding functions but occasionally refactoring, renaming, or just deleting ones that don't work very well. I do all this on my c: drive and sync it up with my flash drive when finished so I can copy it down to my other dev computers.

It's not a perfect solution but it's miles better than what I was doing before. I was trying to do toolkit development on my flash drive. For a while I experimented with using my VIs directly from the flash drive rather than my c: drive but that failed miserably. Mostly I would make changes on my flash drive and copy that down to my c: drive. Ultimately toolkit dev on my flash drive didn't work so well. When I made a change to my toolkit I'd have to copy it down to my c: drive, modify the palette, and then copy the new .mnu file back up to my flash drive.

I do the project work a little differently--all my project dev work is done directly on my flash drive. I sync with a folder on my dev computers as a backup and just in case I forget to bring my flash drive.

Based on the information in this thread I'll probably add a few more files or directories to my sync list.

QUOTE

I haven't done anything with built-in private methods before. How do I find it? (And if it's private, how is it that we can call it from outside whatever class or library it's in?)

--------------------------

In case anyone else ever has this problem, I figured out what was wrong with my Favorites palette. You have to be in a Category or Icon view to add VIs to your Favorite palette. I knew this, so although I use Tree view by default I would switch over to Icon view using the View button at the top of the palette when I wanted to add something to my Favorites. Labview doesn't like this. You have to go into the options menu and change the default if you want to add to your Favorites palette.

I also created subpalettes in my Favorites palette (which is easy to do) but haven't found a way to actually get any primatives in the subpalettes. Is there a way to put Labview primatives on a palette of my choosing?

In the spirit of tips and tricks, here's what I've learned about customizing the palettes. I think it's all correct, but it's very possible I've made a mistake somewhere. I find the help files rather vague. I trust the more experienced users will set me straight.

• \LabVIEW Data\x.x\Palettes\ - This directory contains .mnu files for built-in palettes you have customized via the palette editor. VIs and controls are not stored here. Labview checks this directory on startup to see if there are any custom .mnu files that override the default files. The custom .mnu files are stored in a directory structure that mimics the location of the original .mnu file. In general I believe we should avoid editing these files directly. (I have deleted them before to reenable the default palettes.)
  
• \Program Files\National Instruments\LabVIEW x.x\menus\ - This seems to be where all the default .mnu files are stored. I believe the "categories" subdirectory holds Functions palettes and the "Controls" subdirectory hold Controls palettes. There are several other subdirectories that don't seem to correlate to locations on the palettes. Some addons put menu files here (such as the OpenG toolkit) but I don't know if there are any conventions on what we should put here.
  
• \Program Files\National Instruments\LabVIEW x.x\user.lib\ - Controls and VIs dropped here are automatically detected and placed in the User Libraries subpalette. This is the easiest way to add custom VIs and controls to your palette. Since the User Libraries palette is auto-populated by this directory you cannot use the palette editor to remove controls, VIs, or subpalettes that exist in user.lib. NI recommends most custom VIs go here. If you create a subdirectory in user.lib that subdirectory will automatically show up as a subpalette. Any VIs in the subdirectory will show up in the subpalette. If you create a new .mnu file and place it in user.lib that .mnu file will show up in User Libraries as a subpalette. This is useful if the palette structure you want doesn't match your VI directory structure.
  
• \Program Files\National Instruments\Labview x.x\instr.lib\ - VIs dropped here are automatically detected and show up in the Functions -> Instrument I/O -> Instrument Drivers subpalette. I'm not sure what happens with controls dropped here. This directory auto-populates the Instrument Drivers palette so, like the User Libraries palette, you can't remove subpalettes or VIs from the Instrument Drivers palette. NI recommends you put (you guessed it...) instrument drivers here.
  
• \Program Files\National Instruments\LabVIEW 8.5\vi.lib\ - This seems to be where most of the shipped VIs reside. It's possible NI addon or modules (is there a difference?) are put here too. Maybe third party VIs as well?
  
• \Program Files\National Instruments\LabVIEW 8.5\vi.lib\addons\ - This directory appears to auto-populate the Addons palette in the same way the user.lib directory does with the same restrictions other synched directories have.
  
• Although I said you can't remove subpalettes and VIs from palettes that are automatically populated, I lied. If you right-click on a subpalette icon such as User Libraries while in the palette editor, a context menu will appear with the option "Synchronize with directory" checked. If you uncheck that option you can go into User Libraries and delete things to your heart's content. You need to reenable the option if you want any future VIs in user.lib to automatically appear in the User Libraries palette. (Of course, if the items you deleted from the palette are still in user.lib they will show up on the palette again.) I frequently use this technique to remove missing subpalettes (the ones with the big question marks) that I otherwise can't get rid of.
  
• Like tcplomp mentioned, in a directory that is synched with a palette, prepending a subdirectory or filename with an underscore ("_") will prevent Labview from putting that item in the palette. (In fact, I think I learned that from his Code Capture tool.) This can be a good way to keep your User Libraries palette from getting out of control.
  
• Many of the menu directories have a 0 byte file named readonly.txt. I believe if you delete that file you get more control over the palettes contained in that directory. I haven't experimented with this much so use at your own risk.
  

There are a few things I'm still trying to figure out:

• I'd like to organize my VIs and add subpalettes to my Favorites palette. Unfortunately I broke something somewhere and now my favorites palette remains perpetually empty. Resetting my palettes to default didn't help.
  
• I'm sure there are conventions on which directory (user.lib, vi.lib, and vi.lib\addons) to use when you are distributing VIs, but I don't know them. I've seen things put in all three. Anyone have ideas on the rules here?
  
• I'm under the impression that you can add items to the Tools menu by putting a .mnu file in the right place. No idea if that's right or not. In any case the Tools menu looks to be reserved for VIs that are executed (wizards, etc.) rather than VIs used in a block diagram.
  
• In Labview documentation I've seen references to "addons," "modules," and "toolkits." Are these synonyms or is there a real difference between the three? Does the "correct" distribution location depend on what your VIs are categorized as?
  
• tcplomp, you mentioned firing app.palettes.refresh a couple times. I've looked for it in the application property and invoke nodes but haven't found it. Could you explain how to do that?
  

QUOTE(Neville D @ Feb 8 2008, 09:22 AM)

I don't think pallet info is stored there. I know some pallet info is in your /LabVIEW Data/8.5/pallets folder. I agree, it is quite annoying when you have multiple installations, and all the pallets are just slightly different enough to be frustrating.

I develop on multiple machines too and use sync software to keep projects and palettes updated across them. When I'm done with a programming session on one computer I sync with a flash drive and use that to sync with the other computer. A couple sync programs are SyncToy (free) and Syncback ($30).

QUOTE(Yen @ Feb 7 2008, 12:55 PM)

Since the tab can't change...

There's the rub. This is for a piece of test equipment that will very likely need to be expanded in the future... near and/or far. It is probable that someone else will rearrange the order of the tabs. Since I reference the tab value all over the place it would be easy to miss a required change somewhere. This really isn't *that* big of an issue. I have a work around in indexing the tab control out of the array before I send it to a sub vi. Mostly I'm trying to make it idiot-proof when it comes to maintenance and expansion. (It's pretty embarrassing to break your own code and not know why. Or worse, break it and not know I broke it.)

Thanks for the system/Labview control tip. I'll be sure to change it.

QUOTE(Doon)

Ding! I know some idiot (like me) is going to change things around and screw it up. Like I said, not a big deal. It's just easier to maintain and understand my code.

As I sit here and think about your post, I realized I'm trying to make my data self-aware. If my data knows what it is, then my sub vi's and process loop states can operate on them correctly rather than requiring me to tell it what's coming. I have no idea if that's a good idea or not... I didn't even realize I was it doing until now. I'll have to think on that for a bit.

QUOTE(Yen @ Feb 7 2008, 11:47 AM)

Maybe it's just me not understanding, but if the controls are all hovering over the tab control, what use does the tab control have? Why not just use a bunch of buttons or a listbox to indicate which "page" was selected? Can you post an image of the FP?

Why? Primarily it's a ui asthetic design issue. Plus buttons wouldn't give me the advantage of an enum. I could use an enum with a drop down box, but it's not really the right control from a ui design standpoint. (Switching tabs shifts data categories. Switching the alias, also a drop down box, changes the data within the category. Switching data categories is a bigger change and should be reflected in the ui.)

Also, since I've already structured my program around tabs I'm reluctant to go back and change it. I suspect it wouldn't be that big of a deal but I'd rather not.

Now lets see if I can attach an image...

QUOTE(crelf @ Feb 7 2008, 10:40 AM)

Right - the tab control/indicator is just an enum that other controls can bind to on the front panel - that's really the only relationship they have. The tab constant is a block-diagram-only node, so it's not bound to anything else, so it can be freely used as an enum constant.

But the fundamental problem is I can't use that enum in an array as an input to a sub vi, because tabs can't be in an array unless they are a constant. (And of course they aren't constants when they are a sub vi control input.) I'd like to have the advantage of using the tab enum in my sub vi's AND I'd like to use my tab state array in those sub vi's. They appear to be mutually exclusive desires. Is there a good work around?

I have an application with several tabs each of which uses the same controls. Functions change depending on what tab is active. To simplify coding I created a single cluster of front panel controls and put it on (as opposed to in) the tab control. Now I have only a single copy of each control and I can direct the program flow by getting the value from the tab control.

Each tab needs to remember the state of all the controls the last time it was active so when the user switches back to that tab all the settings and values are the same way they were left. To be "smart" I bundled the tab control (which I typedef'd) with the cluster of front panel controls and put that in an array constant on my block diagram. Each element correlates to one tab on my tab control. I use the tab control in the array element to identify which tab that element is storing information for.

This works great until I tried to create some sub VIs to handle lower level chores. It turns out Tab controls/indicators can't be put in arrays or clusters. (But Tab constants can...) So my question is, is there a better way or "best practice" to store tab states? I thought about creating an enum typedef with just the tab names, but if the tab control or tabname control get out of order subtle bugs will be introduced that may not be noticed for quite some time. I've worked around the issue for now by pulling the tab state element out of the array before sending it to a sub vi but it's not an ideal solution.

You guys are great! Not only do I get my questions answered, but I get answers to the questions I didn't know to ask! :thumbup:

It turns out I'll probably skip the Perforce solution and go with SVN/Tortoise. The biggest advantage of Perforce is the Labview integration, and since most of our licenses are Full I don't think they can integrate scc anyway. Plus $800 a seat is a big pill for my manager to swallow... especially when there are internal solutions we could get for free.

QUOTE

Have a look at the section "Setting up a Server >> Svnserve Based Server". It looks a bit complicated at first, but in the end it's only a small list of steps you have to follow. As long as you are not afraid of the command line, I don't see a problem ;-)

Usually I can figure things out so I feel like an idiot asking the question, but which binary am I supposed to download? Tortoise 1.4.7 is supposed to work with SVN 1.4.6, which I can't find. I see 1.4.5 and various dev libraries for 1.4.6... ?

Right now it's only me using the depot installed on my laptop. I anticipate moving the depot to the same server that hosts my Labview installation files sometime in the not-too-distant future. There is an outside chance additional users (maybe 5-10) will be storing their Labview source in the depot once I do that. (In fact, we have enough key Labview tools right now that I'm going to encourage it.) In general we will not be having multiple people working on the same project, but each engineer has several projects going at any one time.

Just to throw a little twist in, I'm currently contracting at Microsoft meaning I could easily get VSS free. When I was looking at that I came across some comments about having to embed some text in the vi's to prevent corrupting the depot. It was a while ago so I may be misremembering, but it was enough to scare me away from that solution.

I really do like the SVN option since it is more intuitive for our main users, engineers. Unfortunately I suspect running Apache on corpnet would violate IT policy. Apparently SVN can run under a separate server that doesn't require Apache, but I don't know enough about that to say whether or not it will work.

QUOTE

Instead select the files (or directories) you want to get rid of in P4Win, right-click and select "Open for Delete" (they must not be open for edit at this time!). This deletes them immediately from your local disk, but not from the depot yet. Deletion in the depot happens when you submit your changelist, which contains a new "delete" action for every deleted file.

Doesn't this leave an open changelist waiting to be submitted? I think it would annoy me having semi-permanent changelists cluttering up my interface.

I have been playing around with the palettes trying to figure out exactly how I want to add my personal toolbox vi's to it. I have a problem now that has me quite frustrated. I had several sub palettes in the user.lib directory that I have since deleted; however, the sub palettes still show up in the User Libraries palette with a big question mark indicating they do not exist. When I edit the palette set and right click on the question mark icons I do not have the option to delete them. How do I get rid of them?Found a resolution. When I am editing the palette set and come across a non-existant sub palette that I can't delete, I right-click on it and select sychronize with directory. That frees up all the missing palettes and lets me delete them.

Thanks for the replies. I'm definitely learning more as I go along but then I hit roadblocks that stump me.

1. Is there a way to create a directory structure in depot other than by creating it in my workspace and adding it? I'd really like the depot to have an organized structure but have each project directory in the depot, which may be several layers deep, to map to a directory in my root workspace. I've played around with the mappings but so far haven't been successful.
   
2. I successfully got my projects in the depot. To experiment I went back and deleted the files in my workspace. The process for getting the files back into my workspace seems awfully weird. I have to go into my depot and check out the files I want followed by reverting them. Only after I revert them will they be copied to my workspace. Then of course I need to check them out again. Isn't there a more straightforward way to do this? (Edit: I tried "Get Latest Revision" but that didn't do anything.)
   

(FYI, I was doing all this through the P4V client program, not Labview.)