jzoller

The invert is... dependencenders? Joe Z.

QUOTE Scan from String sounds good to me too! Joe Z.

Keep in mind that using a stack (http://en.wikipedia.org/wiki/Stack_(data_s...e)#Applications, for instance) can be far more efficient than using recursion in LV. It may require painful architectural changes though. Joe Z.

I have an upcoming project where I'll be processing quite a bit of data coming over a serial port or USB. The timing budget for the processing is of the "faster is better" variety, and I'm looking for something that will allow me to accurately measure usage and timing in different threads. My experiences with the built in LV profiler haven't been entirely wonderful, and tight LV integration isn't immensely important for this project. Does anyone have any experiences they can share about using third party profilers with LV? (For instance, any idea what NI uses?) This is under Windows XP (RT isn't an option right now), likely with several dlls and the .NET framework involved. Thanks, Joe Z.

It's worth noting that OpenG packages are also available on sourceforge in zip format. You don't get all the integrated goodness of the VIPM though: installation is up to you. Joe Z.

QUOTE (eaolson @ Sep 30 2008, 02:48 PM) Arc the daft? I agree, it's an interesting concept. The sheer volume of knowledge there, even during the beta, has been overwhelming. Joe Z.

QUOTE (Minh Pham @ Sep 29 2008, 05:37 PM) No. While there have been some brilliant uses of existing and/or hidden functionality (the Bird's Eye View and Tunnel Wiring Wizard, for instance, or XControls/dynamic processes/probes), it's not really possible to extend the LabVIEW environment with new, integrated content. If you watch Jeff K's keynote from NIWeek 2008, there's some hope for it in the distant future. http://www.ni.com/niweek/2008/keynote/jeff...resentation.htm Joe Z.

If you prefer a built in, by value (rather than by reference) dictionary, variant attributes work wonderfully well. Dark side: http://forums.ni.com/ni/board/message?boar...ssage.id=209272 Joe Z.

My apologies if this is too basic.... The explicit pathing rules are under Tools>>Options>>Paths>>(dropdown)VI Search Path. From the help: QUOTE Problems usually happen at <foundvi>. LV finds one VI in a location you don't like, and promptly sucks in the entire hierarchy from that location, whether you intended it or not. Practical solutions: 1. Common vi's library, covered admirably above. 2. Name mangling - lvlibs do this (after a fashion), but the more traditional method is prefixing your vi's with purpose names. In my reuse lib, I prefix everything with "COMMON_". 3. Hiding things you don't want - When you're recompiling, if you understand the above pathing, you can rename/remove/zip folders to remove them from the pathing for the duration of the recompile. 4. Standard distribution & package management of source code - Also covered above, with addenda: I'm using an installer for package management. No software required on the target machine that way. -Edit- When IE attacks... Joe Z.

(Disclaimer: As a relative newcomer to the project (using 8.5.1), I may be missing some things that already exist. If so, *please* point them out to me.) 1. There's still work needed on project stability: 2+ crashes a day are common for me, along with corrupted project files that are never quite the same again. 2. For builds, I'd love G-code Integrated Ant, (see Ant/NAnt ...but that's probably asking too much for a multinational corp, and should be left to the open source folks ). While I'm holding my breath for that... how about: a "clean out old files before building" option Source build even when missing dependencies +1 for dynamic build location (I'd call it symbolic path substitution though ) On all build types! Stop leaving dynamic files out of my installers I would very much like to stop describing the project as "Better than it used to be.", and start using "Fantastic!" instead. Joe Z.

Just a quick followup on this... SQLite is really very cool (thanks Chris!). I'm tinkering with the ADO.NET provider for it from sourceforge (http://sourceforge.net/projects/sqlite-dotnet2). It seems to function well enough for my limited usage, though I haven't tested it under heavy loads. Long term, this looks like the solution I would like to transition to, I just need to make validated tools out of it. In the short term, I'm playing with what I'm calling decorator files. Parametric (scalar) test data is stored in a single row header, tab delimited text files, one row per test. This allows raw data to be opened in ways that my engineers prefer (Excel, JMP, etc). From there, I generate a series of (usually disposable) decorator files associated with the test data files. Need an index for quick searching on a particular column? It goes in the sorted, time stamped index file, which gets regenerated once in a while if the data file has changed. This allows the memory shadow and search time to be much reduced. Need to mark particular items inside the data file (say, making deviation notes on a given data point for an SPC chart)? This goes in an application specific XML file that "points" at a given row, column, or data point in the original data file. And so on, and so on... nothing brilliant or complicated, just trying to stick with the practical. Thanks all, Joe Z.

I've recently started using the automatic error handling. It's annoying, but worthwhile for catching those unwired errors. Maybe someone knows, is there a way to attach a custom handler or callback to the automatic error handler? (I would occasionally like to inspect, or even modify, my program state when the automatic error handler pops up.) Thanks, Joe Z.

QUOTE (Aristos Queue @ Aug 22 2008, 10:18 AM) He got a great member number

QUOTE (Darren @ Aug 15 2008, 09:39 AM) It's definitely amazing. I'm struck by how much everything (and it gets pretty strange) seems to just fit into the worlds... Joe Z.

A quick shuffle through my iPod renders: Chevelle, Slipknot, Tori Amos, Joe Satriani, Dave Matthews, Sting, Steve Vai, Tool, StaticX, Depeche Mode, Boston, Frankie Goes to Hollywood, a few movements of Sheherazade, Linkin Park, and se radio's interview with Anders Hejlsberg. Anything not country is fine with me Joe Z. P.S. Anyone know where to get a compilation of Nuno Bettencourt's work without a torrent?

http://wiki.lavag.org/Insane_Objects

QUOTE (PaulG. @ Aug 12 2008, 09:40 AM) Just out of curiousity, why is this important? Joe Z.

Check out DFGray's very nice reference object benchmarks. Joe Z.

Since I'm very interested in seeing this development continue.... Here's a link-back to Aristos' performance note for the Map.lvclass: http://forums.lavag.org/LabVOOP-Performanc...ion-t11521.html Edit: classname was incorrect

QUOTE (crelf @ Jul 25 2008, 10:19 AM) Actually, I've never found NI to be unresponsive (though the response might just be "No", or "We can't tell you right now"). They are responsive, open, communicative, even chatty, and I love that about them. The difficulty that I see is implementation time. When was the first time you requested "change all at once" feature that Heiko & Norm mentioned? I know it was LV5.1 for me, undoubtedly due to some hideous, gods-awful megacluster I had conjured up... anyway. I don't think that it's lacked implementation for all these years because they didn't know about it, or were avoiding it, or weren't working their butts off trying to make LV the best possible system. My suspicion is that it hasn't been done because it's just hard, and difficult things take longer, and get pushed down the priority list. Frankly, if the choice was between that feature and, say, Retain Wire Values, I'd take Retain Wire Values in a heartbeat. Design decisions always have tradeoffs, and this is the one we live with: we get the best integration between IDE and compiler anywhere, that does things that many programmers don't even believe can exist. In return, we suffer the occasional leaky abstraction and trailing a bit behind on some of the more modern IDE features. Joe Z.

QUOTE (hfettig @ Jul 25 2008, 07:01 AM) Occasionally, the LV IDE drives me batty. Just totally, 'why isn't this available?!!!', stark, raving nuts. After calming down a bit, I ran across the reason. In Jeff K's very good article http://zone.ni.com/devzone/cda/tut/p/id/5313' target="_blank">Is LabVIEW a general purpose programming language?, he states: "In reality, it is a severe disadvantage to limit the connection between program editor and program compiler to a simple ASCII stream." This model has worked well for LabVIEW, but it has a very dark side. Go off to the nearest OO-style program you have available. Find two well factored, separate classes. Great, now combine them into a single class. What's that? Loose coupling between different functions? Ah, but, there *are* benefits to tight coupling: information sharing is very tight, and you can have very strong optimization, because your environment is very well known. These benefits are most obvious in the first few versions. As things evolve, though, you run into a problem. You must develop the components together. Lockstep. You can't make changes to the IDE without affecting the compiler, and vice versa. And so, the combined component takes *at least* twice as much time to develop, and probably more due to developer communication overhead, and when one component introduces side effects into the other. And so, when your competitors are introducing scriptable development environments, code snippets, plugins, etc... you still take 9 steps to make a merge VI. You can't right click a selected portion of code and say "Put a for loop around this". You can't select a sub-vi and see it's path in the IDE. You can't adjust the speed of the debug highlighting. You can't match sizes on the block diagram. You can't attach the profiler results to the VI hierarchy display. You can't modify palettes on the fly. You can't have a scrollbar on a cluster. So, the industry standard solution to all this is painful: intermediate bytecode/markup, generated by the IDE/precompiler and consumed by the compiler. Whether that, or something more innovative, would ever happen, is difficult to say. Happy Friday, Joe Z.

QUOTE (Aristos Queue @ Jul 14 2008, 12:25 PM) Thanks Aristos, that's much more concise than my statement. I should mention that I've recently been using the VI Analyzer more frequently, and have found it to be an excellent tool. I expect it to save me literally days of mind-numbing work testing user submitted code against standards. Joe Z.

The profiler will work if you have subvi's. It won't work if you have monolithic code. If you need a quick subvi, you can highlight the relevant code section and Edit>>Create SubVI. Note that it appears that the profiler can be blocked by the running process, so don't expect perfection. I've had a number of vi's that run a minute and a half, but end up totalling 30 seconds in the profiler. VI Analyzer (if you have it available) is a static code analyzer. It will give you some tips on how to organize your code in more efficient fashion, but it's not really a performance tester. Joe Z.

QUOTE (Ton @ Jul 8 2008, 08:05 AM) The XControl seems like a good solution, but it doesn't have any built in timing capability to update itself. Aristos' example gets around that. Correct me if I'm wrong, but is the more general idea to essentially have a state machine behind the control? Joe Z. edit: grammar == bad

QUOTE (Mobile-it @ May 16 2008, 08:10 AM) Hi Mobile-it, While creating one program from the output of another is fairly common in the text world, it's pretty hard in LV. It's even harder to specify a text language that captures the code structure of vi's. I would suspect that NI has the tools and knowledge to do this, but it's not available to the general public. Joe Z.