8

I am trying to determine which of these two to buy for my work. I have used SIMULINK but not LabVIEW. Is there anyone who has used both and would like to provide some details? My investigation criteria are the user friendliness, availability of libraries and template functions, real-time probing facility, COTS hardware interfacing opportunity, quality of code generation, design for testability (i.e. ease of generating unit/acceptance tests), etc. However, if anyone would like to educate me with more criteria, please do so by all means!

For anyone who does not know about SIMULINK and LabVIEW - These are both Domain-Specific Languages (DSLs) intended for graphical dataflow modelling (and also code generation). These are multi-industrial tools and quite heavily used for engineering design and modelling.

IMPORTANT - I am quite interested to know if SIMULINK and LabVIEW offer real-time probing. For example, I have a model that I want to simulate. If there are variables associated to certain building blocks in that model, could I view them changing as the simulation continues? I know that it is certainly not possible with SIMULINK as it has a step-by-step debugger. I am not aware of anything similar in LabVIEW.

I really have not used LabVIEW and cannot obtain it temporarily as my work internet has got download restrictions and administrative privilege issues. This is the reason why I simply cannot use only NI website to draw conclusions. If there is any white paper available that addresses this issue, I would also love to know :)

UPDATE SINCE LAST POST

I have used MATLAB code generator and will not say that it is the best. However, I hear now that SIMULINK Embedded Coder is the best code generator and almost one of its own kind. Can anyone confirm whether or not this is good for safety critical system design i.e. generating code from safety-critical subsystem models. I know that the Mathworks is constantly trying to close the gap to achieve fully-flexible production-level C/C++ code generation.

I know that an ideal answer would be,"Depending on what you are trying to do, use a bit of both". And interestingly, I think I am heading to that direction. ATEOTD, it is a lot of money and need to be spent "nicely".

Thanks in advance.

ha9u63ar
  • 4,811
  • 7
  • 54
  • 80

6 Answers6

17

I used labVIEW from 1995, and Simulink from 2000. Now I am involved in control system design, and simulation of robotic systems using labVIEW Real Time and automotive ECUs using MATALAB/Simulink/DSPACE .

LabVIEW is focus on measurement systems, and MATLAB/SIMULINK in dynamic simulation, so,

If you run complex simulations, and your work is create/debug complex simulation models of controllers or plants, use Simulink+RealTimeWorkShop+StateFlowChart. LabVIEW has no eficient code generators for dynamic simulation. RTW generates smaller and fastest code.

If your main work is developing systems with controllers and GUI for machines, or you want to deploy the controllers on field, use labVIEW.

If your main work is developing flexible HIL or SIL systems, with a good GUI, you can use VeriStand. Veristand can mix Simulink and LabVIEW code.

And if you have a big budget ( VERY BIG ) and you are working in automotive control prototypes, DSPACE hardware is a very good choice for fast development of automotive ECUS, or OPAL to develope electric power circuits. But only for prototype or HIL testing of controllers.

From the point of view of COTS hardware: Mathworks don´t manufacture hardware -> Matlab/Simulink support hardware from several vendors.

National Instruments produce/sell hardware->LabVIEW Real Time is focused in support NationalInstruments hardware. There are no COTS full replacement.

Tyler
  • 947
  • 9
  • 19
Jesus Alfonso
  • 171
  • 2
7

I have absolutely no experience with Simulink, so I'll comment only on LV, although a quick read about Simulink on Wikipedia seems to indicate that it's focused mainly on simulation and modelling, which is certainly not the case with LabVIEW.

OK, so first of all, LV is NOT a DSL. While you wouldn't want to use it for any project, it's a general purpose programming language and you should take that into account. I know that NI has a simulation toolkit for LV, which might help you if that's what you're after, but I have absolutely no experience with it. The images I saw of it seemed to indicate that it adds a special kind of diagram to LV for simulation.

Second, LV is not restricted to any kind of hardware. It's a general purpose language, so you can write code which won't use any hardware at all, code which will use or run on NI's hardware or code which will use any hardware (be it through DLL calls, .NET assemblies, RS232, TCP, GPIB or any other option you can think of). There is quite a large collection of LV drivers for various devices and the quality of the driver usually depends on who wrote it.

Third, you can certainly probe in real time in LV. You write your code, just as you would in C or Java, and when you run it, you have several debugging options:

  1. Single stepping. This isn't actually all that common, partially because LV is parallel.
  2. Execution highlighting. This runs the code in slow motion, while showing all the values in the various wires.
  3. Probes, which show you the last value that each wire had, where wires fill the same function that variables do in text based languages. This updates in real time and I assume is what you want.
  4. Retain wire values, which allows you to probe a wire even after data passed through it. This is similar to what you get in text based IDEs with variables. In LV you don't usually have it because wire values are transient, so the value is not kept around unless you explicitly ask for it.

