Val Brown

QUOTE (neBulus @ Feb 24 2009, 01:34 PM)

No I don't have a demo just the complete application. Lets see if this helps. I wrote a "Controls on the Fly" app that when in run mode took this form.

<....>

Thanks, yes that helps and, at some point, if someone can, a "small" example would be very wonderful. They probably already exist so maybe someone here knows an example they can point to. Again what would really help me would an example that hews as close as possible to these descriptions.

And FWIW, this is a really great thread for me!

QUOTE (bsvingen @ Feb 24 2009, 12:57 PM)

I just know by experience that my old programs using GOOP and call by ref vi's, simply get cleaner and "tighter" and more modular when using LVOOP and Actor principles (after getting familiar with actor oriented design). IMO LabVIEW is in many ways the "native programming language version" of Simulink or http://ptolemy.eecs.berkeley.edu/' rel='nofollow' target="_blank">Ptolemy. Where Simulink and Ptolemy is built on top of some other languages to be Actor Oriented simulation environments, LabVIEW is sort of built from the ground to be an Actor Oriented visual programming language (I don't know if it actually is, but I pretend it is, and it works real good ). LabVIEW is also dataflow, but the main limitation with that is not the dataflow itself (call by value), but the implicit synchronizing and serialization caused by the wires (easy to work around but still a limitating factor), and none of the GOOPs changes any of that, they just change a data-wire for a ref-wire.

Anyway, I like to think like this. LabVIEW simulates instruments. It is in all respect a 100% configurable software version of a concurrent embedded system of processes that manipulates any kind of data in any way possible, a virtual instrument. Just like Simulink and Ptolemy can be used to simulate anything, so can LabVIEW. Simulink and Ptolemy forces you to think actor oriented rather than object oriented (in the traditional meaning) or procedural, because there is no other way. LV does not force you to to that, but if you do LV really shines and so do LVOOP. In this respect LVOOP is a completely new concept altogether, it is an object oriented version of actor oriented design. I am not sure if that is entirely correct, but it works for me much better than GOOP.

Thanks for the reply. That helps too.

Can you recommend a good book or other written resource for what you're calling "Actor Oriented Design"? I'd like something that you feel comfortable with, that was/is helpful to you, esp in facilitating seeing LV in the way you've described. And, of course, others here may have some good resources to suggest as well.

QUOTE (neBulus @ Feb 24 2009, 09:59 AM)

I'll give it a try since I have not been OOPing long enough to fall into the trap of using those fancy OOPish terms.

I understand the difference is the nature of the wire being passed around. IN LVOOP the data is in the wire. The "by-ref" version passes a reference to the data.

So it is a question of where is the data. Since LVOOP is smart enough to work in-place it ends up being faster. The by-ref version requires moving the data (after getting a lock) to where it is manipulated and then putting it back. THe movement of data back and forth is what always kept me out of GOOP but the native LVOOP removed that limitaion.

THe only limitation that I ran into is something that is an automatic in my design but not straight forward in LVOOP. I understand it to be called an "Active Object". These are objects that once created can go on by themselves doing their job while also offering services (methods) to other objects.

Ben

Thanks for the explanation. You've hit on a couple of points that I've wondered about and thought I understood and it seems like I probably do because you've expressed the same understandings.

1. the "by-ref" implementations will, almost inevitably, execute more slowly for "equivalent" code. This is because of the multiple operations needed to "access" the data through the "by-ref" process.

2. This might be helpful from a design perspective -- esp for those used to by-ref object design -- but it will also lead to the likelihood of runtime penalties in performance.

3. There are work-arounds using by-val that can address the "limitations" of that approach re: point 2 above.

Do you an example of the "Active Object" code that could be uploaded here? I'd like to see how you've done it and then, if possible, get comments from others about it, esp from those who favor a "by-ref" approach.

All of that would really help me understanding this issue more deeply.

There are a number of examples available via the web for interconnecting to an Access mdb file using the DCT. I'm not where I have that list at this time but I would think a search on the NI forums or support link would work using keywords like "Access", "Database Connectivity", etc.

QUOTE (bsvingen @ Feb 24 2009, 07:27 AM)

Well, yes – at least that is my experience. As long as I stick with AOP (Actor Oriented Programming) paradigm using LVOOP, sate machines and queues, I simply feel by ref GOOP will add nothing.

Can you -- or someone else here -- clarify what would be "missing" from such a stance: ie what does "by-ref" add at a functional level that is not available with what you're reporting. Not being "deep" in OOPs I'd really like to hear this laid out as clearly as possible by those who know.

Let me say this another way: if the native LVOOP really does "do it all" then I'm much more interested in pursuing OOP within LV. If not (yet?) then I might just wait to jump into the pool until the native implementation does "cover the waterfront". I don't want any "OOPs" or "gotchas" along with way.

QUOTE (bsvingen @ Feb 23 2009, 11:15 AM)

I suddenly discovered that I never use GOOP any more. Somehow LVOOP and queues seem to do the job better, with better consistency, less coding and with less clutter than any GOOP could ever do. LVOOP is also faster for some reason. The only by ref objects I have are made in C++, mostly due to complex algorithms not easely made in G, not due to by ref programming paradigm.

Anyone else experiencing this?

Are you saying that LVOOP "...and queues" covers the water front or am I misunderstanding you?

QUOTE (Jim Kring @ Feb 21 2009, 11:11 AM)

Background

There is a bug in the Event Structure where code in frames of an Event Structure can get re-associated with a different/wrong Dynamic Event when the input event reference data of a Register For Events node changes.

I haven't had the time to download and test this but I'm wondering if you know the behavior for 5 or 6 such events and deleting one: ie where do the remaining events map now? There may be an underlying logic to the actual behavior which, although it looks pretty clearly "buggy" to me, might allow us all to work with it until it is fixed. FWIW it sounds like a index reversal issue in the underlying code of LV itself and the event registration process.

I've used the DCT for several years and found it very useful. I'm also on Premier support for the Professional Development System so, for me, having access to AEs who know what they're doing (that's the Premier part) I know that I can find out what I need to fairly quickly -- and definitively. I was never that interested in using LabSQL as it was a third party tool, not NI officially supported. Now don't get me wrong. I know Jeffrey and his work is exemplary but I really wanted something that would be eligible for "official" support.

