jzoller
-
Posts
285 -
Joined
-
Last visited
-
Days Won
5
Content Type
Profiles
Forums
Downloads
Gallery
Posts posted by jzoller
-
-
-
Wii
in LAVA Lounge
-
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?
-
-
-
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)
Great post, but the reason I most often see is much simpler than that: no one has asked for it
I find NI to be pretty responsive to new IDE feature requests (based on valid use cases, of course).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)
True. But several of the style tests have the effect of improving performance....
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)
"One NI R&D developer"...
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)
I have a question about automatically generating vi's.Is it possible in some way to generate a vi by use of parameters? I mean from another programming langauge.
for instance something where we create 2 controls, 1 add function and 1 indicator? without opening LabVIEW?
for instance we use VBA under Excel to do this kind of things?
Thanks for your help.
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.
-
There's nothing new here, but maybe someone will be kind enough to lend me their experience.
I need to store data taken at a series of points (>100k) over time (minutes to months). At each point in time, many (1000+) parameters will be tested, and each test will generate a single result (string, bool, dbl, etc). All of this data will be associated with some identifying and meta data (time stamp, serial number, etc). Not every parameter will be tested at every point in time, leading to some sparse result sets.
In the past, I've taken all of the data for a time point as a "row", with each test result as a single column. That row was written as a string to a tab-delimited file as every time point test completes. I'll skip all the problems this can lead to, but too much of my life was spent on fixing them.
So, I have a chance to start from scratch. I've been looking at a few options, and there seem to be issues on all of them:
1. NI's TDMS: doesn't seem to understand the concept of a row, only a column. Not expandable in ways that I'd like.
2. Database: ideal, but I've many non-networked computers... anyone know a good sneakernet DB?
3. Markup (XML and ini, for instance): poor scalability & poor LV tool support... anyone have an LV native SAX parser?
Of course the database folks want future compatibility for import into the grand plan, the engineers want to use Excel (sigh...), the web folks want to be able to pull reports in .NET/PHP, and I want to be able to add or remove tests any time I'd like.
What have you all done with your data systems?
Thanks,
Joe Z.
(My budget for this is currently whatever I have in my cubicle, pockets, and/or can sneak out of IS after midnight, so large scale proprietary systems are out. Please, feel free to respond here if you have a commercial system, but no emails.)
-
-
QUOTE (Aristos Queue @ Mar 31 2008, 12:11 PM)
Aristos, can you spare any comments on how LV deals with http://en.wikipedia.org/wiki/Memory_fragmentation' rel='nofollow' target="_blank">memory fragmentation ?
Joe Z.
(Edit: specifically, is external fragmentation an issue... you covered internal above)
-
QUOTE (jdunham @ Mar 11 2008, 11:17 AM)
I stuck with the tab key and auto-tool off, because it seemed like the hot-spots were too sensitive. I know which tool I want and it is easier to make it happen with the tab key then to try to find the hot-spot with my mouse hand.I also end up using a trackpad more than I'd like, and I think it is more of a pain with the autotool.
However if some of you are saying it's better, maybe I should give it another go.
I agree, the hotspots seem a little too sensitive at times, especially as screen resolution climbs (and my eyes age!). I also find the lack of wiring hotspots on large block diagram structures a bit of a hinderance with the autotool.
Joe Z.
-
QUOTE(Gary Rubin @ Mar 6 2008, 10:12 AM)
I have a cousin who is a real computer nerd. He used to enjoy dressing up really scruffy, going to someplace like Best Buy, starting off asking very basic questions of the computer sales people, then asking them some really detailed technical question about system...... I admit it, I did this last time I was in an Apple store
. The saleswoman actually ran away.JZ
-
In a more useful vein, here's Adam Kemp's reply on the same subject from Info-LabVIEW:
"It may be annoying, but it's not unheard of either. Most programs need
some kind of runtime code to work. Native applications need runtime DLLs
that happen to come with the OS, so you don't notice. Programs written
in other languages like VB need runtime DLLs that happen to be very
small. Then you have programs like Java and .Net which need bigger
runtime components. Java comes in around 10-20MB and .Net is about
20-30MB. Depending on your OS version you may or may not already have
these components installed, but that didn't use to be the case.
If you think about file size compared to the size of drives and typical
bandwidth for network connections, then LabVIEW is doing fine compared
to what Java users had to go through in the 1990s. The JRE took about 30
minutes (or more) to download back then, and it seemed like every
program written in Java came with a different version of the JRE.
Fortunately Java has settled down a bit since then, and people can
mostly get away with relying on the JRE pre-installed on most systems.
LabVIEW can't get away with that (it's probably not going to be
pre-installed on systems any time soon).
It's unfortunate, but realistically it's not very different from the
other software tools. We just don't have the benefit of coming
pre-installed like they do. Maybe some day. :)"
-
QUOTE(brent99 @ Feb 22 2008, 12:21 PM)
I apologize if I'm beating a dead horse here -- I'm not sure if and how often this has been brought up in the past -- but I'm kind of annoyed at how large the distribution file has become since Labview 7 because of the massive Labview 8 RTE. I used to be able to distribute a complex program at about 8MB or so. Now, even a simple program is taking like 50MB. Am I alone in this or do other people see this problem? You can email an 8MB program, but you have to serve up a 50MB program. It really limits distribution of a simple program to people who don't normally use Labview.Dead horse: yes.
Still true (and annoying): yes.
JZ
-
QUOTE(rolfk @ Feb 22 2008, 12:21 AM)
Of course if you don't have an MSP this might be the time to think about it again.Rolf Kalbermatter
For a more explicit description of this: If your SSP expired after 8.20 but before 8.2.1, you were not entitled to receive the 8.2.1 bugfixes. I have no idea if this will remain the same for 8.5.1.
This situation convinced my boss to stay at 7.1 rather than making the planned 8.2.1 upgrade, and now that we're off the upgrade trail, frankly, we're unlikely to upgrade again until things become so broken that we have no other choice. :headbang:
Joe Z.
-
QUOTE(cmay @ Feb 19 2008, 01:41 PM)
This is running WinXP SP2 on an Intel Core Duo @1.83 GHz with 512MB of RAM.-Casey
You're running a little tight on memory. If the GUI is large, it might be causing some page file swaps that are slowing down disk access on the loads.
Just a thought. Hard to do more without concrete details.
Joe Z.
-
Wow, that takes me back. It looks like my early programs... it's just lacking a 12 level stacked sequence structure!
Step away from the LabVIEW for a little bit. Go read http://zone.ni.com/devzone/cda/tut/p/id/4434 and it's associated links.
(Yes, it is god-awfully, mind-bogglingly boring. And necessary.)
Then, go to the LAVA code repository and OpenG and look at some code. Don't worry about what the code there is doing. Just look at how it's written.
Now, go back to your VI and re-arrange it so that it looks as much like the above as possible.
The migraine will recede soon thereafter. Honest.
Joe Z.
-
How about serializing the state of the controls on each tab to a scratch file?
You could use something similar to the OpenG Read Panel from INI/Write Panel to INI (or XML or whatever) when you detect a tab change.
If you don't store the state of the panel between program modifications, there shouldn't be any problems with mis-naming or bad ordering.
Make sure you don't run into file write permissions problems if you do it this way!
JZ
Automatic Error Handling - What do you do?
in Development Environment (IDE)
Posted
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.