jzoller

Some random thoughts on general purpose LV.

First, I have more thumbs than there are major companies that make money from selling general purpose languages. Most major languages are either open source (free-as-in-beer), or are loss leaders for companies selling platforms (Microsoft).

Second, the test hardware niche is really comfortable for NI. Imagine Microsoft came up with LV.NET: an exact, general purpose clone of LV, just without the hardware access. Would NI sales suffer? Almost not at all: NI is a hardware company. In fact, sales might even increase as more users find this really "new" language, and discover this rip-off that NI has made isn't half bad either

Third, making LV general purpose requires NI to take market share away from the major players already entrenched in the field, at a not insignificant cost. It almost certainly also requires they adhere to a more broadly accepted standard of some type as well, making development and maintenance more painful.

However, I agree with jdunham that the "threat of conversion" is very real. Last place I worked, we were told (by executive fiat) to retool everything in C# and C++. Pointing out the multimillion dollar investment loss and 2 year downtime seemed to cool the executive enthusiasm, and this made them mumble something vague about carrying on with LV and go back to counting their bonuses.

Watching LV restrict itself to its market niche is like watching Tiger Woods decide to only play mini-golf, but if mini-golf is where the money is...

QUOTE (Aristos Queue @ Jan 23 2009, 09:55 AM)