Your situation might be very different. If you're no on SSP or Premier status then you probably want to use tools that can be supported in other ways, like via user forums. The you might reasonably ask: "Why pay for something you can get for free?" But even if I weren't on SSP (and Premier status) I'd probably still go with the DCT because my primary RMDBS target was Access not MySQL.

QUOTE (Phillip Brooks @ Feb 5 2009, 04:26 AM)

Any person with programming experience can laugh at this.

Only a LabVIEW programmer would laugh at this...

Jim's magical use of the word open is important. The upper image is "open". Practically any programmer can read and interpret it. It can be compiled and adapted to run on virtually any type of computing platform.

The lower image can only be created and executed with a specific programming language.

Perhaps, BUT -- and it's an incredibly large but (which anyone can laugh at) -- how long would it take a non-programmer to laugh at each one?

Now before this reverts to "noobs" vs "real programmers", it again makes my point. Everyone who says the top comic is "easier" to understand is simply well taught in text-based languaging of operational code.

And actually we don't DRAW pictures, we USE pictures (graphic images) to accomplish real-world tasks. Hey keypunch still works, as do TTYs...

QUOTE (Gary Rubin @ Feb 5 2009, 05:38 AM)

I find exactly the opposite, esp with the picture control toolkit.

QUOTE (Gary Rubin @ Feb 5 2009, 05:38 AM)

I find exactly the opposite here as well and a lot of my work involves "ad hoc" variations of my current code to add-in features, troubleshoot and prototype alternatives, etc. to my already novel visualization and analytic routines. It's difficult for me to imagine how that would go using Matlab, C/C++, etc.

