LabVIEW
NI DAQmx for matlab takes literally FOREVER to install
@3dfernando wrote:
It took 6 hours. I lost an entire workday. This is just nuts.
I suspect your issue with installation is due to a versioning problem. Unfortunately I can't share the discussion, but you might (if you have to do this again) have a better time if you first install NI Certificates version 21.0 before DAQmx (or install an older DAQmx version, but probably you'd prefer not to do that).
In general, the popup should only appear once (if you check the box), and the fact that it appeared repeatedly for you might be an indication the installed certification was older than the drivers you were installing.
@3dfernando wrote:
Replying to your comment, I understand your position but you have to understand that not everyone thinks like you. I find LabVIEW a terrible programming environment, ...
I also thought LabVIEW was a strange-looking misfit when I first came across it (lab setting, a previous PostDoc bought a bunch of NI hardware, then I needed to program it... coming from C++, it seemed very unusual/unnecessarily screen-occupying).
After a couple of weeks, I changed my mind. Now I like it for basically all the non-web programming that I do, including in some cases data processing. Certainly for acquisition, storage and metadata additions.
@3dfernando wrote:
Matlab (and other text based programming languages) are far superior in searchability, community size, availability of library functions for big data processing, and debugging. I'd go as far as saying that LabVIEW is not even a real programming language.
- Searchability - I'm not convinced, but I guess maybe. I think this probably ties in with one of your later points, so I'll comment on it there. A key point you might be missing is the Context Help (Ctrl+H) which would tell you the names of things you hover over, allowing you to search with those terms (rather than an image, which I agree is not easy to use for searching). Context Help (and the accompanying Detailed Help link) might also remove the need to search elsewhere...
- Community size - I'm sure you're right about this. I don't think many here would believe that LabVIEW has a larger (by number of individuals) community than e.g. C/C++, Python, Java, JavaScript/TS, or perhaps even MATLAB (not sure about that one, but certainly in academia I'd say more people are familiar with MATLAB). However, not sure it's a relevant metric, just a common proxy. What I really care about is the speed with which I can have questions answered, and the speed/quality I can solve a problem with (here, the presumably related point is more people -> more community libraries -> quicker solutions, although I think there are counter examples, like too many libraries -> decision paralysis, bad libraries -> reworking repeatedly, etc).
- Availability of library functions for (XYZ | big data processing). Probably true that some languages targeting XYZ | big data processing have more tools for those tasks. LabVIEW has advantages, so does R. Like Bob mentioned, the fact that LabVIEW is good for A,B,C doesn't inherently mean it's good for X,Y,Z, but I'd suggest it could be if you were more familiar. The same is probably true for Python though, which I strongly avoid, so each to their own.
- Not a real programming language. Sorry, this is just wrong. And in the context of comparison with MATLAB (which is not /barely a programming language), it's a bit ironic. In fairness to MathWorks, MATLAB has improved on its offerings with regards to software engineering etc over the last few years, and since I was an undergrad the help files have drastically improved (my original reason for disliking MATLAB - you couldn't do it without Google in the other hand).
@3dfernando wrote:
I personally don't care if I can make GUIs with lab view. I don't think any of my colleagues cares either. I just want to make my one-off experiment acquire some automated data and process it. I know how to code quite proficiently... [in MATLAB]. I'll process the data in Matlab anyways so why not use it for everything?
Fair enough. I tried using GUIDE once for MATLAB, that was a painful experience, and many of my colleagues functions involving UI clicks on graphs etc in MATLAB also cause grief, and make things harder to automate, but if you truly don't need a GUI, then ease of GUI development is indeed irrelevant.
Re why not use it for everything? - Because you want to use the NI hardware, would seem to be the reason, so you're choosing to also use the NI drivers (sensible, but not inherently required - you could reverse engineer the entire thing and write your own drivers if you had nothing better to do for the next few ... [appropriate timespan here, I'd expect years maybe, but perhaps that's optimistic, depending on the range of hardware you wanted to support]).
Why not process the data in LabVIEW? What operations are you carrying out? (For that matter, what types of data are you acquiring?)
My colleague and I do a sizeable chunk of processing with MATLAB, mostly by saving (to NI's TDMS files, although you could pick another format) from LabVIEW and then loading the file in MATLAB for the generation of other results.
You could also save from LabVIEW directly to .mat file, if you're willing to jump through a few dozen hoops.
The simplest solution would be something like CSV, but your data volume/rates might be prohibitive of non-binary storage formats.
From a later reply:
Coding is easier in text-based languages. Coding is, in this day and age, a survival skill; and text-based code is superior, hands down. You can be colorblind (like me) and not have to struggle to discern whether that solid green line in your VI is a double data type or whatever else. If you don't remember what a function does, you can google its name and always find precise information about its arguments and what it does. If you see somebody else's code and there's a function you don't know, it is trivial to find it online and find out what it does. Good luck doing that with the little box elements in Labview. Not even a google image search will do the job (I've tried). None of the experiments in my career ever needed a front panel. I just need to acquire some data and automate some motor/solenoid/light/switch/whatever. What you're proposing is a botched workaround at best.
Labview is an outdated language. There's no discussion about it. It was a good effort, but we moved on. NI is the only company that refuses to realize and, to some extent, you've become a cult. I am just expressing what others won't bother to or don't know any better. So far in my career, I've done experiments far more impressive than what could ever be possible in Labview by using Matlab. I get praise from my peers because I can do so much with my experiments in so little time while they're struggling to build a string with a lego-like system designed for 5-year-olds. If you want to do any non-trivial data analysis Matlab is THE industry standard. If you want your experiment to do such analysis as it runs itself, computing different information on-the-go to make decisions along the way of what cases to explore next, it is insurmountable to build with a graphical language. Graphical languages are a gimmick and they have to go. If NI didn't make the exceptional hardware it did, it would already be out of business.
- Colorblindness - you can change the colours LabVIEW uses if you like. It might make it harder to understand for others viewing your code, but of course that's a secondary concern if you're writing it. It's also a per-installation setting, so if you use Git with me and I download your code, I see it in "my" colours, whilst you see it in yours.
- Remembering functions - see earlier comment about Context Help (Ctrl+H)
- Unnecessary front panels - ok, sure. Re "botched workaround", I think saving and loading data is a sensible method to communicate between languages, and TCP/IP or shared memory would also work if you needed them to run concurrently and process as acquiring.
- Outdated language. Seems unlikely, plenty of people still like it as a language. "Moved on" -> to text based? Didn't text-based exist before LabVIEW? Seems like it was doing just fine at the same time to me, I'd say they're compatible and it's hardly like the entire programming community moved to LabVIEW (they didn't) and is now discarding it for text-based (some are expressing concern with NI, but I don't speak to many who are too concerned about LabVIEW as a language).
- "experiments far more impressive than what could ever be possible in LabVIEW" - doubtful, although it might be that it would take longer in LabVIEW. I don't think it would be impossible in general. "by using Matlab. I get praise from my peers because..." - congratulations. Others feel the same way about LabVIEW. I'd say there actually are things that can't be done natively with MATLAB though.
- "non-trivial data analysis MATLAB is THE industry standard" - then use it? As, indeed, you seem happy to. And you also have the DAQmx drivers for the Data Acquisition toolbox, which as far as we know so far hasn't caused any issues except the annoying certificates behaviour during installation, and delays. Irritating, but hardly project-destroying (I assume you occasionally have less-than-totally-productive days, or try something and all you learn is that it didn't work. If not, congratulations again, although I'd ask if you're really doing research...)
- "If you want your experiment to do such analysis as it runs itself, computing different information on-the-go to make decisions along the way of what cases to explore next, it is insurmountable to build with a graphical language." - definitely not true, I have such a system in the lab I work in, I'm sure many others on this forum also do similar things. Whilst me asserting I know this to be false doesn't provide you with proof, I hope you'll accept it anyway. You might not know how to do it with LabVIEW, but I can tell you it's possible.
- "gimmick" - hmm, don't agree, but since I'd take this statement more as an expression of your opinion than a claimed fact, you're I suppose free to feel that way (although I'd hope you might give this "gimmick" a little more time to impress you - as I said earlier, I also felt it was silly when I first saw it).