Of course, since you're talking about code, you could also simply write the code to display the values to the screen on a graph or a numeric indicator or to log them to a file, so there should be no need for actual probing. You could also add analysis code, etc.

Fourth, you could try downloading and running LV in a fully functional evaluation mode. If I remember correctly, NI currently gives you 7 days and then 45 days if you register on their site. If you can't do that on a work computer, you could try at home. If your problem is only with downloading, you could try contacting your local NI office and asking them to send you a DVD.

Note that I don't really know anything about modelling and simulation, so I have no idea what kind of code you would actually have to write in order to do what you want. I assume that if NI has a special module for it, then it's not something that you can completely cover in regular code (at least not if you want the original notation), but I would say that if you could write the code that does what you want in C, there's no reason you shouldn't be able to write it in LV (assuming, of course, that you know how to write code in LV).

Yair
  • 2,161
  • 11
  • 12
  • +1 only because you know LV :)...I will certainly and most respectfully disagree that LabVIEW isn't DSL. LabVIEW is not a language itself, but wrapping another programming language called "G" which is apparently not very well-known such as C/C++/Java. I do agree with your argument that just because it has not been tried for multiple things doesn't mean that it isn't doable. All the use-case examples on NI's website suggest that control system, data aquisition, measurement, and testing are the key area of application. Your answer is good and with valid arguments! Thanks! – ha9u63ar Jun 19 '13 at 10:38
  • 3
    You're right that technically isn't a language at all, since it's the name of the IDE, but then the argument simply moves to whether G is a DSL or not. My understanding is that years ago NI had some legal issues with using G as the name for the language, which is why you don't see it around much. In practice, LV and G are synonymous. And while I agree that LV isn't very well known, and that it's mostly used in specific areas, it's still technically a fully functional general purpose language (although, again, that doesn't mean that it's good for everything). – Yair Jun 19 '13 at 11:07
  • 1
    LV is actually very well known now these days and in fact, replaced some SIMULINK based design infrastructure in aerospace and defence industries. Even the price is more reasonable in some cases compared to SIMULINK :). I really need to make a decision how I am going to maintain these tools. I guess using LV is better as it supports SIMULINK model inputs. Cannot beat the driver support for NI hardware, but that doesn't mean they don't have drivers for third party ones. – ha9u63ar Jun 19 '13 at 12:08
  • 1
    I was thinking of LV as not being very well known by programmers. It is true that in some places it is well known (labs, engineering departments in the academy, aerospace, car manufacturers, etc.). In any case, you could also try asking your question in the LabVIEW board in the NI forums, where I think there are some people who use Simulink. If you do, be sure to link here as well. I'm assuming that Simulink is better for some things (Interaction with MATLAB? Maybe simulation?) and that LV is better at other things (writing custom code). I have no idea which one is more suitable for you. – Yair Jun 19 '13 at 13:11
  • Good suggestion! I think it will be a combination anyway as some of the data I use are in SIMULINK, but doesn't cause harm to use them in LabVIEW. The good thing aboug LabVIEW is that I can wrap the LV models with C function calls so that I can use them in my core software without having to generate code for the models. – ha9u63ar Jun 19 '13 at 13:41
1

A lot of the best answer would have to depend on your ultimate design requirements. Are you developing a product? If so, in what stage of development are you? Or are you doing research?

I recently did a comparison just as you are doing. I know LV, but was wanting to move towards a more hardware-scalable option, since NI HW is very expensive in volume. That is, my company was wanting to move towards a product. What LV and NI HW give you is flexibility. You can change code very quickly compared to C. On the other hand, LV does not run on nearly as many different HW platforms as C. So I wanted to find an inexpensive platform that would work well for real-time control and data acquisition, such that if we wanted to sell a product for, say, $30k, our controller wouldn't be costing $15k of that. We ended up with Diamond Systems Linux SBC's. Interestingly, Simulink ended up using the most expensive hardware! It did have a lot of flexibility, and could generate code, as well as model plants and controllers. But then, LV can do that as well.

As Yair wrote, LV has plenty of good debugging tools. One of the more interesting tools that is not so well known is the Suspend when Called option for a SubVI. This allows you to play with the inputs and outputs of a SubVI as much as you want while execution is paused.