QUOTE (Gary Rubin @ Feb 5 2009, 05:38 AM)

It seems to me that LAVA does a fair amount of code sharing but, more importantly to me, it does an enormous amount of expertise sharing (your second point about LAVA) and that is a far, far more important resource to me personally and I suspect to most LAVA members. I don't need mapping capabilities but, if I did, I would look for some form of ActiveX component that could do the same. Something like what I've done to encapsulate WMP for my use and, hopefully, at some point in the future NI will do the more complete encapsulation that I've requested (esp maintaining the size of the visual image regardless of source when Pause and Play operations are toggled repeatedly).

QUOTE (Gary Rubin @ Feb 5 2009, 05:38 AM)

I understand about not being able to "forward" visualize from an earlier version. I guess that's kind of like trying expect C++ classes to function exactly the same in an early release of SmallC or something like that. Yes, it would be nice if LV could forward visualize and leave a :question: as a marker when it didn't recognize a construct from a version of LV later than the one running; however, I expect that's a very difficult feature to implement. I don't have this issue because I'm on SSP and keep up with the most current versions pretty well and I find THAT process far, far smoother and easier than having to update an almost infinite variety of C/C++ libraries, COM objects, NET controls, Matlab scripts, etc, etc. One source (NI), one product containing its own dependencies that are completely versioned internally (LV and its toolkits) -- all of that greatly simplifies my life and adds most of the complexity and capability that I need but I also have a rather specialized situation in that I'm a single programmer, with essentially a single family of products.

QUOTE (Jim Kring @ Feb 4 2009, 04:11 PM)

Don't forget that text-based languages are inherently open, in the sense that you can use any editor to read and modify the sources.

Yes, of course, but isn't that also part of the problem? I mean you could even use card punch to implement text-based languages but aren't we sort of like a couple of decades past all of that? Or are we saying that we should reduce what we do to the lowest common denominator, ie a notepad compatible text editor?

QUOTE (neBulus @ Feb 4 2009, 12:48 PM)

This discusion reminds me of the "Why would you want to waste all of your CPU on a mouse when can do the same thing with a keyboard?".

So I say let them talk, I'll go draw pictures.

Ben

...esp if the keyboard has a trackpad because it's on a laptop!

QUOTE (bsvingen @ Feb 4 2009, 12:30 PM)

Java is not open source. It is proprietary and closed, but free (as in free beer). The difference between java and LV from a "high level commercial" point of view, is in fact price only. But there exist another programming environment, Matlab, that is general purpose in nature and much more expensive than LV, still it has a much larger user base. With Matlab it is also possible to make stand alone executables, yet extremely few use Matlab to make general purpose programs.

There is also a Matlab open source "clone" called Scilab. It even has a LabVIEW node that can be used. Everything is open source and free and supported by NI it seems. I tried it a few months back, and it seems to work just perfectly (if I only could find some real world use for it ).

I think that, again, you make one of my main points. What differentiates Matlab from LV is that Matlab is TEXT! So, yes, the text-based "crowd" really likes it and it is taught in a number of CS programs alongside standard C/C++ courses. LV is visual and far more intuitive than any text-based programming constructs UNLESS you've been "brought up" to expect text.

QUOTE (bsvingen @ Feb 4 2009, 12:30 PM)

Java is not open source. It is proprietary and closed, but free (as in free beer). The difference between java and LV from a "high level commercial" point of view, is in fact price only. But there exist another programming environment, Matlab, that is general purpose in nature and much more expensive than LV, still it has a much larger user base. With Matlab it is also possible to make stand alone executables, yet extremely few use Matlab to make general purpose programs.

There is also a Matlab open source "clone" called Scilab. It even has a LabVIEW node that can be used. Everything is open source and free and supported by NI it seems. I tried it a few months back, and it seems to work just perfectly (if I only could find some real world use for it ).

