EEVblog Electronics Community Forum
Products => Test Equipment => Topic started by: Coliban on April 17, 2019, 09:34:33 am
-
It´s a little bit surprising for me that this professional test equipment gains such a low interest if i compare the posts about test equipment. Once in a while in my business there come the question to get National Instruments and, for example PXI chassis and modules because of something "standardized" testing for example with LabView or LabWindows.
Therefore i reconsidered my private test equipment with several multimeter, oscilloscopes, signal generators, etc. and when i think about it, it would be much more compact and concise to have one chassis with several modules and a software in favour of several test devices and a zoo of test programs, equipment and starting from scratch every time i think of a new project. And therefore, the ramp up for every new project is cumbersome if there is some amount of time between them, because OS changes, computer changes, and i have to search and collect often from scratch interfaces, probes, devices and start from zero with testing or developing.
I am aware that such devices like from NI are expensive, but they have also small chassis for an reasonable amount of money with slots for 5 or 6 modules. In my mind (it is only a theory) the devices would be in place, the software would be in place and if i use the NI software, LabView for example, i always have a defined hook where to start from. And, before all, a functioning one.
Ok, maybe that's only ideal (or wishful) thinking from me, a theory, but what do you think, is it a good way (maybe a little bit more expensive) to set up an NI testing environment?
Ok, when i look at the prices i am convinced that the PXI prices makes the difference: a PXI chassis with 5 slots costs more costs 1250€ and the modules are not very cheap so an oscilloscope (modul) to operate on an connected computer would already costs. For companies where time is money (but for whom not) this would be a useful way.
But the compactRio modules are low priced and would be a good alternative for standardized and repeatable measurements in the private sector (?). The advantage is supposedly the high number of modules and the fast integration into the test environment.
Nevertheless, when i see the many test equipment here on EEVBLOG, which is sometimes very high priced, i wonder why such environments like LabView is not seen more often.
I wonder what the pro and cons may be.
Or do i bark up the wrong tree?
regards
-
For private use I found already an obstacle: for the software, in the cheapest configuration, LabView costs a fee of 400€ per year. I would not pay for software subscription (i refused that already for photoshop).
-
My three personal ramblings at NI
- Labview is one of the slowest pieces of software i've ever had to use. No matter how fast is the PC
- We have a bunch of NI interfaces of different ages and guess what, each supported from to and up to a different version of labview so if we want to use them all we need multiple installations and multiple OSs as some of the older one require XP to work, other 7.
- Each installation would obviously require a different license
-
@JPortici,
and what do you use instead?
-
It would have been used for automated test. Luckily one of our boards has the appropriate number of input/outputs (and then some) so i decided to write a dedicated firmware and app in one day
-
At my job, I've probably bought well over one million dollars worth of test equipment hardware/software over the years. LabView is the ONLY thing I
ever returned for a full refund. Simply horrible to learn, horrible to use (if and when it works with NI hardware) and very slow. Take a look at the NI
forums - hundreds and hundreds of posts complaining about errors. Yet it does have a cult following - some people swear by it (don't know why!).
I have been somewhat successful using NI's Measurement Studio. I wrote my own application software using Microsoft Visual Studio (.net) calling
the Measurement Studio which calls the specific NI drivers for the hardware.
My preference is Matlab. However, this is pretty expensive once you add a few of their toolboxes, and is probably impractical for most home users.
-
I used VBA (with Access for results databasing) and VBA with GpIB between the instruments and recently added support for some Siglent equipment via network cable.
Of course developing and perfecting your apps while still getting work done takes months, if not years.
Then if you talk to an instrument under test via RS232, and use mscomm32, you find you can not get it to work under windows 10, but everything else does, even VB6!!
Sent from my iPhone using Tapatalk
-
I wonder what the pro and cons may be.
Or do i bark up the wrong tree?
regards
I've used Labview since version 4. We looked at LabWindows back in the 80s I think. This was a DOS based system.
There was a person who ran a website that was titled Labview Sucks. Or Why Labview Sucks. Something like that. It was several pages long with hundreds of complaints. I was not able to find it but there are several smaller similar lists out there. Even a cartoon:
https://www.youtube.com/watch?v=4BppvSzsrNk (https://www.youtube.com/watch?v=4BppvSzsrNk)
I have used very few of NI's hardware. I have their first version of Ethernet GPIB controllers but that's it. Speed wise, its subjective. I can tell you that I used to do a lot of low level code in C and would call the routines from Labview. A couple of years ago, I bought a new PC and at that point stopped using C all together. Everything I do now on the PC is Labview. Maybe the best example I could provide you is a home made motorcycle simulator I came up with. I'm far from an expert with it but there is a pretty decent forum with people who should be able to answer any questions you have about it.
Here you can see me using it with a handheld meter over BLE.
https://youtu.be/e_YzwO62feQ?t=1240 (https://youtu.be/e_YzwO62feQ?t=1240)
Here I am using it to collect data from a spectrum analyzer and then decoding the FSK data from another meter.
https://youtu.be/Mkec-Eyhg7c?list=PLZSS2ajxhiQBcHhIaGpmm9GyZQfrCzqkv&t=356 (https://youtu.be/Mkec-Eyhg7c?list=PLZSS2ajxhiQBcHhIaGpmm9GyZQfrCzqkv&t=356)
-
Yet it does have a cult following - some people swear by it (don't know why!).
bet they all are Uni Lab Teachers/TAs (cough cough)
Then if you talk to an instrument under test via RS232, and use mscomm32, you find you can not get it to work under windows 10, but everything else does, even VB6!!
Actually it's working for us.. No idea why or why you have problems. We communicate with the units with a usb->uart TTL cable and the application (written in vb6) also works on windows 10 with no modifications
-
For private use I found already an obstacle: for the software, in the cheapest configuration, LabView costs a fee of 400€ per year. I would not pay for software subscription (i refused that already for photoshop).
More like $49.95:
https://store.digilentinc.com/labview-home-bundle/ (https://store.digilentinc.com/labview-home-bundle/)
-
In college I used both Labview and VEE (something like Labview but from Keysight) but after a while I dropped Labview and went with VEE because it was much easier. :)
What a shame that Keysight has clearly no interest in VEE :(
We also used PXI systems but most of the modules were from Aeroflex and Adlink. I looked at PXI for my home lab but regular instruments are still a lot cheaper ;)
-
For private use I found already an obstacle: for the software, in the cheapest configuration, LabView costs a fee of 400€ per year. I would not pay for software subscription (i refused that already for photoshop).
More like $49.95:
https://store.digilentinc.com/labview-home-bundle/ (https://store.digilentinc.com/labview-home-bundle/)
Cool!
however, i'll add another reason to hate labview that i just remembered..
The last time i tried to install it (2016-2017) they asked for a lot of personal informations and about 10 minutes later i filled the form, along the email with the download code and license entry i received another spam email and a spam call. I don't remember if it was NI or one of their associates but they had emailed and called me at the same time ask if i wanted support (paid obviously) and i didn't even have started downloading the software yet. It happened twice over the same month, as i tried to download the thing twice and the multi GB download wouldn't come to finish, or would finish corrupted
-
I had to use LabView in school and i never really liked it.
The GUI designer is quite good (Even if it does look a kida ugly) for quickly throwing together a nice functional user interface. But the actual programing using the flow diagram never really worked well for me. Sequencing things in that language is annoying and any big program just turns into a huge tangled mess of spaghetti that makes it hard to even see what is going on.
Most of my test automation ended up being in C# trough the standard VISA DLL. I did some with VBA in Excel too, but that was not that great.
Still i have not found the perfect test automation tool. I want something where i can quickly throw together a test without any significant programing effort. For example hook up a few multimeters and PSU to it, just drag drop the desired values into a graph and have it chart my experiment in real time. Then if i want to do more then i would want some user definable "test cycle" feature where a seqence of actions is fired off each iteration and the result of each iteration is plonked into a chart. Then in the end i could just save the chart in any common format, analyze and measure it with cursors, perhaps even feed that graph into another test cycle sequence to grab some information from it and put it into a new graph etc.
So far i have never found any piece of software that does this in such a quick and easy way. I'm even considering making it myself and open sourcing it.
-
The big disadvantage with any software suite is the work in getting it up and running, and working with all the instruments.
For hobby use, just using the instrument's own GPIB capabilities with a serial to GPIB converter is easy, cheap, and fast enough for basic instrument control and getting readings on to your hard disk.
The downside is that you have to use Excel etc. to make graphs, or use your scope as an XY recorder and only use GPIB for control.
-
This is hardware in the loop motorcycle simulator, currently all written in Labview. The basic idea is I have the real engine controller plugged into the simulator. This allows me to try things without having the actual motorcycle. Originally, I was doing the engine model in C but as I mentioned, the new PC is so fast it's now 100% Labview. The hardware is all custom. Labview communicates with this through the PCI bus.
https://youtu.be/q_89qoFMivg?list=PLZSS2ajxhiQBvWvqMVLdRQMjGofKpQUJr&t=2194
-
In this video, I am measuring a several shunts out various meters I have looked at.
https://youtu.be/ne4Ls2mPF-s?t=2173
-
Has anybody used EEZStudio? They have done great work in other areas with their programmeable power supply.
https://www.envox.hr/eez/studio/create-an-instrument-extension/introduction/11-eez-studio.html (https://www.envox.hr/eez/studio/create-an-instrument-extension/introduction/11-eez-studio.html)
-
Having used Labview for so long now, the main reason I continue to use it is because it saves me time. I can pretty much automate any sort of test I come up with. This includes collecting the data and post processing it. I have been burned by LabView a few times. The most recent, they dropped support for my Ethernet GPIB controllers after I had upgraded. I had to spend time sniffing the traffic and then wrote my own interface for it, in Labview of course. It actually works much better now!
Dave ran a test about a year ago where he life cycle tested the 121GW multimeter rotary switch. If you watch their video, you get an idea about their test setup. Pay attention to the yellow sticky notes as I understand that's how you decode the data. I was never smart enough to translate it.
https://youtu.be/uEfzy3xmReI
I had ran a similar test on a few meters but used Labview to control mine. 24 or so minutes in you can see how I am post processing the data. Setting up this little fixture wasn't days of effort. Maybe I spent a few hours on the main program and after some feedback from viewers, I spent a bit more time changing it. It's not uncommon for me to run a test of the course of weeks using Labview. It's been a very stable platform.
https://youtu.be/bs5n3a__Yq0?t=449
-
We started out using Matlab and LabView in my lab about 5 years ago. And, for the most part is was great for introducing me to SCPI codes and how to automate stepper moters, oscilliscopes, NI-DAQ's, etc.
But then the codes just grew too large to manage.... And I'm sure some NI guy could come to the lab and show us how to better manage it.
I really love my job, and I want to be able to take work home. But that would require having the licenses and the equipment.
So we had an intern from some top university come into our lab. He's an EE guy. We're all physicists. We just get the machines working the best we can with duct tape and WD-40.
He shows us python, but we really don't pay much attention to it. He takes whatever code we had and just made it better. Then I download Anaconda python just to putz around with it a bit. Best thing that's ever happened for our lab.
Saved us alot of money and we vowed to rid ourselves of Labview and Matlab. It's just the best thing ever. Get yourself a copy and just connect to one of your instruments. If you love this stuff. You'll be hooked.
I've been around the PXI chassis. They're nice, but too expensive to justify for our type of research.
Edit:I'm really bad at spelling.
-
Python is awesome for that sort of thing. There's an enormous ecosystem of powerful scientific packages available, to do practically anything imaginable. True, it's probably almost never the fastest performance-wise, but once you get a feel for the Python way of doing things, it's incredibly fast to get code up and running. JetBrains Pycharm Community Edition (it's free) is a great environment working with all things Python as well. Although I'm very much a "vim+shell" guy, PyCharm CE won me over for Python work. It handles all the virtualenv stuff for you, provides an excellent debugger, and overall just shows nice level of polish.
-
Another vote for python. When I was doing my PhD, I would have scripts which could acquire the data from experiments (basically some lasers and mechanical stages interfaced to a bunch of GPIB, serial and LAN devices from many different vendors, as well as some NI DAQ cards over PCIe), post process it and generate the eps files for publication, all in one go. It certainly makes reproducible experiments much easier. I even had one experiment where I was “unit testing” my simulation software (also written in python/C++) by actually doing a real experiment, and checking that the simulation matched the real results.
MATLAB is good for maths, but it sucks as a general programming language, and a lot of non-trivial problems end up needing the features of a general language. Just about the only thing MATLAB has going for it imo is that everyone else historically uses MATLAB (and that is changing, thankfully!)
I also use python and the unittest module to do flashing and production testing of assemblies. Works great, and I can ssh into the test system halfway across the world to check on things or examine an unusual fault.
I also vote for pycharm (although the license cost for the pro version is easily worth it for me).
Edit: also, if you have any problems with performance in python, just write the optimised code in C or C++ and plug it in using Cython. I wrote a GPU accelerated ray tracer which loaded geometry from disk and set up the scene in python, precalculated some stuff in C++ and then pushed it to the GPU to calculate using CUDA C and some PTX assembly.
-
At my Uni lab we have constant arguments about Python vs Matlab. Nobody uses NI LabView.
We make quite decent sized automated setups because we do a lot of performance sweeps vs bias voltages etc. We have discrete standalone equipment, PXI stuff, VXI stuff (parbert for example), MXI stuff. Right now, on of our setups uses 3 PSGs, 1 BERT, 3 scopes, 7 supplies, 2 Spectrum Analyzer, automatic attenuators, and a few switch devices. This is stuff from Rohde&Schwarz, Keysight, Anritsu, Virginia Diodes, Keithley.
The people who use of Python say they prefer it because it is free and easier to use. The supporters of Matlab prefer it because the manufacturers tend to have more examples for it or provide code for us (EG, our 65 GS/s AWGs come with a set of matlab tools to configure it and integrate it more easily into other code) and tend to be able to support us better. I haven't used python much, but what I like about a lot of the stuff is that the software takes care of most of the setup and interfacing.
-
This one is pretty old. Video showing the Labview to control my old VNA. The VNA doesn't perform any calculations. The SOLT is all done in Labview. The graphs in this program are all custom. I don't think they supported Smith charts back when I wrote this.
https://youtu.be/GJd8niwbic8?list=PLZSS2ajxhiQBcHhIaGpmm9GyZQfrCzqkv&t=185
-
Another vote for Python.
It has the following benefits:
1. No license to purchase, maintain, or renew
2. Can do everything from simple text scripts to full-blown web driven GUI
3. Can interface with many other programs
4. Easy to find solutions to programming problems
5. Python skills transferable to other tasks besides instrument control
6. Many more people know Python than Labview
7. Python doesn't crap all over your Windows installations (although VISA still does >:().
Number 1 has proven to be a really big benefit for my company, since we have several sites with common test setups. Purchasing multiple licenses, dealing with license servers, renewals, etc., has not only direct costs, but all the indirect costs as well. We already do this with Altium, and you can sink a surprising amount of time into dealing with them. And, every time you need another license, their salepeople use it as leverage against you. Don't want to repeat that with another company.
John
-
I bought a Labview license for home with version 5.0. I had been using Labview at work for a few years by then and knew that the time it was going to save me would pay off. I don't stay current with the license and won't upgrade unless they have something I feel will be of benefit to me.
I have used Labview to write programs for friends and no they don't need a license. Making an executable is simple. I provide them an installer like any other program. That's worked out really well.
One program I put together is for an engine dyno we built. I made a model dyno that uses a toy electric motor that I used to develop the code on. Sorry but I don't have a good video showing the toy or real dyno in operation. Like the motorcycle HIL, it runs closed loop all in Labview.
I think NI allowed web based control in Labview 5. They had some demos setup onsite that you could log into and run. One was a light bulb and temperature sensor. I think it was basically you could tune the PID and watch how it controlled. They had a camera set up with live feed. Trivial today but I yet have a need for it.
Recently I wanted to measure the battery life of a few handheld meters. Many companies will provide Labview examples for their hardware. In this case, the DAS is custom made.
https://youtu.be/IoCGMRi536Y?t=235
-
There have been major problems with almost every piece of NI hardware I've bought (and it's their high end stuff, not the lower-cost instruments). Their highest end digitizer has aliasing problems and cannot reliably trigger at low sample rates (and a Keysight DSOX3000 that was 1/5 the cost of the NI triggers perfectly on the same signal), the vector signal generator disables output power regulation when modulation is enabled (we were getting errors of up to +/-4dB whenever something as simple as AM was turned on, and if you look closely, the manual actually states that this will happen), their RF switches have mediocre isolation specs. The icing on the cake is that each PXIe card cost more than the equivalent Keysight/R&S/Tek instrument that would have better specs and actually work properly. For simple things their instruments would probably be fine, but in my mind they're not suited for anything beyond the simplest measurements.
LabVIEW is a pretty good tool for quickly throwing together some simple instruments with a passable GUI. For anything more involved, it's just very clunky and buggy. I'm fortunate enough to have an NI certified LabVIEW contractor who develops and maintains our code, but even with his 20 years of experience, we run into stupid bugs and limitations in the language all the time. I'm often tempted to scrap all of our LabVIEW software and rewrite it in MATLAB or Python.
-
There have been major problems with almost every piece of NI hardware I've bought (and it's their high end stuff, not the lower-cost instruments). Their highest end digitizer has aliasing problems and cannot reliably trigger at low sample rates (and a Keysight DSOX3000 that was 1/5 the cost of the NI triggers perfectly on the same signal), the vector signal generator disables output power regulation when modulation is enabled (we were getting errors of up to +/-4dB whenever something as simple as AM was turned on, and if you look closely, the manual actually states that this will happen), their RF switches have mediocre isolation specs. The icing on the cake is that each PXIe card cost more than the equivalent Keysight/R&S/Tek instrument that would have better specs and actually work properly. For simple things their instruments would probably be fine, but in my mind they're not suited for anything beyond the simplest measurements.
LabVIEW is a pretty good tool for quickly throwing together some simple instruments with a passable GUI. For anything more involved, it's just very clunky and buggy. I'm fortunate enough to have an NI certified LabVIEW contractor who develops and maintains our code, but even with his 20 years of experience, we run into stupid bugs and limitations in the language all the time. I'm often tempted to scrap all of our LabVIEW software and rewrite it in MATLAB or Python.
I have some horror stories about attempting to use their hardware as well. Same for working with their "tech" support. I would never attempt to use their hardware again outside of maybe a one off prototype.
It would be interesting to know more details about the clunky, buggy Labview problems and what is a simple setup and passable GUI. I've provided several videos in this thread with examples of how I have used it with success. I am not NI certified and have no formal training in Labview. It's been a learn as I go sort of thing.
It's rare I run into limitations. One I came up with is I wanted to basically have a spreadsheet and wanted to be able to use the mouse to edit their values. Basically this was to edit engine tuning maps. It's something I would have thought would be built into one of the widgets. In this case, coding what I wanted was indeed what I would consider clunky. It was also what I consider slow. The following short video gives you some idea what I was after.
**** Just to be clear, the video is not showing some full on program. The GUI in this case is only to demonstrate the table entry. The plan was to use the table editor as part of an actual program. Also, this was from a few years ago and it is very possible NI came out with a better way to handle tables since then.
https://youtu.be/EgLwrH3zrEw
-
I use the comedi open source drivers (not associated with NI at all) for the DAQ cards on Linux (also with python). I don’t exactly push the features to the max, but I’m yet to have a problem with them. If your hardware is supported, you should give it a try. These are older cards though.
-
I am using both LabView and NI PXI hardware for my day job. If one follows the style guide, their code will not be a mess of spaghetti. It is the same with text based languages, you don't want a 10000 lines monsters, you want small, maintainable files.
Yes, a PXI DMM or scope don't make much sense, but a 32 channel scope in a 4U Chassis makes sense for certain applications.
-
I am using both LabView and NI PXI hardware for my day job. If one follows the style guide, their code will not be a mess of spaghetti. It is the same with text based languages, you don't want a 10000 lines monsters, you want small, maintainable files.
Yes, a PXI DMM or scope don't make much sense, but a 32 channel scope in a 4U Chassis makes sense for certain applications.
True, I am sure we have all seen some pretty messy unmaintainable text based designs. I may have contributed to that! :-DD
For work, we used some of NIs VXI (hardend VME) hardware for a similar reason, lot's of I/O in a fairly compact chassis. A bit of a side note. This thread seems to segregate the various tools. For work, we would use a combination of Matlab, LabView and C on a single project.
-
Hi Joe,
I'm not sure to follow all you do :
- Did you develop yourself these Labview softwares ?
- Are you a Labview developer or/& architect ?
- Is it your job or do you make Labview Softs for a private passion ?
If yes, how much time is required to get a good skills level to develop a full Labview software ?
-
Hello,
- Did you develop yourself these Labview softwares ?
All of the programs I show in this thread, I developed.
- Are you a Labview developer or/& architect ?
I use Labview as a tool, like any other tool. Do I develop programs in Labview, yes.
- Is it your job or do you make Labview Softs for a private passion ?
Everything I show in this thread is for my personal hobbies. It has nothing to do with my job. However, as I mentioned in my previous post, I do use Labview for my job as well.
-If yes, how much time is required to get a good skills level to develop a full Labview software ?
I can't answer that for you or anyone else. We all have different education levels, skills, and ability to learn. I am also not sure how to define good.
On the PC, I started out learning assembler, then mainly used C. I developed code for the PC for several years before using Labview. It took me about a week of going through the manuals before I started using it for actual projects. After several years of using it, I continue to learn better techniques and tricks. I would say I am much more fluent with it now.
-
But the compactRio modules are low priced and would be a good alternative for standardized and repeatable measurements in the private sector (?). The advantage is supposedly the high number of modules and the fast integration into the test environment.
Nevertheless, when i see the many test equipment here on EEVBLOG, which is sometimes very high priced, i wonder why such environments like LabView is not seen more often.
Probably the wrong tree.
First, I wouldn't call compactRIO particularly inexpensive.
Second, NI isn't compactRIO. CompactRIO is just a package. PXI is also good.
Third, NI isn't just Labview. Labview has strengths and it has weaknesses. NI has a lot of other useful software products besides Labview.
I built a startup on scanning light microscopy. We needed several multifunction DAQs (regardless of the number of ADC's, the NI DAQs only have a limited number of control channels), along with a high sample rate reconfigurable I/O module. We used the reconfigurable I/O module to act as a high sample rate digitizer via the on-board FPGA.
NI's Labview provided a good way to perform the FPGA synthesis and build the digitizer quickly. We did not use Labview for anything except the HDL synthesis. We had good C/C++ windows library support and MATLAB interfaces with NI's API's. All stable enough software to build our entire toolchain.
The CompactRIO chassis allowed us to consolidate most of the scanning hardware to a single backplane. Before that, it was a rats nest of wires that only appealed to the disheveled mad scientists.
The NI support is pretty good, as well. They have a big staff of application engineers and the online support is quick. That said, if I was a lone individual trying to get something done on a shoestring budget, I wouldn't consider NI to be a first choice.
Just wanted to add - we moved to PXI chassis for the high resolution / high frame rate imaging...the ADCs were much faster on the PXI's but we didn't have to do hardware rework when moving to PXI from CRIO.
Quite frankly, the alternatives for high-sample rate 14-bit ADC digitizers can be expensive - the NI digitizer solution saved us money. The compactRIO was just a convenient way to package everything in a single chassis. The PXI is really awesome, more capability but larger and more expensive.
-
But the compactRio modules are low priced and would be a good alternative for standardized and repeatable measurements in the private sector (?). The advantage is supposedly the high number of modules and the fast integration into the test environment.
Nevertheless, when i see the many test equipment here on EEVBLOG, which is sometimes very high priced, i wonder why such environments like LabView is not seen more often.
Probably the wrong tree. While I'm very new here, from what I have seen, many of the strongest opinions on this forum are not representative of reality, real companies, or real work. Usually, the strongest opinions seem to be tied to personal ideologies or axes to grind taken to obsessive extremes. Take everything with a grain of salt.
I think you're on the right track, not just here, but life in general. The strongest convictions tend to accompany the least knowledge. I've been using linux for 20 years but I don't hang out in linux user communities because of the large concentration of users who can barely use ubuntu but believe beating others over the head with the fact that they "use linux" (or, have a live cd they booted once) makes them morally superior to some other group of users.
Its best not to get caught up in the zealot approved solution to any problem, but rather the real best tool for the job. The hard part is picking that out from the noise.
-
Hi Joe,
I asked you some questions because I'd like to start a NI project but I'm a bit confused with all possible solution.
I've contacted NI support but they absolutly don't know anything about Cam or Crank sensors topics. Your work exhibits a high level of Labview skills 8)
Maybe could you help me ? ::)
Hello,
- Did you develop yourself these Labview softwares ?
All of the programs I show in this thread, I developed.
- Are you a Labview developer or/& architect ?
I use Labview as a tool, like any other tool. Do I develop programs in Labview, yes.
- Is it your job or do you make Labview Softs for a private passion ?
Everything I show in this thread is for my personal hobbies. It has nothing to do with my job. However, as I mentioned in my previous post, I do use Labview for my job as well.
-If yes, how much time is required to get a good skills level to develop a full Labview software ?
I can't answer that for you or anyone else. We all have different education levels, skills, and ability to learn. I am also not sure how to define good.
On the PC, I started out learning assembler, then mainly used C. I developed code for the PC for several years before using Labview. It took me about a week of going through the manuals before I started using it for actual projects. After several years of using it, I continue to learn better techniques and tricks. I would say I am much more fluent with it now.
-
Hi Joe,
I asked you some questions because I'd like to start a NI project but I'm a bit confused with all possible solution.
I've contacted NI support but they absolutly don't know anything about Cam or Crank sensors topics. Your work exhibits a high level of Labview skills 8)
Maybe could you help me ? ::)
NI support "absolutly don't know anything about Cam or Crank sensors topics" is your opinion based on the few people you spoke with, but it's not a fact. You are not talking to the right people is all. They have a fairly large forum. I suggest you do a little homework before calling them or posting generic questions on their forum. Google "labview HIL engine" and start reading.
You could also consider D-Space. Applied Dynamics may still be around. Depending on your requirements (schedule, budget) D-Space used to offer turn key solutions. If you know exactly what your requirements are, you could get a quote from them.
You could post about your project here as well but it seems there are not many people using the tools. Being an electronic forum, you may not find many people interested in engine controls and such.
*****
https://www.dspace.com/en/inc/home/products/systems/ecutest.cfm (https://www.dspace.com/en/inc/home/products/systems/ecutest.cfm)
https://www.adi.com/ (https://www.adi.com/)
A few NI links from a Google search:
http://www.ni.com/example/31187/en/ (http://www.ni.com/example/31187/en/)
http://www.ni.com/en-us/innovations/white-papers/17/what-is-hardware-in-the-loop-.html (http://www.ni.com/en-us/innovations/white-papers/17/what-is-hardware-in-the-loop-.html)
http://www.ni.com/en-us/innovations/white-papers/18/automotive-hil-testbed-reference-architecture.html (http://www.ni.com/en-us/innovations/white-papers/18/automotive-hil-testbed-reference-architecture.html)
-
Hi Dr Joe,
I'll be more accurate : People from NI France I've spoken with were not aware about what is a cam or crank sensor.
I'm not a NI forum user but I've seen example and white papers you've mentionned. I think so partners developers from NI know exactly how this kind of sensor work.
I've contacted dSPACE and they'll make an offer for my topic :)
Thanks a lot for your info !
-
Hi Dr Joe,
I'll be more accurate : People from NI France I've spoken with were not aware about what is a cam or crank sensor.
I'm not a NI forum user but I've seen example and white papers you've mentionned. I think so partners developers from NI know exactly how this kind of sensor work.
I've contacted dSPACE and they'll make an offer for my topic :)
Thanks a lot for your info !
I would be interested in understanding more about what you were after and how it goes with dSPACE. They were doing some very impressive things 20 years ago. I can only imagine what they have to offer today. If you decide to made a blog about it, please post a link here.
Good luck.
-
Hi Dr Joe,
My topic is a bit complex because acquisition systems have to use timing to synchronize signals together. For my setup, I need to synchro an angular position delivered by an encoder (not sine and cosine signals but pulses) with an analog voltage applied on an input of the acquisition system. The final is to get an Excel sheet with an angle assciated to a voltage value and for example draw a graph with the angles on X axis and voltage on Y axis. It seems maybe easy but not so that due to this synchro system.
Hi Dr Joe,
I'll be more accurate : People from NI France I've spoken with were not aware about what is a cam or crank sensor.
I'm not a NI forum user but I've seen example and white papers you've mentionned. I think so partners developers from NI know exactly how this kind of sensor work.
I've contacted dSPACE and they'll make an offer for my topic :)
Thanks a lot for your info !
I would be interested in understanding more about what you were after and how it goes with dSPACE. They were doing some very impressive things 20 years ago. I can only imagine what they have to offer today. If you decide to made a blog about it, please post a link here.
Good luck.
-
Hi Dr Joe,
My topic is a bit complex because acquisition systems have to use timing to synchronize signals together. For my setup, I need to synchro an angular position delivered by an encoder (not sine and cosine signals but pulses) with an analog voltage applied on an input of the acquisition system. The final is to get an Excel sheet with an angle assciated to a voltage value and for example draw a graph with the angles on X axis and voltage on Y axis. It seems maybe easy but not so that due to this synchro system.
That's pretty common practice really. For experimental work when we needed finer resolution than we could get with the cam and crank sensors, we would mount an encoder to the camshaft. The encoder will provide an index. Then basically do everything in the digital domain. Maybe if you provide a little more detail, I could offer you some suggestions.
-
Another vote for Python.
It has the following benefits:
1. No license to purchase, maintain, or renew
2. Can do everything from simple text scripts to full-blown web driven GUI
3. Can interface with many other programs
4. Easy to find solutions to programming problems
5. Python skills transferable to other tasks besides instrument control
6. Many more people know Python than Labview
7. Python doesn't crap all over your Windows installations (although VISA still does >:().
Number 1 has proven to be a really big benefit for my company, since we have several sites with common test setups. Purchasing multiple licenses, dealing with license servers, renewals, etc., has not only direct costs, but all the indirect costs as well. We already do this with Altium, and you can sink a surprising amount of time into dealing with them. And, every time you need another license, their salepeople use it as leverage against you. Don't want to repeat that with another company.
John
Out of curiosity, how do you create LABVIEW-like GUIs in Python? We would love to ditch LABVIEW at my office but I haven't found a great substitute for creating front panels in Python or C/C++.
If anyone here has any suggestions, I would be greatly appreciate hearing them.
Thanks,
Jason
-
Out of curiosity, how do you create LABVIEW-like GUIs in Python?
MATLAB - GUIDE
Python - Tkinter
it's pretty easy to do procedural UI's with Tkinter...GUIDE isn't as much fun, but it can be done.
-
Out of curiosity, how do you create LABVIEW-like GUIs in Python?
MATLAB - GUIDE
Python - Tkinter
it's pretty easy to do procedural UI's with Tkinter...GUIDE isn't as much fun, but it can be done.
Interesting. I did a search for Tkinter and only found examples similar to what I was doing with Visual C back in the Windows 3.1 days. Can you provide some decent examples?
We would love to ditch LABVIEW at my office but I haven't found a great substitute for creating front panels in Python or C/C++.
It seems the GUI for you is the motivator for Labview. Personally, I like the whole package. The extensive libraries have really saved me a lot of time.
-
The GUI is the only motivator for us. Most everything else is much more cumbersome for us in LABVIEW compared to other languages; however, we don't do too much interfacing with other people's lab equipment through it. If you are interfacing lots of such equipment, I can appreciate that the existing drivers for many pieces of equipment can be a real time saver.
-
Most of the time, I am using it with Ethernet, GPIB or RS232. So talking with the various equipment hasn't been much of a problem. Actually, the worst one I came across was when they dropped support for my Ethernet GPIB controller that they make. It would have been simple to enough to control it if they would have released the documents for it but instead, it took me some some time with Wireshark to sort it out.
The motorcycle simulator is custom hardware, sitting on the PCI bus. I had been doing all the low level interface in C but have since used their driver wizard. Basically the interrupt that runs the the control loop was all in C and now even that is in Labview. It's a lot easier to make changes to the model. If you look at some of my programs, I certainly take advantage of some of their advanced math functions.
Now days it's the only tool I use to develop software for the PC. Even if I just want some simple program to parse a file, it's in labview. It's just faster for me to get things done with it.
That said, a few years ago I looked at their GPU toolkit and didn't see the point of it. In that case, I wrote some code in Labview and C. Even my single threaded C code would run circles around my best attempt as Labview. The CUDA code would runs circles around my best C attempts. Still, it was a rare case where I was really just trying to do tun a benchmark.
I've never looked at their FPGA tools as again, I didn't see the point. The motorcycle simulator is using an Altera and most of what I work on is Xilinx based. I just use their tools and talk to the parts directly. No big deal.
The GUI is nice but for me, that's normally about 1% of the job. I wonder what you are doing that Labview is more cumbersome.
-
...
Nevertheless, when i see the many test equipment here on EEVBLOG, which is sometimes very high priced, i wonder why such environments like LabView is not seen more often.
...
Years ago ,when investigating how to automate my test gear, I decided:
* NI and Agilent s/w software were too expensive for me; spend my money on test h/w, and spend my time writing my own s/w;
* connect all test gear to ethernet; if necessary, use serial-, gpib-, and usb-to-ethernet adapters;
* use SCPI;
* use GNU tools like gawk and octave to run experiments and process the data; the tools run on a variety of setups: Linux, Cygwin, rpi.
I'm happy with the results, so far.
-
Out of curiosity, how do you create LABVIEW-like GUIs in Python?
MATLAB - GUIDE
Python - Tkinter
it's pretty easy to do procedural UI's with Tkinter...GUIDE isn't as much fun, but it can be done.
The person who writes our GUIs uses wxPython, although there are many ways to do it. Labview may be easier for GUIs, but you can definitely do them in Python as well, from very simple to very complex. We went with Python because we felt that the combination of benefits listed was beneficial. Note that a few people in our company do use Labview, but they have a couple people who have done years of work with it. Unfortunately, they have little extra time to help others out.
It just seems to get really expensive very quickly if you have multiple sites, and to do it right, you need a lot of expertise with Labview. With Python, we also found it easy to get support and help.
YMMV, as always...
John
-
Looks like they release the free versions of LabView 2020 and NXG yesterday.
-
Time flies so fast. Bought the home edition of LabVIEW 2014 last year I think. Didn't had the time to play with it yet.
Ho well, I guess I will try to do my LabView rampup on LabView 2020.
-
At that price point (FREE), it might be worth a look. From the download page:
LabVIEW Community Edition
Use the same powerful graphical programming language that engineers and scientists use for your non-commercial personal projects.
The LabVIEW Community edition includes:
Access to LabVIEW 2020 Community edition and LabVIEW NXG Community edition
All of the capabilities found in the LabVIEW Professional editions
The LINX toolkit for use with Raspberry Pi, BeagleBoard, and Arduino
Access to the LabVIEW NXG Web Module for creating web-based applications
-
Location of Community Edition: https://www.ni.com/en-au/shop/labview/select-edition/labview-community-edition.html (https://www.ni.com/en-au/shop/labview/select-edition/labview-community-edition.html)
-
I was a beta tester and while I have downloaded the released version, I have yet to install and try it out. I hope to give it a try over the weekend and see if I run into any problems with it. Keeping my fingers crossed that they have not crippled it in any way and provide the application builder. If it's all there, this is going to be a really nice setup.
-
I was a beta tester and while I have downloaded the released version, I have yet to install and try it out. I hope to give it a try over the weekend and see if I run into any problems with it. Keeping my fingers crossed that they have not crippled it in any way and provide the application builder. If it's all there, this is going to be a really nice setup.
Yes the Application Builder is included.
(https://www.eevblog.com/forum/testgear/advantagesdisadvantages-ni-labview-etc/?action=dlattach;attach=982506;image)
-
That's very good news. What's up with the 365 day license? Is it free or isn't it? If say someone uses this to develop a bunch of applications, what happens at the end of the year? Are they fucked? If so and it's really just an extended trial, IMO, that's even worse. Are they being upfront about it or is it hidden top secrete info like daves $150 meter?
-
That's very good news. What's up with the 365 day license? Is it free or isn't it? If say someone uses this to develop a bunch of applications, what happens at the end of the year? Are they fucked? If so and it's really just an extended trial, IMO, that's even worse. Are they being upfront about it or is it hidden top secrete info like daves $150 meter?
You need to activate the product with your NI account. So I guess you could always renew the license.
-
If they require you to renew after a year, they may force you to change over to NXG, start charging you for it or any other number of possibilities. I was reading what they have published and I am not so sure now what they are offering. It seems like if a person was going to invest the time required to learn a new tool like LabView, they would want to make sure it was going to be around.
Don't get me wrong, I really like the product and it's saved me a lot of time but I own a license and it's not required to phone home or renew. It just works.
If you find out more details, please post them.
-
Like Joe says, learning is an investment in time.
I'm slowly ramping up the license level I pay for with Eagle as I now use it more, getting more efficient and can afford it. But it, like LabView is still only a tool and a small part of what I do.
-
Like Joe says, learning is an investment in time.
I'm slowly ramping up the license level I pay for with Eagle as I now use it more, getting more efficient and can afford it. But it, like LabView is still only a tool and a small part of what I do.
Imagine if you had to subscribe to every little tool in your garage and/or shed... - it just isn't a useful business model unless the product actually is a service, rather than pretending to be a service.
-
That's very good news. What's up with the 365 day license? Is it free or isn't it? If say someone uses this to develop a bunch of applications, what happens at the end of the year? Are they fucked? If so and it's really just an extended trial, IMO, that's even worse. Are they being upfront about it or is it hidden top secrete info like daves $150 meter?
So today I now have 364days left. When you install and then activate the community edition, they give you a year of usage. Look like they are using a license scheme similar to Fusion360 and they left the door open to change the details of the usage contract along the way.
Personally, I wouldn’t worry too much. It's in their best interest to foster and support the hobbyist community. And extending the license after a year is probably going to be possible.
Btw, the Home edition is also phoning home when you install it. The unlocking is done with a serial number and not via your NI account. Still use the same NI license server and etc ...
-
Like Joe says, learning is an investment in time.
I'm slowly ramping up the license level I pay for with Eagle as I now use it more, getting more efficient and can afford it. But it, like LabView is still only a tool and a small part of what I do.
Imagine if you had to subscribe to every little tool in your garage and/or shed... - it just isn't a useful business model unless the product actually is a service, rather than pretending to be a service.
Who's talking about subscription ? you can buy a license for LabVIEW and it's yours. You can use it as much as you want. I still have a licence for LabVIEW Home Edition 2014 and can install it when I want and use it as much as I want.
The Community Edition seam to be a bit different where they don't give you a permanent licence. Usage condition can change along the way but Hey … it's free ;D
-
Anybody can tell me the big difference between LabVIEW and LabVIEW NXG ?
I started with LabVIEW but I'm wondering if I should switch to LabVIEW NXG.
-
Anybody can tell me the big difference between LabVIEW and LabVIEW NXG ?
NXG is a start from scratch version. LabVIEW has gotten extremely bloated and complex, many people like me just gave up on it years ago because we weren't using it full time, and it was impossible to keep up with all of the changes year/year and the nuances. NXG maybe less capable but is much simpler to get started with. Sometimes all I want to do is grab some analog input levels and graph them. I can do this in a couple of minutes with NXG, total no-brainer. With old LabVIEW, if I didn't have appropriate old code, I would mess around for 30 minutes trying to do the same, looking up things along the way, and sometimes it... .just wouldn't work.... oh, forgot to set this or that abstracted variable to the right thing, forgot to make that wire right, forgot to error trap properly.... now it works. OG LabVIEW is aggravating if its the sort of thing you do 3 times a year, IMO.
I think NXG is free to try if you have current service. I love it personally, perfect for "I need to control/measure this now" use.
-
Thanks.
BTW, they also offer a community edition of LabVIEW NXG for free. I guess I will start with NXG since I have 0 experience with the old labview.
-
I looked at NXG and saw they had removed some features I use a lot. Similar to their 64-bit version of LabView. This is why I am still running the older 32-bit version.
I am currently using 2011 for home. I did pick up the 2014 home edition with the watermark which has helped me port code but that's pretty much all I use it for.
I would upgrade more often if I saw any need for it but really my projects are fairly simple so I just stay with what works. That and I have been burned by upgrading. Typically, they will drop support for hardware. At one point they redid all their serial communications which rendered it useless. How you mess up a serial port, when the OS is handling it for you, I have no idea but someone there figured it out. NIs response was buy our USB serial adapters. Changing to 2011 was fine, until I went to Windows 10. This broke the GPIB interface for my controllers. I still have to run a virtualbox for some of my code but I am slowly porting it over to use direct TCP calls. They managed to screw up PCI interface at one point. It took me a long time to hunt this one down. I had it narrowed down to a single DLL or something. Finally their tech support came through. Turned out the had added something and rather than appending it to some table, they stuck it in the middle which broke all the calls below it. Some crazy BS like that.
So yea, I cringe when I have to "upgrade" from something that I at least know what the problems are and how to work around them. That's not just with LabView.
-
Well i'm back to LabVIEW standard. Tried NXG and was not able to connect it to my AWG via GPIB.
-
I love my AD007 Ethernet->GPIB adapter. Since VXI11 is standardized, all you need is a python module, so installation takes, well, let's see:
jjoo:/$ time pip install python-vxi11
Collecting python-vxi11
Using cached https://files.pythonhosted.org/packages/c7/d9/7b9cd149295be9ade54e7d29f5ab09af1a4aefdbdc425c577522f3fc7d18/python-vxi11-0.9.tar.gz
Building wheels for collected packages: python-vxi11
Building wheel for python-vxi11 (setup.py) ... done
Created wheel for python-vxi11: filename=python_vxi11-0.9-cp37-none-any.whl size=18194 sha256=45274cde25f596a450e785c9122878eebc1a1ef1c10769b0fb74b3a1907e8b08
Stored in directory: /home/jon/.cache/pip/wheels/a6/db/4a/d98e940537b436c3d9f1d555f433cf053d9f692b09ea577d8f
Successfully built python-vxi11
Installing collected packages: python-vxi11
Successfully installed python-vxi11-0.9
real 0m3.475s
user 0m3.120s
sys 0m0.222s
3.5 seconds, and I don't even have to make a yearly ritual of digging up every SD card and every pi I've install it on and feeding it a fresh activation code. Jupyterlab, ipywidgets, and holoviews aren't as slick as labview, but they're good enough and they're not *just* free-as-in-beer.
-
Aw heck, it was cached! For posterity I need to retroactively add
jjoo:/tmp$ time curl -O https://files.pythonhosted.org/packages/c7/d9/7b9cd149295be9ade54e7d29f5ab09af1a4aefdbdc425c577522f3fc7d18/python-vxi11-0.9.tar.gz
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 19967 100 19967 0 0 141k 0 --:--:-- --:--:-- --:--:-- 142k
real 0m0.145s
user 0m0.020s
sys 0m0.000s
0.145 seconds to that figure.
-
The GPIB driver is easy to install for me too :)
The LabView instrument driver, not so much. Since old LabView instrument drivers are not compatible with NXG, you can only find drivers for relatively recent instruments. Since I pretty much only have old instruments around and I don't really want to rewrite all those drivers because I'm lazy, I will stick with the old LabView.
-
Are you saying that NXG can't import LabView code? If so, that's a big mistake IMO.
I never understood the whole "driver" name. It's just code like any other VI. GPIB, that's a driver. Example code to talk with my arb over GPIB, not so much.
-
Are you saying that NXG can't import LabView code? If so, that's a big mistake IMO.
I never understood the whole "driver" name. It's just code like any other VI. GPIB, that's a driver. Example code to talk with my arb over GPIB, not so much.
Yep, it need to be converted. They have a tool to do that apparently but it's not completely automatic.
That's really unfortunate. I kind of liked the new C node in NXG. I need to check how hard it is to create a C# node in LabVIEW.
-
That's too bad as I can't see porting my old code and most of it gets reused time and time again for various projects. After all, for the most part I use LabView to collect and post process data. My test equipment doesn't change so it's normally a matter of just putting together some bits of code to get something working. It's proven to be very efficient.
I used to use C and assember with LabView to gain some speed. I gave up my P4 and bought a new PC about 4 years ago. This thing is so fast, I now just use Labview.
-
The subscription model combined with proprietary files makes it a non-starter for me. If you do this for a living, you will get burned eventually. The following can happen, in no particular order of severity:
-You can lose access to the software application, period, and all work you did with it, with no recourse.
-You can lose access to your data because you can't justify continuing to pay a subscription, either to your manager or yourself.
-You can be forced to maintain a separate computer or multiple computers to maintain access to your data, either because the company quit supporting your application, got swallowed by another company, went out of business, etc.
-You can need to pay back maintenance fees for software that you have not used for years, just to gain access to your data or make it usable again.
-You can be pestered by salespeople endlessly.
-The correlation between money spent on proprietary software and its quality is rather weak.
-You can go grey or lose your hair before your time (or maybe that's from the flux fumes...)
All of the above have happened to me at one point or another. If any of these happen to you, you may need to move to new software. This will likely cause pain, cost serious money, etc. Starting many (15?) years ago, I have moved to open source software with open data formats where possible. It can range wildly in quality, but some of it is really good. It has it's own set of problems, but I have yet to permanently lose access to data. This is not a religious thing for me (for example, I use Altium because that's what my employer has, and it mostly works), it is just my defense against the above. Seems to be working fairly well for me.
For instrumentation reading and control, we use Python quite a lot. It does what we need, has an acceptable footprint, and our experience with it has been good. We feel we have saved money and time with it, so the experience has been good. It also has made it much easier to spend money on software that we do buy. Altium's not cheap... If it does not meet your needs, well, then, it doesn't. But, even if you start on this road, and later find out you want to invest in Labview, you will enter that situation with a lot more knowledge about what your needs are. Any Python skills you develop may be useful for other things, though.
By the way, "free" does not imply "open-source". If you are using "free" software and you are violating its license, be aware that updating it is an ideal way to telegraph to someone that you are likely to be using it. This can give the supplier some pretty strong leverage over you if they feel they would benefit from such.
John
-
The GPIB driver is easy to install for me too :)
The LabView instrument driver, not so much. Since old LabView instrument drivers are not compatible with NXG, you can only find drivers for relatively recent instruments. Since I pretty much only have old instruments around and I don't really want to rewrite all those drivers because I'm lazy, I will stick with the old LabView.
Ok, let's install some instrument drivers in python. Packages are separate by subject area, so let's use RF as an example, because that's what I've been hacking on recently.
jon@jcomp:/$ time pip install scikit-rf
Collecting scikit-rf
Downloading https://files.pythonhosted.org/packages/0f/c7/18a46bf8205f0b0b8f3c35e24fe844cd48538af6eb55245c3d947827dcc1/scikit_rf-0.15.2-py3-none-any.whl (2.0MB)
|████████████████████████████████| 2.0MB 920kB/s
Installing collected packages: scikit-rf
Successfully installed scikit-rf-0.15.2
real 0m2.950s
user 0m2.249s
sys 0m0.200s
Not only did it install instrument drivers, including those for my old instruments, in 3 seconds, it also installed some feature emulation code that I wrote years ago and contributed back. I didn't have to dig it up on an old hard drive, or in an old account, and I didn't have to maintain it in the meantime, it was just there, and if you have the same old instrument, it would be just there for you too, even though the commercial world stopped caring about these instruments 20 years ago.
Like JohnG said, licensing headaches go far beyond the money you pay. That's still probably the strongest argument for open source, but being plugged into an ecosystem where you can see code and tweak code and fix the one place where the platform lets you down is also fantastic.
Well, at least so long as the open source infrastructure is close enough to being complete that it really is just one issue and a handful of setup headaches in your way. There are certainly places where open source still isn't competitive, but when it comes to instrument control, it's viable. It's not as slick, but it is viable, and it has some major advantages.
-
... If you do this for a living, you will get burned eventually. ...
If you did this for a living, you would not be using the home edition. Well unless your ethics are in the shitter.
-
Which of JohnG's complaints apply only to the home edition?
-
Which of JohnG's complaints apply only to the home edition?
It's not clear to me yet what NI is offering now with this latest package but we do know from reading the license that is targeted towards people wanting to use the tool for their private use. For the full blown software, I have no subscription. I paid for a license when I decide to upgrade and that's it. If I were using it to make a living, this is what I would be running. They offer a maintenance contract if you need to stay current or require help but personally, I have no use for it.
If I lose the software, that's my ow fault for not keeping backups. I started using it regularly when 4.0 came out and have not ran into any of the problems they mention. That's well over 20 years now.
So far it sounds like there is not going to be any cost for this new package. However, I am concerned if some of what JohnG mentioned would not take effect with these tools. I don't have a crystal ball. If you asked me two years ago if NI was going to offer the tools free for the hobbyist, I would have said no way. But here we are....
If NI's goal is to try and build a new base of customers for LabView, I would not think they would go down this path just to cast it aside down the road. Then again we have seen the MBAs do a lot of things when it comes to running a business. So in this sense, I have to agree with JohnG that there is certainly a risk for the home user. For the businesses using the full blown tools, not so much.
-
I would expect NI to support the new community edition the same ways they supported the home edition for 6 years. They might not update the community edition with the latest release of LabVIEW every years but at least I'm expecting the old version to still work years later. Pretty much like LabVIEW home 2014.
-
I'm not bashing Labview. Where I work, there are people who know it extremely well, and scoffed at our group going with Python for our automated testing and instrument control. Our group, however, had several people who knew Python, and I found it easy enough to pick up (not a piece of cake, but not that hard, either). There is a huge Python community. It did what we needed, did it well, has proven relatively straightforward to maintain and update, and much of the knowledge developed has been transferable to completely different applications.
In my former job, MEs loved Labview. It's all they ever knew. It did what they needed.
For home use, of course you can use their free version. But I can use Python, or other software at home and at work. The advantage for me is that I can get better at a smaller set of tools. This is a big plus for me, because I don't really like programming that much and I don't consider myself very good at it. I just do it to get the job done.
Just to be clear, the list of things I gave is NOT Labview specific. But, all those things have happened to me, and I have become sensitized to them. In my last job, I became quite good at using Saber for simulation. Then it went through a lot of changes, almost went away, and then went from very expensive to super expensive. My company dropped to one license to support one engineer with one application that they could not do without, and anyone else had to transition to something else. I went with Orcad. When it became harder to find a free license, I switched to LTspice. Great for many years, until my current job, where we are moving in a direction that will most likely collide with their licensing terms. The next one I use will be open-source, although I can at least keep most of my Spice models.
I used to love MathCAD. Then PTC bought them. Their salespeople lied to our procurement and sources, all our individual licenses got yanked from underneath us, and then they broke much of the software. It was at this point that I consciously decided to favor open-source solutions whenever I thought it could do a reasonably good job.
This approach has not been without it's own problems. It is not always feasible, it can also lose support or development can cease, etc. But, on the few occasions where that happened, it was relatively easy to move my designs and data to another solution. We have occasionally paid a developer to fix or enhance something, and we have generally been happy. And, when you work for a company, you have hard numbers that you can claim for money saved, and this can be leverage to buy the equipment or commercial software that you need. Finance people love hard numbers...
All that being said, there are jobs where Labview proficiency is a requirement, so a free edition is a great way to learn. And, I firmly believe whatever you do in the privacy of your own home (or lab) is your own business >:D.
Cheers,
John
-
"...I became quite good at using Saber for simulation. "
You don't see that posted very often. It would be funny if we worked together at one time.
-
Writing models in MAST - those were the days...
-
Answering the OP. I think you saved me from a world of pain.
NI is liking dating a hot girl that comes with crazy exes and a love of hermes bags.
We spent something like $30k 12 years ago on a PXI chassis with LabView and TestStand to run an ATE.
Note: the following comments may be out of date.
- Bloated expensive software. Even installing a driver for a $300 NI card meant you had to install every driver for every card NI made with all sorts of nefarious hooks into your OS.
- TestStand was just awful. Slow, inflexible, lots of mouse clocks to do anything.
- LabView beyond anything simple became a spaghetti western, with the casualties being the new guy trying to understand what the old guy did.
- We had a problem with the high density crosspoint front connector which NI weren't interested in solving. I think to this date there is a piece of tape putting torque on the connector to make it work.