torekp

Thanks LV Punk. I forgot to mention, my VI automatically increases its decimation factor every time it gets "filled". Say you start out by capturing every item ("frequency to write VIG" = 1). After the allotted space is filled, it becomes every 2nd item; then when filled again, every 4th; etc. When the calling VI terminates, the functional global is filled with items number 0, 8, 16, etc. (for example), although there will likely be a few leftovers from the previous decimation (item #28, say, which is divisible by 4 but not by 8). This lets me keep a tight lid on the allocated memory, and get a representative sample of the history, without having to know in advance how long the top-level VI might run.

I've developed a "functional global VI" to store a representative sample of raw data throughout the history of a run. It works, but it seems kind of klutzy. Also it requires the calling VI to keep a, whaddaya call, double shift register (where you use the time-before-last-time's value) to decide whether to log a given data set. So ... please suggest improvements. Thanks in advance. Download File:post-4616-1170851012.zip

Excellent. :worship: I think I'll try making the larger graph "hidden", and see if that works, or maybe put it on a separate tab in a tab control. Actually, it might be nice to have that zoomed-up graph available on the GUI, so tab control it is.

OK, I just discovered a new toy with the Labview report generation (html reports). I used to write data to text files named with ".xls" extensions, then do my graphs in Excel. What was I thinking?? OK, so there are a few potential benefits to that approach if you want to do a quick recalculation, but... :headbang: What I want to do now is just add the images of my Waveform Graphs to an html report. But, I want to make the details resolvable - I want the graph to be larger in the report than it normally is in my GUI. There are several graphs in the GUI, not to mention buttons and labels that don't need to go in the report, so the graph needs to be kind of on the small side in the GUI, most of the time. Should I add a button to my GUI that resizes and repositions the graph before adding its image to the report? Or is there some way to manipulate the size / resolution of the image as (after?) it's added to the report? I just know there's someone out there who has figured all this stuff out, at least better than I have.

If the above solutions are working for you, ignore the following advice. Some people on LAVA have recommended that when you write a file that has both header and data, you start the data at the Nth character where N is a nice round number large enough to cover any possible header you would want there. If you really want to get fancy, you can pre-write the file with blank header and data before your main code executes, to speed execution (reduce time wasted on file space allocation). Note, I haven't tried these tricks yet, but they sounded smart to me.

Do you want the whole displacement history during the experiment, or only the final displacement? Taking the simple cumulation of values and multiplying by dt gives you the "rectangle method" approximation of an integral. Unless you have very particular timing constraints at the start and end of your experiment, I don't see any reason to prefer the trapezoidal approximation to the rectangle approximation. (In other words you don't need to single out the first and last data points for special treatment. ) But if you know that the time period you care about begins exactly at the time that your first data point was taken and ends at exactly the time of your last, then the trapezoidal approach is more accurate, especially for a very short series of data.

If I understand what you want, you should try the function "Integral X(t)" in the mathematics -> Integration and Differentiation Palette. But you have to have Professional edition(?) of LabView for that. If you only have basic Labview, try this (Labview 6.1); you'll want to use the DBL input and output and ignore the i32s. Download File:post-4616-1167740730.vi

If you use classes and datalogs, as mentioned in this thread, you get the advantage that whenever you add to your list of configuration conditions, you can still read older configuration files. The new items that do not exist in the old files will be assigned their default values, when you read from an older file.

I decided to go with classes, partly because it was relatively easy, given that I was already using datalogs. Using TDMS would have required me to stop bundling disparate data types into clusters. And I just know I'm gonna love the automatic revision-tracking feature. Thanks Aristos!

Whoosh! That's the sound of your website going over my head. Well, mostly. Still, I might come back to this, depending on how I fare with TDMS. Actually, TDMS file write primitive can't handle my cluster as-is. I'd have to separate it back into its component arrays, though I could group a few sets of arrays that are the same length. I'd also have to add a numeric to keep track of the variable length of certain arrays. For some of my arrays, it's always a certain number of points per write, for others, not. Datalog was very forgiving and user-friendly about that. The good side of TDMS is that every channel has a name. When I modify my cluster, it tends to be by adding more arrays (more "channels"). So I guess I could just add a little error-handling routine for channel name not found, whenever I modify/upgrade my file reader. Alternatively, if I stick with datalogs, I can first examine the file date stamp and then decide which cluster typedef to use. Hmm. Sounds ugly, yet less work in the short and medium run ...

