bsvingen

Or better, make the error wires invisible. Seriously, they mess up the diagram wile serving only an implicit function that distracts away from the flow of data. I mean, LV is dataflow - not errorflow. There could be a switch that makes them visible/invisible, and the connectors could be "filled" when a wire is connected and unfilled when not.

Or better, make the error wires invisible. Seriously, they mess up the diagram wile serving only an implicit function that distracts away from the flow of data. I mean, LV is dataflow - not errorflow. There could be a switch that makes them visible/invisible, and the connectors could be "filled" when a wire is connected and unfilled when not.

I think the best source is the Ptolemy web site, with tons of info. Here is a ppt file with some basic info. Ptolemy is open source, and the best way to study actor oriented design is to download and use Ptolemy, or at least look at some examples. Ptolemy is really super high quality stuff. An actor is very simple. A LabVIEW vi is an actor by the definition of an actor. Data flows through it, and it has input and output ports as well as parameters and/or states (state machine). In contrast, no data flows through a GOOP/C++ object, a GOOP object has data that has to be initialized and methods that has to be invoked. An LVOOP vi is like a super star (Marlon Brando ). It can take different kinds of data and do different things according to what data actually enters + lots of other usefull stuff (encapsulation, better modularity, less coding and so on). An actor IS the machine firing up automatically when data enters, while a GOOP is a vague representation of what the machine can do with no concept of time, it has to be told to act.

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

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.

C++ is no problem, but you have to make wrappers. I am using C++ for lots of stuff: http://wiki.lavag.org/DLL/shared_library http://forums.lavag.org/C-classes-from-LV-t12905.html Depending on the complexity of the C++ classes and code, it could be done very fast, or it could be much more difficult. You only need to make wrappers for the stuff you need, and make sure that the wrappers get access to the C++ code.

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?

It was mainly just something I was wondering about. You can get some info here. In the early 90s there were alot of development in mathematical packages using C++ due to the OOP functionality, but lots of it simply died due to performance penalty, ranging from 20% at best, to a factor of 10 compared with FORTRAN (or sometimes C programmed in "FORTRAN fashion"). Templates even the table a bit (lots actually) while maintaining most of the flexibility of OOP.

One drawback with OOP i the loss of execution speed. In C++ templates can often be used instead of inheretence, offering the same/similar functionality in most cases, and with no loss of speed. Could this be something for LVOOP? Or will this simply be the same as a polymorphic vi? Can this be done with LVOOP classes?

I mostly find labelling wires to be confusing and difficult to work with. They don't really show any information that is not already there in most cases, unless you have really long wires. They are free labels, meaning the automatic wiring tools will route wires around them. All in all, I have stopped using them entirely. An alternative method is to use the "Description and tip..." when rightklicking on the wire. Open the online help, Ctrl-h, and now you see the "label" or description when your mouse is hoovering above the wire. An added bonus is that wire branches will also have the same description. This is a much better solution IMO.

Look under "Fundamentals->Graphs and Charts" with the example finder.

QUOTE (Gary Rubin @ Feb 5 2009, 02:38 PM) thanks. (once LabVIEW - always LabVIEW) Off topic: There was in fact an error with the Scilab to labview node ver 1.1. It was fixed in the Scilab 5.1 series build. So it works, but you have to use a "non stable" Scilab version, hmmm.

QUOTE (Val Brown @ Feb 4 2009, 09:41 PM) I think it is more to it than that. There is something called algorithms, and this is where LabVIEW falls bang to the floor. LV is good at expressing data flow, but terrible at expressing the algorithms operating on that data. FORTRAN is extremely good and incredible efficient at it, while C/C++ is more than adequate and extremely flexible. Matlab is also extremely good at it, but inefficient enough to be nothing more than a university tool. I mean, how would a general purpose matrix solver look in G? completely incomprehendable, that's how. A side note. Downloaded that Scilab-LV thing along with Scilab. There is a new version from desember 2008, but it seems broken, giving a runtime error. Anyone else got it to work?

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

QUOTE (Mark Yedinak @ Feb 3 2009, 09:03 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

With a bit of theoretical work, you can show that any programming paradigm is "perfect" for just about anything. This doesn't mean that a specialized programming language like LV is a general purpose language just because it uses dataflow. On the other hand, Java is indeed a general purpose object oriented language like C++, but Java is abselutely useless for making low level stuff like drivers for instance. I mean, programming paradigm is only one of several pieces that makes a language "tick" in the real world. I use LV for lots of things as well, but I have grown more and more sceptical using it for general purposes. The cost is one major issue. If you use it in the lab with equipment costing several millions, this cost is easely justfied. As a general purpose language, the cost is way too high, when looking at the alternatives which cost nothing (Java, C/C++ etc.) I think most people using LV as a general purpose language, started using it in the lab. Then they got more and more professional with it, and also started using it for other tasks as well (why use a month learning Qt and some more C++/Java when I can do this in one evening using LV? right?) This is all very fine, but sooner or later, if your code base develops, you will get into practical problems with license cost, portability, maintainability, not necessary for yourself but for others and for future development and certainly for future distribution. These are problems that naturally surfaces due to the fact that you are using a highly specialized proprietary programming language. You cannot even legally read the source without a valid license. For a general purpose language this is a big NO NO. These are real world problems that you simply cannot get around untill NI start licensing LV the same way Sun is licensing Java (which doesn't seem to happen any time soon). Anyway, I'm not saying "don't use LV". I think LV is excellent. But it is not a general purpose language, not in any stretch of the word. If you use it as a general purpose language, you should be aware that you could face unsolvable problems in the future.