Adrian Keister
  • 566
  • 2
  • 9
  • 27
  • 1
    I think you can use wrappers around your LabVIEW models/libraries to ensure a good interface with your legacy C or FORTRAN code. In fact, a company called Keenan Simulation in USA have refurbished the old Single Link FFS for McDonnell Douglas DC-9 aircraft. You can find the story in National Instruments website. – ha9u63ar Jun 27 '13 at 06:29
  • Perhaps, although LV does not have the reliability and "tested"-ness of C. In our case, LV *was* the legacy code, and we moved towards C. – Adrian Keister Jun 27 '13 at 14:49
  • Really! That is a bit strange as I hear from people in modelling and simulation that LV is doing the job right! But of course, your use case are not necessarily the same. – ha9u63ar Jun 27 '13 at 14:52
  • 1
    Yeah, we're talking NASA-reliable. LV crashes too often. In fact, the path that we took is pretty much exactly the same path that NASA took for one of their projects. They were using LV, but their reliability engineers took one look at LV and said, "Not stable enough." So they moved to Diamond Systems Linux with C for moving towards a flight-ready system. By the way, a typical path towards a product is LV or Simulink, then C, then custom PCB. – Adrian Keister Jun 27 '13 at 14:55
  • `@AdrianKeister` You seem to be quite close to my industry. I am surprised that LV does all those advertisement and actually not helpful when it comes to something as complex as NASA or Interservice avionics. +1 for adding the "By the way" bit at the end :) Really helpful. – ha9u63ar Jun 28 '13 at 08:45
  • Btw....NASA Mars Rover used LabVIEW software and NI hardware.....just remembered :) – ha9u63ar Jun 30 '13 at 21:46
1

MATLAB and Simulink are the defacto standard for control system design and simulation. Simulink controller models can be used for offline simulation in conjunction with plant models, all the way to realtime implementation on embedded targets. It is a general simulation framework with extensive built-in libraries as well as a la carte special purpose libraries, and can be extended through creation of custom blocks (S-function blocks) in C and other languages. It includes the ability to display values in graphs, numeric displays, gages, etc. while a nonrealtime simulation is taking place. Realtime target support from The Mathworks includes x86 (xPC Target) and several embedded targets (MPC555, etc.), and there is 3rd party support for other targets. The aforementioned dSPACE provides complete prototyping controllers including support for their quite powerful hardware. xPC Target includes support for a plethora of COTS PC data acquisition cards. Realtime target support includes GUI elements such as graphs, numeric displays gages, etc.

mark
  • 11
  • 1
0

As I understand it (I have never really used it in anger), LabView only supports NI hardware, and is more hardware-oriented. Simulink supports hardware from multiple vendors, be it for data acquisition, or real-time implementation, but it may require a bit more work for the user to interface to his or her own hardware (less plug & play than LabView). On the other hand, Simulink provides tools to support the whole model-based design process, from modelling & simulation, control design, verification & validation, code generation, hardware-in-the-loop, etc...

Disclaimer: I used to work for MathWorks.

am304
  • 13,425
  • 2
  • 19
  • 36
  • Thanks for your answer! When you say SIMULINK supports hardware from multiple vendors, what do you mean? Can you connect a COTS hardwar product to SIMULINK for data aquisition? I was not aware of that. – ha9u63ar Jun 19 '13 at 09:10
  • Also, can you do real-time probing into SIMULINK to display real-time values of C code used in the models? – ha9u63ar Jun 19 '13 at 09:15
  • 1
    @hagubear For data acquisition with Simulink, you will need the Data Acquisition Toolbox (http://www.mathworks.co.uk/products/daq/), which provides analog and digital I/O blocks for various hardware (https://www.mathworks.co.uk/products/daq/supported/data-acquisition-cards-and-boards.html). – am304 Jun 19 '13 at 09:58
  • 1
    @hagubear Not sure about the real-time values displayed. I suspect the answer is yes with an S-function, but bear in mind that Simulink runs on Windows or other non-real-time O/S and therefore it won't be in "hard" real-time, but "soft" real-time. – am304 Jun 19 '13 at 09:59
  • @am304 - it's true that if you are running Simulink on a non-rtos then results will not be in hard real-time (and I'm not sure you can technically even call them soft real-time). That said, it is possible to run Simulink models in real-time using [xPC Target](http://www.mathworks.com/products/xpctarget). – grungetta Jun 19 '13 at 17:58
  • @grungetta True, but xPC Target runs a real-time kernel on a target PC machine, so it's not really Simulink, but rather generated C code from Simulink you are talking about. In this case, it is "hard" real-time. Another option, which doesn't require a separate target PC, is Real-Time Windows Target. – am304 Jun 20 '13 at 09:17
  • 3
    It is absolutely not true that LabVIEW only supports NI hardware. – nekomatic Jun 21 '13 at 20:05
  • @nekomatic Thanks, I stand corrected. As I said, it was my understanding, I never claimed to be an expert in LabView, on the contrary! – am304 Jun 24 '13 at 08:43
  • " LabView only supports NI hardware"---> VERY WRONG. – Kamran Bigdely Oct 12 '13 at 05:07
  • @kami See my comment to nekomatic. The same applies. – am304 Oct 12 '13 at 12:20
0

You guys may really be interested in Control Design adn Simulation Module for LabVIEW. It does a lot of simulations and in the future may be competitive to Simulink. I'm not a control engineer but I use it sometimes for simple testing and I'm glad that I don't have to learn Simulink from the beginning to do some work since I'm familiar with LabVIEW philosophy.

akson128
  • 61
  • 1
  • 5