I think that, again, you make one of my main points. What differentiates Matlab from LV is that Matlab is TEXT! So, yes, the text-based "crowd" really likes it and it is taught in a number of CS programs alongside standard C/C++ courses. LV is visual and far more intuitive than any text-based programming constructs UNLESS you've been "brought up" to expect text.

QUOTE (jzoller @ Feb 3 2009, 08:42 PM)

...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.

I don't think so. LV is setting a standard -- a true visual interface. And, if I'm not mistaken, some matured form of LVOOP will eventually consolidate and remove THAT perceived barrier. One other innovation that I think could really help with general acceptance would be completely transparent C/C++ text-based interface in the mode of the Math Expression node. I KNOW it's not at all easy but, if it were done, it would really make it a no-brainer for the "text-uber-alles" crowd to really "get it" about LV's capabilities. That might even make some other code more "readable"...

QUOTE (jzoller @ Feb 3 2009, 08:42 PM)

In the end dollars DO count and I believe that IF companies (and individual programmers) actually counted the REAL costs of using C/C++, JAVA, etc they would come to see just how cost-effective LV really is.

QUOTE (jzoller @ Feb 3 2009, 08:42 PM)

To say it that way does sort of imply that LV is a bit of a toy or game.

QUOTE (jdunham @ Feb 3 2009, 07:04 PM)

Well the advantage would be that the user base would probably increase by a factor of 20 to 50 in short order (wildly guessing of course). The world would be divided into people who use LabVIEW or who program "the old-fashioned way". What if 80% of the kids in the USA would have built a LabVIEW-controlled robot by the time they reached 10th grade?

I have no doubt NI evaluated this future and decided it was too risky and that they didn't know how to do this in a way that would benefit their shareholders. I don't know how to do this either, but I don't agree that this it's naive to contemplate it.

The naive part is, IMO, the idea that it will open source, low (initial) cost a la C/C++ compilers. The idea that LV will ultimately become a dominant IDE is pretty obvious.

QUOTE (Michael Aivaliotis @ Feb 3 2009, 05:03 PM)

I installed Windows Vista on my PC. Now when I open old code which was written on Windows XP, all the fonts on the Vi diagrams seem to be slightly bigger. I notice this because text and string constants are now touching other objects when they weren't before. This also applies to bundle\unbundle nodes, properties etc. Anyone know how to fix this? I'm using LabVIEW 8.6. This even happens to newly created VI's

Is this just the new standard?

I believe it's just the new standard and, if that's the case, the "fix" would be to revert to XP or rework everything based on the new font.

QUOTE (bsvingen @ Feb 3 2009, 03:18 PM)

I am sure if they did promote and license LV as a general purpose language the same way Java is licensed, the user base would expand tremendously to put it mildly. We can only hope, some day

I think it's highly unlikely and incredibly naive to believe that NI should "market" LabVIEW as if it were JAVA. Not only is there no real need for NI to do so -- unlike the situation facing Sun when they sourced Java -- what would really be the advantage? One posted cited cost as a factor making LV not be a general purpose language. I think the real issue was that it does cost, so it is a low-cost general purpose language. Other options APPEAR to be low-cost because for the "pure" base language and IDE the cost IS lower, initially. But, as I pointed out above, the learning curve for other languages as well as the cost and need for additional "add on" libraries, etc makes the overall cost far, far HIGHER than using LV.

I've never had a problem distributing my built apps, at least NOT with the LV portions. Where I have had problems over the years was with all of the OTHER components and "pieces" that were written in C/C++ and VB. A big part of my efforts over several years involved completely removing ALL of those other portions, so as to simplify my distribution and maintenance issues. To say this another way, you couldn't pay be enough to NOT use LV and move to another environment with what I'm doing. And bear in mind I started out as a unix and C hack back in the day (as the saying goes). I am SO thankful to be out from under ALL of that nonsense and that is all because of LV. I only wish the rest of the initial team had headed my advice and ONLY used LV. It would have saved me thousands of hours of re-programming, re-factoring time.

