The advantage of labview is that for some instruments there are nice virtual instruments (VI), so it becomes very easy to to use the graphical interface of labview to control them. The disadvantage of labview is that if there are large number of loops and instruments interacting with each other. It can be difficult to understand and debug the code. There is also a large community that uses it, so sometime you can sometimes ask questions and get technical solutions back.

Python is a nice language and very versatile, but it is not really designed for instrument control. However, if an instrument is controlled by ASCSII commands like many that have RS232 or GPIB interfaces, I suspect it could be very convenient to do simple things. However to write code and interrupts at a low level with python might be difficult.

I think the choice can depend on the situation. Lab View can be expensive.

It is relatively true that depending on application

and level of complexity one can choose between

a free open source software like Python or an

expensive one like Labview.

Easy thing can be drammatically complicated in

labview with plenty of loop, stacked sequence,

shift register,.... one can save plenty of time with

a simple code of less than 40 lines in python and

interface an instrument and taking a sequence of

data simply.

I remember a simple code of interfacing an old

instrument with labview, consisting of only

taking data from it, was resulting in really a

pletora of things that are far to be simple as

should be.

Also I was surprised by the time labview get

stucked when increase the leavel of complexity

and follow a block diagramm is something so far

to be simple like following a written code.

Last the fact that old version of Labview do not open

new version of it is not handly.

It all depends on an individual's background. People from EE and Controls are used to Labview and people from CS major prefer using DAQ libraries. If someone is "engineering" a software or a framework for some DAQ equipment (depending on the research work) in their lab, libraries are a way to go about. If a solution is required for implementation (with focus on electronics, signal and timing) then you may as well consider Labview. NI provides a .net extension of DAQ libraries, widgets and plugins that integrate with MS VS.net for rapid prototyping and development. To some people the license costs (NI licenses have always come expensive) maybe a deterrent to go for Measurement Studio.net however, there are C#/C++ DAQmx libraries that ship with some DAQ devices and are also freely downloadable.

DAQ cards I have seen and known are all proprietory and so the software libraries that drive them are proprietory as well. It would be difficult to find an open source set of libraries for DAQ cards that are proprietory. You can write open source wrappers around the DAQ libraries and then you would need a license to distribute it as the underlying libraries would still be licensed or lesser licensed. NI daq libraries, as far as I know are not open source.

There is an interesting one: http://www.myopenlab.de

However, it is only in German. But there is some forum in English: http://myopenlab.informe.com/myopenlab-english-df1.html

I have not tried MyOpenLab yet, but I'm also interested in learning more about it.