QUOTE (jdunham @ Feb 2 2009, 06:16 AM) Yes, but everything about LabVIEW is tuned towards dataflow. This is intuitive for datalogging where data is in fact flowing or streaming, but counterintuitive for just about everything else where no data is flowing, or at least you would not naturally think in those terms. Classic GOOP is more intuitive in most situations, because the data has now stopped flowing, it is only changing based on the reference that is flowing. LVOOP is somewhat more tuned towards dataflow than ordinary dataflow, because in addition to the data flowing, the functions and knowledge of what can be done to that particular data is also flowing (dynamic dispatch). Another thing that is counterintuitive and IMO counterproductive for everything except streaming data, is the left-to-right paradigm. The natural thing to do when you can program in two dimensions, is to fully use those dimensions to build abstract programming topologies or topologies representing real world topologies where data and messenges flows in all directions. This also requires objects with persistent datastorage in the form of GOOP (or more precisely reentrant LV2 style globals) rather than LVOOP. Complex programs can be built easely using this "paradigm", because the topology inherently within all software is simply laid out on the screen. This can be done today in LV, but it is cluttered and confusing because of the left-to-right paradigm, and becomes utterly counterintuitive for someone thinking only in dataflow. LabVIEW is similar to FORTRAN. They both can be used to make any kind of program, but they are both really only good at doing one single thing; datalogging and number crunching respectively. Like FORTRAN, the reason for this is not inherent shortcomings in the language structure, but because they both are tuned towards those specific tasks.

QUOTE (Val Brown @ Jan 31 2009, 09:58 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?

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

QUOTE (Michael_Aivaliotis @ Jan 21 2009, 10:53 PM) Maybe so, but there aren't many valid arguments for releasing scripting here either. From a pragmatic point of view, it is pretty obvious that NI lacks arguments for releasing it, but they have tons of arguments against it. What exactly those arguments are and if they are valid, makes no difference relating to the simple fact that they lack valid arguments for it.

Does anyone have any info about the built-in functions in the library node? The functions you get when writing "LabVIEW" in the "Libraary name or path" window ?

Maybe they feel that scripting doesn't add any real value unless you are developing LabVIEW? I mean, you don't need scripting to make a good logging program. Scripting is compleletly incompatible with the KISS principle but there are lots of questionable? uses for it when making toolkits and stuff like that.

Download File:post-4885-1232315590.zipUsing C++ classes in LV is something that pops up now and then. Searching the net is almost fruitless, untill I found this site. I simplified it a bit to better understand what was going on, and called it from LV. I put it here with source and a compiled DLL in case someone else is searching for days to find out how to do this. The clue is of course to built a C wrapper and call it from LV, but that's not the main clue. The main clue is to make the wrapper opaque to the C++ code by typedefing a struct using the class, and pass a pointer to the struct. This way none of the C++ class code need to be touched. I think this can only be done in C++, not in plain C, because C++ doesn't differentiate between classes and structs, and plain C does not have classes. With this wrapper, the C++ classes can be used in principle like any other GOOP classes.

I have thought about this too. What i have come to is that in 90 % of the cases, all you need in an app is a straight forward PID controller with a minimum of "bells and whistles". In addition you probably in some cases need an integrator and a derivator. The two latter things already exist in the math library in LabVIEW, and a simple PID is made in 5-10 minutes. If you have a good PID, then the code repository on this site is a better place IMO. If you focus on "what is possible to do" instead of "what do most of us actually need and want", then there really is no limit to the complexity you can make out of this toolkit, and you end up making a simulation toolkit al

IMO this is a typical example of something that requires a lot of work and a lot of time, still - all you could realistically hope to acheive (within the constraints of a challenge) is a tool that does this on a small subset of all the functions that exist. Besides, such a tool already exist (by the looks of it, at least some bits and pieces) in the "...vi.lib\_script\XML Scripting" folder in LV8.2 What would be more interresting, and also a lot easier and faster, is to write a compiler that makes VIs out of a textual language. Then you are free to make the language syntax and style anyway you like, without the restriction that it has to be a textual representation of the VI. Nevertheless, i'm much more for challenges that most of us actually has time to do, since the usefulness of any code resulting from a challenge will be very limited at best. I think a good challenge is not one that pushes the limits, but rather one that sparks off creative solutions.