I've got a project going in (now) Labview 8.20 that uses Datalogs to store and review several MB of data. It works, it conserves disk space, and it's fast, but it's not very flexible. If I change the cluster typedef that defines a record, I lose the ability to read older data files, unless I save an outmoded version of the file reader using the old typedef. I'm thinking of changing to TDMS files for more flexibility. I don't mind paying significantly more disk space, if that's an issue, but I would mind if the speed dropped more than, say, 10-20%. Does anybody know what the tradeoffs are -- or would you recommend an entirely different alternative? I would just go ahead and do it, and report the results, but it will be a lot of work, so I thought I'd ask first. In the larger one of my datalogs, each record consists of one 2-D and nine 1-D arrays, some i32 and some DBL. Each record uses about 500kB of disk space. The data is decimated before it ever gets to a file, and I alternate between two files, overwriting as needed, to keep the total size reasonable, while having a reasonably representative sample of all data. This thread could be a good place to expound your general approach to filing data. Try not to be shocked by my ignorance ...

Actually there is a camera upstream already (forgot to mention that ) and I know the positions of the items, the speed of the belt, and the moving speed of the sensor. The sensor finds qualities of the items (namely, composition) that are not always visible to the camera. The only problem is to figure out the best order in which to visit the items. That more or less amounts to finding the path which minimizes total travel between items and the total number of items missed (with some relative weighting for importance). That's why I thought the Labview Linear Programming module might be helpful, because I have a large-dimensional optimization problem with constraints. Here's a picture of a hypothetical belt, moving downward. The green lines represent the top speed of the sensor combined with the speed of belt motion; i.e. if you start at the bottom of a green line, you can move left or right only so fast. So for example, if you start at the bottom with the sharp-edged item, you'll miss a few items by the time you can move over to the left side. Or in the other green-lined example, if you have visited the upper-middle-right round item, you can't get to the sharp-edged item on the left. So in this example, the thing to do would be to let the sharp-edged items go by, and visit all the others. Only, how to figure that out in the general case? Hope it makes more sense now. Thanks for your input.

I've got a moving belt with parts randomly scattered on it, and a sensor that can move in the direction across the width of the belt. I want to move the sensor to each part (if possible) as it comes along, then raster back and forth over the part for a while. The more time spent dwelling over the parts, and the less spent traveling between them, the better. Also the fewer parts missed altogether, the better. I've looked on the web for solutions to the "Traveling Salesman Problem" and, more relevantly, the "Linear Ordering Problem", but what I've found was highly theoretical. Also, many of the computational methods people have used for those problems are too time-consuming. My belt moves fast. I need a rough-and-ready heuristic that gets not-too-horribly suboptimal results. Is there any way to use Labview's Linear Programming optimization routine on this problem? Consider a three-part problem with parts A, B, C, and possible routes AB, BA, AC, CA, BC, CB. Could I impose contraints like 0 <= AB <= 1, 0 <= BA <= 1, 0 <= AB + BA + AC + CA <= 1, etc.? My problem is discrete, whereas Linear Programming is meant for optimization of continous variables, I think; but maybe that's OK? Any help appreciated.

Thanks JFM. I always make things too complicated :headbang:

See post #20 in the share your favorite user lib VIs thread for my latest zip file of this project. There are just too many messy subVIs, and parts held together with duct tape and rubber bands, for me to clean this up to Code Repository standards. But it works, and I've killed a lot of bugs (can't guarantee there aren't more!) Comments, complaints, bug fix requests welcome.

In this other thread I've discussed a project of mine that is too messy to be Code Repository material. Unzip the attached and open File IO/DirTree__Browser_Plus.vi - It's a GUI for browsing directories, with a pie chart showing relative sizes (bytes) of the items, where the only bytes that count are the files that you're looking for. For example, if you're looking for files VoltageData* and CurrentData*, a folder that has many bytes of those will appear larger on the pie chart than one with few of those but more total data. You can leave the search pattern(s) blank and then all files will count. Directories with what you're looking for will get check-marked, as in the picture below. Any directories that do not have such items will have plain folder symbols. Note that in the picture, two directories have been selected (which really means that the 7 files within have been "selected"). When the user quits, these items' paths will be passed to the calling VI. Some sub-VIs that may be of interest, even if you don't have any use for the main VI: Tree Related: tree_Find_all_children.vi, tree_add_if_new.vi, tree_locate_and_add_item.vi (files item alphabetically within "its kind", as determined by a list of item symbols defining "its kind") File operation: List_all_dirs_many_files (applies "patterns" to filter file listing but not directory listing) GUI: Pie_chart_oriented.vi Array: cut_multiple_indices_1D.vi (polymorphic for i32, dbl, str) String: see picture above. If anybody feels like cleaning this stuff up (or maybe just some subVIs) and making Code Repository material, be my guest, but I'm not feeling up to it. If you find some smallish group of subVIs particularly useful, let me know, and I'll see about cleaning those up myself. Download File:post-4616-1163076885.zip