QUOTE (Dirk J. @ Feb 2 2009, 12:31 AM)

what's certainly not helping in my opinion is the enormous complexity of turning a moderately complicated LV project into executable code.

(thinking of the LVOOP <--> app builder issues)

Again I think several of you guys are making several of my point(s). It SEEMS difficult to build with LV because you're benchmarking what/how LV works and does its builds against text-based programming IDEs which have ENORMOUS amounts of "hacks" in them to make it all "seem easy". What you're "used to using" seems easy almost regardless of how easy the alternative is. Case in point within the LV environment. I don't yet use the wonderful option that Darren demonstrated so well at NI Week. Having to move to the keyboard while in LV is SO FOREIGN to me that it seems slower to me than just using my trackpad and dropping down the pallets. Now which way is really "easier"? If you're on a desktop system and need a mouse (or a laptop and USE a mouse) then moving to the keyboard to type a bit doesn't seem like a big deal but, if you're NOT using a mouse at all then it really can become a far digger deal. The feature is great and I'll get into using it "at some point" but it's not high on my list while I have development and tech support demands on me like I do currently.

Yes, NI could do some things differently but I'm not so sure that it's just "noobs" who like the current orientation of the company.

QUOTE (bsvingen @ Jan 31 2009, 01:31 AM)

I am in fact essentially a LabVIEW guy and I tried to answer the original question of why there are no open source alternatives to LabVIEW. The answer is obvious: NI-DAQ drivers that can be used out of the box for C, C++, .NET, C#, VB, Matlab (and probably many more with slight modifications, wrappers etc), so the need for yet another language really isn't there. And when you start thinking about it an open source version would have to use those NI-DAQ drivers, there are no other options. You would also need an open source high performance window system, http://www.qtsoftware.com/' rel='nofollow' target="_blank">Qt . The point is, Qt is here, it works for all operating systems (even smartphones soon) in both C++ and Java, NI-DAQ is here and works for all operating systems, everything is here, but what purpose would it serve? You would be better off just using Qt as is using the TONS of scientific software already available as open source, with full readable source code.

We even have an old Mac in our lab with a full functioning LV 1.0 on it What point am I missing exactly?

You make my point. "Readable" means text-based and that ain't LV although, as you well know, LV can make use of text-based language constructs.

QUOTE (bsvingen @ Jan 31 2009, 12:35 AM)

The original question was why aren't there any open source alternatives to LabVIEW. Please correct me if I am wrong, but as far as I know NI-DAQmx still supports .NET, VB, Visual C/C++, C# and even Matlab straight out of the box (with the DAQ toolbox in Matlab). Drivers for using C in LINUX is also supported. I know many laboratory personell that have used BASIC with NI-DAQ (the old version) with NI hardware for decades.

What would an open source initiative add to the world of DAQ? Data Acquisition is inherently hardware based, and will allways be. I have allways thought that the real strength of NI is the NI-DAQ drivers, enabling the use of NI hardware for just about every thing possible. LabVIEW is just an add-on enabling easy or fast use of NI hardware.

LabVIEW has grown way beyond being just an easy eaccess to NI-DAQ, but as a general programming language it simply falls short compared with text based programming with few exceptions. It is good for two things: data acquisition and user interfaces, but it is utterly closed, you can't even look at the source without installing LabVIEW.

An open source labview is certainly doable from a DAQ point of view, all the drivers are there. The "perfect labview" IMHO, would be a native by-ref object based version with seemless integration with C++, more as a user interface builder for C++. But then again, this is more or less exactly what Qt is, it is open source, works on all operating systems, and there should be no problems using NI-DAQ with it

In other words, you're essentially a C++ guy, committed to open source, who just wants a graphical interface. FWIW, I think you're missing the point of what LV is and does but then again everyone is entitled to their own opinions.

