04-04-2022 12:44 PM
I don't even know which forum to post this, because there are so many NI forums (why?).
I am incredibly, incredibly frustrated. I just upgraded Matlab, and I just want to have Matlab access an NI DAQ in a computer through the daq toolbox. In order to do so, I need to install "NI DAQ-mx" package. IT'S BEEN LITERALLY 4 HOURS AND IT'S NOT EVEN DONE!
What the hell, NI? This is bull****. Not only the installation process is excruciatingly slow, but it constantly pops up Windows messages asking for permission to install; which DO have a checkbox "always trust NI software" THAT DOESN'T WORK so it literally requires my attention for 4 hours!!
Do you not test your software? Do you not just, I don't know... TRY INSTALLING YOUR SOFTWARE? This is unacceptable user interface. Currently I am just a postdoc, but I sure will make sure to NEVER use NI devices anywhere I have the power to as I progress in my career. I would say, after going through this, that NI easily holds the title of THE WORST SOFTWARE ENGINEERING TEAM IN THE WORLD.
Unbelievable.
I know you'll censor me for this. I don't care. You already lost me as a customer.
04-05-2022 10:05 PM
(To the tune of "Anything You Can Do, I Can Do Better", from the Broadway Musical "Annie, Get Your Gun").
Anything Matlab Can Do, LabVIEW Can Do Better.
LabVIEW can do Anything better than Matlab.
(To the tune of "When I Was a Lad, from Gilbert and Sullivan's "H.M.S. Pinafore")
What, Better? Yes, Better! What, Better? Even Faster?
You mean it really is all compiled??
--------------------------------------
Seriously, I'm sorry you are having trouble installing NI DAQmx into Matlab. [I didn't know you even could install NI DAQmx in Matlab -- seems to me the problem is on the Matlab side ...]
I can tell you that doing a complete installation of, say, LabVIEW 2021 (32-bit) on a Windows 10 PC, the standard package with DAQmx, takes about 30-45 minutes, depending on your level of expertise. If you are trying to build a Virtual Instrument, something with a User-Friendly Front Panel, easy to maintain and use (unlike the design system in Matlab, was it called GLIDE, or something like that?), LabVIEW is very straight-forward and User Friendly. If you want to acquire data from hardware (USB, VISA, GPIB, GenICam) or communicate with other stations using TCP/IP, LabVIEW makes it easy.
Did I mention it is Graphical? Learning to "think Graphically" takes some experience and practice (a good mentor/instructor helps, too) -- it is far easier to grasp a well-designed VI than it is a dozen pages of Matlab listings.
[I used Matlab, somewhat grudgingly, for about two decades before I was introduced to LabVIEW. Some of my more "interesting" Matlab algorithms I've rewritten in LabVIEW -- much cleaner, easier to follow/debug/explain to others ...].
Bob Schor
04-06-2022 11:54 AM
It took 6 hours. I lost an entire workday. This is just nuts.
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, and a lame language to program on. 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.
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 and debugging is just superior in Matlab. I'll process the data in Matlab anyways so why not use it for everything?
You guys blindly on the LabVIEW camp don't do any good to the community and are part of the reason I'll switch to other suppliers any time I have the chance to.
04-06-2022 09:26 PM
@3dfernando wrote:
It took 6 hours. I lost an entire workday. This is just nuts.
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, and a lame language to program on. 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.
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 and debugging is just superior in Matlab. I'll process the data in Matlab anyways so why not use it for everything?
I agree with you that "mixing languages" is often more trouble than it is worth. Why not let each system stand on its own strength? If you want to use DAQmx, which is made to work with LabVIEW, but only want to use it for a limited function (say, acquiring data and then handing it over to another program running on the same, or another, computer at the same time), why not install LabVIEW on a computer, learn enough to write a simple Data Acquisition routine, decide on a communication mechanism to deliver the data to a Matlab routine (some form of TCP/IP? Using "shared memory"? Some other method?), and let each routine "run to their strength". You might even be able to avoid installing LabVIEW on your machine by finding a colleague who knows (and has installed) LabVIEW, acquaint her (or him) with your Hardware, and ask for an Executable that will Do What You Need It to Do.
Bob Schor
04-07-2022 08:13 AM
I'll just leave you at this: You seem to be a fanboy. Someone who thinks NI doesn't need to change, NI is perfect, Labview is perfect. Fact is, in 2022 most engineers from all disciplines learn how to code. 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.
Anyway. I'll leave you at that. You don't seem to understand that the world moved on. Maybe you're one of those dinosaurs that got stuck in the 1990's or something.
04-07-2022 09:55 AM
Install times of NI products are well known to be too long in general, but 6h is ... excessive, to say the least. The pop ups make me think there's a policy and AV issue affecting stuff.
04-07-2022 10:40 AM
@3dfernando wrote:
I'll just leave you at this: You seem to be a fanboy. Someone who thinks NI doesn't need to change, NI is perfect, Labview is perfect. Fact is, in 2022 most engineers from all disciplines learn how to code. 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.
Anyway. I'll leave you at that. You don't seem to understand that the world moved on. Maybe you're one of those dinosaurs that got stuck in the 1990's or somethig
Well I'm glad the edge lord of all programming graced our little community to give us some sage advice : )
04-07-2022 10:51 AM
@3dfernando wrote:
I'll just leave you at this: You seem to be a fanboy. Someone who thinks NI doesn't need to change, NI is perfect, Labview is perfect. Fact is, in 2022 most engineers from all disciplines learn how to code. 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.
Anyway. I'll leave you at that. You don't seem to understand that the world moved on. Maybe you're one of those dinosaurs that got stuck in the 1990's or something.
Will somebody change his diaper already?
04-07-2022 04:39 PM
LabVIEW has nothing to do with this problem and it is clearly an issue on your side. I use DAQmx drivers in C# (with and without Measurement Studio) as well as python and the "install" was pretty much instantaneous. DAQmx comes in a tiny 6.5MB driver package so whatever Matlab is doing with its toolkit is the culprit. OR, it's some kind of permissions issue. Did you ask your IT guys???
I also did a quick search on MathWorks for "DAQmx install slow" and nobody else is complaining. Plenty of other issues of course, but no slow installs.
BTW, Python's Anaconda blows MatLab out of the water... and it's free. 😋
04-07-2022 08:48 PM
@3dfernando wrote:
I'll just leave you at this: You seem to be a fanboy. Someone who thinks NI doesn't need to change, NI is perfect, Labview is perfect.
Not quite accurate. Fortran was the first language I mastered, then Macro 11, eventually learning (and my favorite "text" language) Pascal ("real" Pascal, not the Borland variety). Not to mention PostScript. I also still have (and use) the four "M" languages (M as in Mathematics), Mathematica, MathCad, Maple, and MatLab. For what I'm now doing, LabVIEW not only does the job, but (thanks to "learning from others") has a lot of aesthetic appeal for me.
It was fun developing a VI that implements the Simplex method (I looked up my earlier Pascal version for some of the steps I'd forgotten). I'm glad you find such joy in MatLab, and wish you success in your career.
Bob Schor