File Name: VI_path_listing.zip File Submitter: torekp File Submitted: 30 Oct 2006 File Updated: 31 Oct 2006 File Category: General VI_path_listing V1.0.0 Copyright

Does this have anything to do with the fact that in 8.2, all my VIs now have windows titled "junk.vi on My Computer" instead of just "junk.vi"? I read the thread about multiple projects being open at the same time, but it kinda went over my head. Where should I learn about application instances?

Here's the latest, it seems fairly workable now. It's not very clean code in some spots, so a little more work before trying a code repository version. I have yet to implement Ben's excellent idea of an "Other" category to encompass small-sized directories in one pie slice. Still working with pie chart, haven't figured out squarification yet. Download File:post-4616-1161781231.zip

Would the state machine be the top level structure, and the event case to handle user activity be the contents of one of the states? And then the other states execute the various tasks assigned by the user? Squarification would use front panel space efficiently, but I don't think I can manage to make it as neat & tidy as some of the programs you guys have pointed out. I'm more likely to just start with a 3 x 2 rectangle, and fill in the long side with rectangles until it becomes the short side, then fill in the new long side, ... etc until the "Other" category is reached. Finally, Ben's program makes the pie chart itself the "interactive element", whereas I was thinking of using a tree control, and just having the chart for display. I guess the ideal is for both chart and tree control to be user-clickable items that allow navigation, and to update the one whenever the other is clicked, but ... maybe later ...

Thanks everybody for your help. Ben, your VI is very much along the lines of what I want to do. I'll look into it and borrow all the good ideas and maybe I can give back something you can use. Hey, Labview can fire up other programs, so it's all good. And if the non-LV program can save its results to a file which you can then make sense of with Labview, it could all fit in very nicely. But the 1.4 freeware version, which I tried, didn't have any save-results feature. The idea of grouping LV files into one pie wedge (among various file types) is sort of similar to what I want to do. But as a first go, I'm thinking about showing only files of the selected types. Other file types in the same directories would just be ignored. I'm thinking about the situation where the user is processing saved data, and has the option of including or excluding various files in various directories. He wants to know things like, when were the files in this directory modified, and how much is there in this directory, and how does that compare to the size of the other data already selected. What the heck, let me share the other side of this project too - bear in mind that this is a work in progress, and hasn't progressed very far. But I appreciate any ideas, and if you like anything you see, please make feature requests! I might say, "duh, why didn't I think of that" - and with any luck (skill? ) the ultimate version I post might be worthy of the code repository. With that in mind, here's a zip file for the directory stuff. Download File:post-4616-1160744988.zip

I slightly modified the NI example Pie chart.vi in piechart.llb to get the following. What I changed: oriented labels (important for thin wedges); changed default colors; automatically recycles thru colors after the first (by default) 8; defaults to using text labels, rather than labeling pie wedges by their size percentage. I'd like to use the pie chart to display disk usage in a directory hierarchy, for example to answer a question like "where are most of my *.log files, and do I need to delete some?" Am I missing a much better idea? Any ideas appreciated on how to make it more user-friendly. LV8.0, attached. Download File:post-4616-1160681060.vi Download File:post-4616-1160681073.vi

In LV 8.2, it's under Options... -> Environment. Excellent tip by the way.

Dang, Mike, you sure know how to take the fun out of self-parody! I didn't find anything on my own when I searched for "reshape array" on this forum and (later) NI discussion forums. Well I did find one other thread in NI forums in which a few people said that this would be a cool idea. Unlike the post by Jim Kring that Ben pointed me to, no one else had actually created the flexible one-dimensional-but-really-more array handler, they just thought it would be a good idea. I do intend to contribute, by re-submitting some of my "stupid array tricks" from the share your favorite user lib Vis thread. Once I convert them to their more flexible versions, hopefully they'd be worthy of going to the code repository. Even if someone does hand me what I want on a silver platter, there's a good chance I'll be able to add to it. If I build the one-dimension-is-many idea from scratch, LAVA will get my array utilities handed on a paper plate, most likely, since I'm likely to overlook some things that real programmers would know how to do. That's the flip side of my (affected, mostly) demanding attitude.

Gory details and/or downloadable examples, please! Yes it's comforting to see that great minds have blazed this path before - but it'd be even more comforting to have everything handed to me on a silver platter. And now you see why my avatar is a pest ...