... (Side note: Trust me when I say these logs are boring. I sometimes wish that customers would edit their log files before they send them to NI to include some salacious gossip or poetry or a really good joke just so that when I'm reading through the logs trying to debug something I could hold out hope that something interesting would be included instead of the mind-numbing stream of hex addresses and object IDs...) ...

The token is obviously capitalized incorrectly. It should be "DPrintFlogging".

This looks very cool, will check it out.

Thanks Aristos!

Happened for me as well, DLL pathing issue.

Joe Z.

NTFS copied many characteristics of *nix systems of its time, including the concept and name of inodes.

Side note: SHFileOperation notes (http://msdn.microsoft.com/en-us/library/bb762164(VS.85).aspx) that it was replaced in Vista by the IFileOperation interface (http://msdn.microsoft.com/en-us/library/bb775771(VS.85).aspx)... in the unlikely case that anyone is using Vista.

Joe Z.

QUOTE (jdunham @ Jan 5 2009, 04:25 PM)

Hi John, thanks for posting.

When I evangelize LabVIEW to my co-workers and others, sometimes I say "It's quite possible that in another 50 years, everyone will program computers this way, and text languages will be archaic" I really believe that's possible, for a variety of reasons that we all know and love (dataflow, built-in parallelism, modularity). BUT, then I have to say "but I don't think National Instruments can get us there, since it's designed and marketed as a niche language for a niche market".

Before I make you feel any worse, I don't really think this is NI's fault, or that it's easy to fix. Conquering the world is a might big challenge (Do I hear someone chanting "Open Source... Open Source..." in the background?). However I wish I heard more from NI about this kind of long-term vision, and yes I have been to plenty of NI-Weeks.

But yeah, we need better deployment tools and all that other stuff on your list of New Year's Resolutions.

"It's all part'n'parcel of the whole Genie gig. *PHENOMENAL COSMIC POWERS!!!* Itty-bitty living space!" - Robin Williams in Disney's Aladdin

That was extremely well put, Mr. Dunham. Thank you.

Joe Z.

QUOTE (Michael_Aivaliotis @ Jan 2 2009, 04:00 PM)

I have a project file that always shows an asterisk (like there are unsaved changes) every single time I open it. If I save it, then do a diff on the project file it doesn't show any changes.

What gives?

Same problem here. In my experience, it usually starts occurring after LV crashes (irreproducibly) while the project is open.

Joe Z.

The problems that I've seen for the CLD are not tremendously difficult if you are prepared... except for the time limitation. When I realized I only had an hour and a half left, I started to sweat a bit

Joe Z.

QUOTE (NI Guy @ Dec 19 2008, 09:01 AM)

...

In the meantime, we are going to have to rely on the tribe to supplement these efforts.

Thank you, http://sethgodin.typepad.com/' rel='nofollow' target="_blank">Seth Godin.

QUOTE (Variant @ Dec 13 2008, 10:13 PM)

Can anyone exaplin this " O(log n) )" How it works. Really curious

http://en.wikipedia.org/wiki/Big_O_notation

In very general terms, it's a description of how long it takes for an algorithm to run to completion.

QUOTE (Dan DeFriese @ Nov 12 2008, 09:23 AM)

Not sure what you mean by turning off selection scrolling.

If you hide the scroll bars the FP doesn't scroll. Is that what you mean?

That's an idea...

During development, drop a cluster (like an error control) on an extreme edge of a front panel window, and try to select it by "lassoing" it (that is, drawing a selection area around it).

On my computer, it inevitably results in my carefully aligned pane haring off into parts hitherto unknown, requiring that I resort to programmatic tricks to realign it when run.

In short, it's irritating, just like the on-by-default-but-can-be-turned-off selection scrolling on the table indicator is irritating. :thumbdown:

Okay, off to grump elsewhere

Joe Z.

Is it possible?

Thanks,

Joe Z.

QUOTE (jcarmody @ Nov 3 2008, 07:36 AM)

Shane,

Do you have an example you could share? I don't have any experience with .net (except for a horrible application I inherited that has a slick user interface using .net controls).

Thanks,

Jim

Jim,

I had the attached laying around, hopefully it's helpful.

Another method: it's possible to invoke sqlite from the command line (or the System Exec.vi). The exact syntax escapes me at the moment, but it's something like C:\path\to\sqlite.exe databasename "databasecommand".

Joe Z

Thanks Michael, that's the information I needed. Now I can program around it.

Whether it's "good" behavior or not, I don't know.

Joe Z.

Edit: Script blocker != good formatting

This may be a bug, or may be just an "expected behavior". Given that it's not hard to reproduce, I suspect it's been seen before.

Reproduce:

1. In the Windows file system, create the folders C:\Original, C:\Original\Path1, and C:\Original\Path2.

2. Run the attached VI.

Expected either:

1. An error: the folder C:\Destination does not exist.

or

2. No error, and the folders C:\Destination\Path1 and C:\Destination\Path2 are created.

Actual result, no errors:

1. First iteration of the loop creates C:\Destination

2. Second iteration of the loop creates C:\Destination\Path2

Can anyone provide confirmation or insight?

Thanks,

Joe Z.

The invert is... dependencenders?

Joe Z.

QUOTE

Some people, when confronted with a problem, think "I know, I'll use regular expressions." Now they have two problems. - Jamie Zawinski

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)

I've been fascinated by http://stackoverflow.com/' rel='nofollow' target="_blank">Stack Overflow lately. It's a neat way to get answers to any simple programming question you might have, or just to probe the opinion of a number of professionals. But the way the whole site works is unlike anything I've used before, too. It's like Usenet meets a wiki crossed with digg. There's not a lot of LabVIEW content there at the moment, however.

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)

I just wonder is there a way to create/design new functionality to the Labview block diagram working environment. I really want to personalize the workspace, for example when my mouse move over a function/subvi icon on the block diagram, user can hold shift and have the function/icon being zoomed in with terminals labeled. etc...

Can we write new functionality for Labview?

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

<topvi> refers to the directory that contains the top-level VI that LabVIEW is opening. <LI><foundvi> refers to a list of all directories where you have previously located a subVI. During a search, LabVIEW adds to this list any directory in which LabVIEW finds a subVI. <foundvi> helps you locate a directory of VIs that has been moved or renamed. When you open a VI that calls another VI that has been moved, you must find that directory only once and then LabVIEW adds this path to the list of directories. <LI><vilib> refers to the vi.lib directory in the LabVIEW Directory. <LI><userlib> refers to the user.lib directory in the LabVIEW Directory. <LI><instrlib> refers to the instr.lib directory in the LabVIEW Directory.

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.