QUOTE (Aristos Queue @ Jan 30 2009, 04:45 PM)

I have thought so too, but IANAM*.

*I Am Not A Marketer

Perhaps yes, perhaps no. I think the biggest two hurdles for LV gaining such "general" acceptance as REAL programming environment are its "high" cost and its undercutting of how much traditional programmers need to do in architecting large, complex apps.

No, I'm not saying that LV costs too much, I'm saying the perception is that the cost is high. I've heard so called "real" programmers complain that they can buy x,y, or compiler of IDE for much, much less. Of course in those analyses leave out the costs of the additional libraries, reference materials, courses to attend and overall development time (and cost). Those other aspect simply are seen as "the costs of doing business" and so seem to not "count".

The second issue is IMO the more profound one as it goes to the whole issue of identity and that issue drives a lot of what most humans do. The idea that one doesn't have to be a "guru" to do high-level work does seem to be offensive to a number of the more traditional text-based programmers I've known over the years.

I think a side note to some of that second issue is the way some live out their commitment to open source initiative. Whether or not people know about OpenG and its wonderful efforts, there is a perception that LV is a "closed shop" and some more traditional text-based folks that I know, really don't like that at all. I have always found that interesting in terms of the commitment that some of those same people have to MS products but I guess "that's different" as Emily Latella would have said.

QUOTE (Aristos Queue @ Jan 30 2009, 01:34 PM)

Except that it hasn't been a problem for most of our history. Our bread and butter comes from the zero-experience-with-CS engineers and scientists. Those of you who are skilled programmers and use LabVIEW as a "fully armed and operational battle station" are a much smaller group, though you're growing. But because the bulk of users are in that first group, we do tend to spin LabVIEW for only that first usage. Heretofore it has paid the bills well and we've spread in more advanced contexts by word of mouth and the lone LV user who smuggles a copy of LV into his/her circle of C++-using co-workers. It certainly will be a problem in the future if the "large, full applications" group starts eclipsing the "one while loop around three Express VIs" group, but my understanding is we're still a ways away from that inflection point.

How do you see that being a problem? FWIW it seems to me that keeping both "groups" of LV users active and happy is what counts and is pretty "doable". At a certain level other programmers likely won't get it for quite awhile -- too much investment in "BetaMax and 8 tracks", but perhaps that's just my opinion.

QUOTE (shoneill @ Jan 30 2009, 12:44 PM)

I chimed in too.

Man I really wish NI would do something about this "easy to use" and "no programming required" marketing guff. I mean WTF?

It's hardly surprising these people have these opinions, they're being forced down their throat by NI....

Shane.

Shane,

I beg to differ. LV is easy to use and no background in CS is needed -- to at least get SOMETHING running and sometimes even quite serviceable code. Try to do THAT with C++...

What part of those phrases disturbs you? Is it the implication that one CAN potentially do more with less CS background or is it something else?

QUOTE (dblk22vball @ Jan 30 2009, 11:28 AM)

i chimed in a bit for LV, people still want to call LabVIEW for kindergarder programmers, BOOO!!

I chimed in as well. The problem is that LV does make it "too easy" to do REAL programming and not have a CS background. That generates jealousy and anger esp from those who've invested years in learning the arcana of overloading functions from some obscure lib somewhere. The buggy whip manufacturers got really upset by automobiles...

QUOTE (jcarmody @ Jan 29 2009, 03:27 AM)

I don't think that this will work if the Pause control is handled in an Event Structure because setting the value of a control doesn't trigger an event. I discovered this yesterday and ended up putting a Value (Signaling) property node in the Timeout case.

Jim

That depends on whether you want to trigger the event structure (Value (Signalling)) or just set the value and let the logic of that subs dataflow determine the action to take. Both are available and there can be reasons to use each, in different instances. For instance going into Pause=True one might want to make Run=False or something equivalent and that might mean Pause is Signalling whereas Run is just Value.