May by PyDAQmx (http://pythonhosted.org/PyDAQmx/)...

I am trying MyOpenLab now. It is graphical programming but still a little different from LabView. I like it because it can talk to Arduino. 

The lastest versions of MyOpenLab are in english. But the official web site is still in German. 

I just took a look at the examples of MyOpenLab. It seems very useful! Many thanks.

https://forums.codelite.org

and one of programms from HP

We develop crappy (https://github.com/LaboratoireMecaniqueLille/crappy )

which stand for : Command and Real-time Acquisition in Parallelized PYthon

The goal is to allows one to make complex experimental set-ups in python.

It is OpenSource and already interfaced with several DAQ, and motors.

A PID is implemented in order to simplify closed-loop control.

Feel free to test it and give feedbacks.

Regards

https://github.com/LaboratoireMecaniqueLille/crappy

I would recommend the LabJack interfaces. I have used the U6 and now use two t7pro interfaces and do all my coding in python 3.x

I agree with Paul, Labjack has a marvelous support and the hardware is very reliable. Crappy directly interface Labjack Ux and Tx series so it directly allows you to graph, record or command using Labjack.

where is I get the English manual for myopenlab?

Labjack is excellent

My student (Benjamin Montgomery) has submitted a paper to the Journal of Open Source Software about some wonderful code he has written that makes using the LabJack T7 and T7Pro super easy. See https://github.com/university-of-southern-maine-physics/labjack-controller for all the code!

Thanks Paul Andrew Nakroshis , this is indeed very interesting, but I think it doesn't really answer to the question. Labview among other things allows to acquire data graph them and save save quickly.

I am sure that the code provide doesn't answer to this problematic, indeed python is not as easy as Labview for dealing with multitasking, for example graphing and saving data. Im crappy we have developed for several years a platform that allow the user to easily perform task in //. All the multiprocess framework is hidden. In fact when you create a block you create a new process and the links allos you to assure the communication between processes. So you can use camera, Labjack, whatever you like in // as long as your computer allows it.

https://github.com/LaboratoireMecaniqueLille/crappy/blob/py3/Examples/rw_labjack.py

It is very difficult to reach a platform that is usable and even if we are not able to do everything that Labview does, it is easy to set-up a complex set-up with our platform. As you already work in python, I would love to hear from Mr Montgomery about crappy.

There are several branches of crappy the must up to date is the py3 one :

https://github.com/LaboratoireMecaniqueLille/crappy/tree/py3

I prefer with scilab

Didi Istardi don't understand your point, Scilab is nothing alike LabView, there are bridges between LabView and scilab, but you will not create an experimental set-up with scilab. You could use Xcos to performe experiment with arduino (https://www.scilab.org/news/scilab-arduino-low-cost-data-acquisition), but it is far less advanced that what you will be able to make with Crappy !

MyOpenLab seems to be the closest to a LabVIEW alternative that I have found so far. The main issue is that most of the materials out there for the software are in German or Spanish.

https://www.reddit.com/r/engineering/comments/d5nrnx/dear_spanish_folks_your_help_for_translating/

We have started a new initiative here in this Discord server

https://discord.gg/dbD8AR7

to translate things to English and gather the international community in one place. Feel free to join and invite others.

Hi. One bit of info which relates here, I routinely use LabVIEW with Arduinos (http://sine.ni.com/nips/cds/view/p/lang/en/nid/212478), once you have LabVIEW and upload the Linx drivers to the board this is a very flexible low cost alternative to using NI DAQ cards... :) On a separate note, I ended up here while looking for a good place to publish open source hardware design in which all electronics are controlled using LabVIEW. I agree that the software is commercial but nothing prevents one from sharing code and instrument design right? My main problem ironically stems from the solution above, i.e. I use a Arduino but the code is not embedded but rather in LabVIEW, so not really of interest to the Arduino community. I already done a search for free open source hardware etc but nothing stands out so far.. Any suggestions welcome

Francesco, here's a site mixing Labview and open source.

https://sites.google.com/site/integrationfamily/home/projects/ia-labview-platform-for-research-environment/arduino

Thanks for the link Tiberius

Francesco Giustiniano I think you are looking for this https://www.megunolink.com/

Thanks Virgil Tudor, interesting tool but I am not looking for an alternative to what I currently use (LabVIEW+LINX) which does everything I need. What I was asking is: does anyone know of a good (lots of users, many professionals, no advertising/trolling/etc) web platform for sharing (open source) your work with software, electrical and CAD designs, etc, all in the same place? Regardless of in which language the code is written? The one I would be going for is probably GitHub which I think is too software oriented for what I want (I might be wrong). Then there are Arduino project hub and playground, but since my code is not embedded and not written in Arduino language I would prob avoid those. And a bunch of others, none exactly what I am after, but really I was just looking for any suggestions. Or actually I should find a better and more specific place to ask this..

Francesco Giustiniano , could you open an other thread to deal with your issue ?

This thread is titled : "Which is the best alternative to Labview open source" , so telling "(LabVIEW+LINX) which does everything I need" is obviously not very appropriate.

Regards,

Thanks for your feedback Jean-françois Witz . Could you please explain what does the main question of the thread mean anyway? "What is the best open-source alternative to LabVIEW" maybe would make more sense. Since "which is the best alternative to labview open-source" is grammatically wrong I did not feel like I was posting on the wrong thread, just on a ill-defined thread which by virtue of bad grammar can be very open ended (in fact so far I received pretty much just advertising as comments). Anyway noted and I will look for a better place for this enquiry

There's no problem, Francesco Giustiniano !

I think that the grammar of the Thread is not the most judicious, but I think that Alessio Tierno was right to ask his question in spite of everything, because people whose mother tongue is not English should be able to express themselves.

In fact, there are three problems, the first is the cost of hardware, the second is the cost of software, and the third is technological dependence.

Your proposal addresses the first problem, the cost of hardware. A Labview license is more expensive than a Labjack T7 card, which is extremely powerful, for prices ranging from 400 to 600€. It is therefore possible, if you know how to use this hardware with Free Software, to have high performance hardware where you haven't even bought the hardware with National Instrument yet! If, like you, we are already in an environment where Labview is present, then it is logical not to take this constraint into consideration.

But if you're in the context of a self-employed person who wants to sell a measurement solution, then the price of the license will make it uncompetitive.

The last point for me is the most important one, which is why your answer may be considered inadequate.

The Free Software movement doesn't put cost as the main value at all, but control of its production chain.

OpenHardWare is an important point in this control, but in my opinion it comes after Free Software. Not everybody can rebuild an existing product even with the source code, and some years later the components used will not be available anymore and will require a significant reworking of the product and the associated software chain. Moreover, it is very difficult to protect oneself from industrial forces when innovating in HardWare, an open product will be easily cloned in China, reducing the resources to create new products. So we can see that technological dependence is not only on the product but on the whole value production.

There are many of us who want to try to have all of the value production open, but we can only see that it is difficult today.

We have decided to get the best value for money by forcing our suppliers to give us access to all software platforms for our hardware. So for the low-frequency frame grabbers we use Labjack, which interfaces its boards with all the language we use, and for the cameras we use Ximea, which does the same thing.

In terms of ethical values, it's not the best we can do, but we have to have the best hardware, without wasting too much time interfacing for a new product, so it's a concession we accept.

Using open languages also reduces costs. The world of MCUs has changed a lot, and there are many low-cost solutions out there today, but we need to be able to talk to them. So mastering C and Python allows to use easily, raspberry pi, Arduino ESP32 and with initiatives like Blinka and CircuitPython, there are hundreds, even thousands of very powerful and very simple to use sensors today. This world is not National Instrument's target, so most of these products will not be available for LabView unless a LabView user who is proficient in C, and SPI, I2C and other communication protocols, implements them.

The embedded and lab measurement communities were separate until 10 years ago.But today Free Software has progressed so far and has interfaced with so many sensors, that this strong separation doesn't really make sense anymore.

You have to accept to change your habits and learn to program in another language than LabView and the answer to the Thread that you published seems to show that this question is not in your field of reflection, whereas it is for me the heart of this Thread. I can easily understand that your center of gravity in research is not on these technical aspects, but I hope that this answer, will allow you to understand that there is much more in this approach and in these questionings than technique.

Best regards

Thx again Jean-françois Witz .. I am not sure why you got so triggered by what I said earlier ("LabVIEW+LINX does everything I need"). From there you go on implying that I use only LabVIEW, or that I am advertising it.. Probably due to the fact that my question was about the commercial solution while the post focused on the alternative to the commercial solution, my bad, sorry for that, I forget how sensitive the internet can be. The same goes for english grammar, the reason I ended up here in the first instance is that bad grammar confuses google search engines. The post seemed relevant enough to me (in terms of type of community) for my enquiry, and I took a risk, hoping someone might have some advise (finding an open hardware repository not bound to a specific software language, so I could publish my hardware development irrespective of the fact that the code is written in a commercial language such as labview..)

Ok, I understand.

First,

"I am not sure why you got so triggered by what I said earlier ("LabVIEW+LINX does everything I need")."

Looking back at the initial question: "I used for some years Labview for interface instrument, than I moved to an other lab where Linux was used. I used Python to interface instrument."

For me, there's no ambiguity about that sentence.

"I ended up here while looking for a good place to publish open source hardware design in which all electronics are controlled using LabVIEW."

I think that's a clumsy phrase.

Indeed, I think it's great to want to share your HardWare developments, but I think it's awkward to only be interested in the LabView community when you post on a SoftWare question. Especially when the topic is not to use LabView ...

It's not so complicated to decouple the arduino server part from the LabView client, it would leave freedom to users of other software like MATLab,Scilab,Python.

Some projects already exist in this sense by creating shells in BASIC or Python.

LINX is a special case allowing communication only with LabView, and I think it illustrates how titillating this can be.

But despite that, I think it's a very good thing that you came to propose a solution based on OpenHardWare.

On this subject, there is already quite a lot of work, I think that ohwr.org is a site specialized in this subject, but its audience will not be as good as Github.

There are also other sites such as :

https://www.openhardware.io/

which allows to have an interesting showcase, they host the source files, but the software part is often processed separately on github or other. It is possible to directly import the repository from github.

Best regards.

Thanks Jean-françois Witz , I didn't find these two last time I checked. Having the software part on github and hardware elsewhere is also a valid suggestion. In fact my main point is to give access to the hardware design, and to the software structure which could be rewritten in any open source language; and I will prob post the labview code on either github or labview website, so to keep it well separated from the open-source non-commercial material.

Francesco Giustiniano That's great !

I found this link interesting :

https://www.appropedia.org/Open-source_Lab

Feel free to post on the Thread once you publish your OSHW.

I think MyOpenLab is the best FLOSS alternative available https://discord.gg/RcvVUxt

Hi Foad Sojoodi Farimani,

Very interesting MyOpenLab seems to improve and that's great, do you know if it is easy to play with DAQ hardware ?

For what I've seen, you use arduino to stream data, so if you want to add new device you need to implement it in arduino in C++.

There is also the same concept implemented for scilab/Xcos (https://scilab.developpez.com/tutoriels/apprendre-xcos/#LIV-B), what do you think of that ?

How do you use multicore ? It would be a pity to only use one thread so I assume MyOpenLab has its ways to deal with multicore, how do you do ?

Regards

Hi,

This is a quite old question, but remains important and probably more important than in 2012.

Python is now a very viable alternative to LabVIEW. For instance, you can use PyVISA (equivalent to NI VISA) to interface instruments through the GPIB, serial or USB interfaces (using the driver from NI or other card suppliers). You can also easily interface instruments using serial, USB or ethernet natively. And for the graphical part, you can use the excellent matplotlib package. And, for data analysis and scientific calculations, you have scipy and numpy modules based on high performance C and Fortran core routines.

Then using Python today in instrumentation is something really efficient.

There are also some other possibilities, such as using C/C++ for people with such a programming background, associated with some graphical libraries such as Qt, Gtk, wxWidgets, IUP, etc.

But LabVIEW is still a good choice, since it is easier to master that Python and C/C++ and it has a very good hardware support, a full and well written documentation and a professional support for enterprises.

Sidi

Dear Sidi Ould Saad Hamady,

does one need a sort of DAQ hardware when interfacing via Python? Can one basically plug the usb into PC and run it using PyVisa? Unfortunately, there are no resources for the people with less experience.

All the best,

Umut

Dear Umut Parlak

If you are interfacing an instrument with usb interface, you do not need any specific hardware (DAQ or other). For example, it is easy to interface source and measure units, multimeters, oscillo, etc; through usb or GPIB with PyVISA. For GPIB, you need the USB/GPIB adapter or a PCI card and the supplier's driver and that's all. You open the VISA session, send commands and so on... just like in LabVIEW.

Now, if you want to interface NI-DAQmx with Python, it is a little bit more complicated, since you need to call the driver C routines. There is a package on github for that: https://github.com/ni/nidaqmx-python/

Regards,

Sidi

I am currently implementing a python based software that provides several widgets (plots, progress bar, gauges etc like labview) that can be called in few lines of code from your script (~2 lines of code). I use it to show the progress and plots for my experiments with laser fault injection, however it is made to be used by any type of instrumentation lab. You can for instance check the value of a thermometer, plot waveform from the oscilloscope in real time etc. The widgets don't block the execution of your script and you can close the windows without halting the execution of the script, you can pause the experiment, save data etc. I still didn't make it available publicly since I am still documenting it. I would like your opinion if possible. i made a few videos showing some (not all) available widgets. Hope to get your feedback. https://bit.ly/3aebcEC

Dear Umut Parlak,

What Sidi Ould Saad Hamady is true, if you use software that works with the SCPI protocol, the method he proposes will work, it will be a matter of sending instructions in ASCII through a physical link that will be managed by pyVisa.

On the other hand, this is no longer generally true. If you use a USB device, some of them will be interfaced by a serial driver, you will have to choose a baudrate and send bits in the format expected by the device. They can also use the USB protocol directly. In this case, either there is a driver or you have to write one with the LibUSB, in which case the work to be done is important.

As already mentioned in this thread, Labjack DAQ are very cheap and offer very good quality python drivers.

In Crappy, the python driver platform we developed at LaMcube, you can find several cards already implemented, including NI cards with daqmx, labjack, comedi-compatible cards and spectrum cards. You can find the interface files here, if you want to use them directly: https://github.com/LaboratoireMecaniqueLille/crappy/tree/6f2e23bdf398813a32586b55a5bd800608a5de3f/crappy/inout

keep in mind that managing the display, backup and feedback on the experimental set-up oglibatorily requires a multiprocess environment in python because of the GIL, the work to be done is consequent to have a curve that is displayed live with matplotlib and a backup file on a DAQ.

The good news for python developers is that everything is already done in Crappy, don't hesitate to check it out!

Dear Raphael A. C. Viera,

This is very interesting, in Crappy we definitely don't want to create to much GUI as it is difficult to maintain and make the code complicated. There is nothing on the web except your youtube video, so it is difficult to evaluate, in order to see if it could be compatible with our framework.

Do you have a repository on github ?

Dear Francesco Giustiniano

Could you please provide the link where you posted the labview code?

Hello,

I would like to inform you of the publication of a scientific article on our platform of piloting CRAPPY submitted in SoftwareX, which you can consult here :

https://www.sciencedirect.com/science/article/pii/S2352711021001278

This article was the occasion for us to do a very big work on the documentation, which should allow people outside our laboratory to take in hand the software easily.

Regards