National Instruments brengt gratis versie van programmeersoftware LabVIEW uit

National Instruments heeft LabVIEW Community Edition uitgebracht. Dat is een gratis versie van de professionele grafische programmeeromgeving. De gratis variant bevat alle functionaliteit, maar is alleen voor thuisgebruik bedoeld.

LabVIEW is een ide waarmee software geschreven kan worden voor besturingssystemen als Windows, macOS en Linux en ook is de programmeeromgeving te gebruiken om fpga's te programmeren. Tot nu toe was de software alleen tegen betaling te gebruiken, met LabVIEW Community Edition komt daar verandering in.

De gratis versie bevat dezelfde functionaliteit als de professionele versie. Ook krijgen gebruikers toegang tot de LabVIEW NGX Web Module. Ook bevat het pakket een nieuwe LINX-toolkit om gemaakte applicaties te gebruiken met makerboards zoals die van Arduino, Raspberry Pi en BeagleBoards.

Het verschil met de betaalde versies is dat de Community Edition niet voor commerciële projecten mag worden gebruikt. LabVIEW wordt volgens de makers ingezet door tal van grote bedrijven en instanties, waaronder SpaceX en CERN.

Reacties (62)

[Mindfucker]

Labview is een malloch van softwarepakket waarmee je zonder software ervaring vrij eenvoudig een applicatie in elkaar kan knutselen. De hardware van National Instrument is geweldig, ik denk de beste in hun hun vakgebied.

Het grootste probleem: De hardware is afschuwelijk duur, de software is afschuwelijk duur en de support is afschuwelijk duur. €800 voor een visuele skin, CS GO is er niets bij.

Aan iedereen die Labview wilt uitproberen of aan bedrijven die het willen proberen: Geef je developers een Python cursus en je hebt er veel meer aan.

Ik heb me op de NI Summit van 2018 enorm verbaasd over de blijdschap van een eenvoudige nieuwe feature* onder alle grijze blanke mannen in het zaaltje.

*Voor moderne programmeertaal begrippen

[Immutable]

Ja, maar Python is een script taal dat niet hard-realtime dingen kan doen. Ik vind je vergelijking echt TOTAAL krom. Python is HELEMAAL geen vervanging voor Lab-view, en zoals jij het aangeeft doet het mensen wel zo overkomen.

[toolzero]

wij hebben anders op kantoor labview volledig vervangen door python. Alles dat labview kan, kan python ook. Alleen realtime is inderdaad niet altijd even mogelijk met python, maar goed dat kan labview ook niet (althans niet toen ik met labview stopte, laatste versie die ik heb gebruikt was labview 2011).

[Blokker_1999]

Zelfs in 2011 waren er al RT mogelijkheden voor labview hoor.

[_wolf_]

Zelfs in 2011 waren er al RT mogelijkheden voor labview hoor.

Ik werk sinds 2005 met Labview en toen schreef ik naar compact field points. Ik geloof zo uit m'n hoofd dat de field points ergens begin jaren 90 uitkwamen wat al rt was, dus tja.

De kracht van Labview en waar het zich onderscheid van andere programmeertalen is data acquisitie en instrument control. Daarnaast dat het grafisch is wat het enigsinds eenvoudig maakt om te programmeren.

[Adm.Spock]

In 2006 al, heb de hardware voor een testbed geïnstalleerd en in een team samen met de programmeurs de opstelling gevalideerd.

[_wolf_]

Bij Labview Rt zit er al in sinds de jaren 90. Python is een geschikte vervanger. Het is een andere tool met andere nukken.

Dat is het voordeel van een programmeer taal natuurlijk die kan je makkelijk vervangen door iets anders. In principe maakt het ook niet uit wat je gebruikt zolang je, maar je werk goed kan doen met de tool. Ben zelf overgestapt naar Labview in 2005 vanuit C# en C++.

[basseytje]

Kunnen jullie ook FPGA programmeren met python?

[toolzero]

daar zijn geloof ik wel projecten voor, maar heb ik nog nooit gebruikt. Ik heb wel eens de labview fpga tooling gebruikt, maar dat was eens maar nooit meer. Voor FPGA gebruiken we gewoon de daarvoor geschikte tooling, zoals xilinx vivado.

[Kapitein Edward]

Voor 95% wat Labview doet is Python een uitstekende vervanging. Overigens durf ik te beweren dat 95% van de taken die zogenaamd realtime eisen hebben dit helemaal niet nodig hebben. Een goed ingericht platform en idem applicatie zal vaak goed genoeg zijn om een duik in diverse (hard) realtime frameworks als PREEMPT, FreeRTOS, VxWorks, Xenomai etc te voorkomen. Maakt het alleen maar complex.

[Immutable]

Klopt, maar het is wel JUIST de selling point van dat systeem. Ja als je geen hard-realtime nodig hebt, dan kun je prima naar andere oplossingen. Daar ben ik het zeker mee eens. Je hebt gewoon twee pilaren: Performance Computing & Deterministic Computing. Waarbij 1 gewoon mag jitteren, als het eindresultaat maar zo snel mogelijk berekend zal worden, waarbij bij deterministische berekeningen je berekeningen in een bepaalde delta t moeten worden gedaan, anders werkt het gewoon niet in combinatie met de interactie met de echte wereld (Die hoogstwaarschijnlijk ook deterministisch is, iig op een hoger niveau dan Kwantummechanica)

[Reactie gewijzigd door Immutable op 24 juli 2024 14:00]

[epdv]

Je kun prima realtime applicaties schrijven in matlab of andere talen. Kwestie van algorithms streamlinen en IO goed programmeren. Zul je altijd moeten doen als je een realtime systeem wilt maken. Bij LabView doe je dat omdat die je daartoe dwingt. Dat is erg lastig voor 'high level' programmeurs. Bij andere talen moet je er zelf in voorzien.
By the way, realtime op PCs werkt alleen als je de system load laag houd. Geld ook voor LabView.

[Horatius]

Een goede IDE is goud waard, dus als dit de beste optie in het veld is dan is het vaak het geld waard.

[jeroen3]

Het probleem van ni labview is dat hun visa driver defacto standaard is geworden in de test & measurement wereld.
Als dit niet zo was dan was NI al lang klaar.

[epdv]

Je kunt NI hardware met diverse programmeertalen gebruiken als je de Visa drivers installeerd. Ik draai alles al jaren vanuit Matlab scripts maar waarschijnlijk kan dit net zo goed vanuit Python, C++, etc.

[MotorLum]

Top idee. Zo vergroot je de gebruiksersbasis en zodra je er conmerciele dingen mee gaat doen, dan vindt je het ook geen bezwaar om ervoor te betalen.

[Mraedis]

Misschien wel als je de prijs van het pakket ziet...

[mclegodude]

Als genoeg studenten er goed mee leren werken gaat 't bedrijfsleven vanzelf mee

[keraton]

Reken maar dat dit al het geval is. Ik studeer zelf Natuurkunde in Delft en met LabVIEW leren werken is voor veel TU-studenten vaste prik. Dat is op zich ook niet gek, want de software integreert heel goed met de hardware van National Instruments. Tijdens de studie en in veel laboratoria zie je best veel hardware van National Instruments langskomen en je hebt de software ook nodig voor een aantal practica.

Dat gezegd hebbende, dit betekent natuurlijk niet dat LabVIEW populair is. Binnen mijn studie is dit wel het meest gehate stuk software dat we verplicht leren gebruiken, en bij veel andere technische studies ligt dat niet veel anders. In de praktijk is het toch best complex spul, en als je programma eenmaal af is, is de structuur doorgaans ver te zoeken (wat de leesbaarheid van je programma ook niet echt bevordert). Nu ligt dat misschien aan de manier waarop wij LabVIEW aangeleerd krijgen, maar de eerste indruk is toch best belangrijk en die is voor veel studenten niet positief... Het lijkt erop dat die toch liever met Python werken (en in bijvoorbeeld Leiden doen ze dat ook: daar leren de natuurkundestudenten (NI-) hardware aan te sturen en uit te lezen m.b.v. Python).

[Snippo]

Het voornaamste voordeel van LabVIEW lijkt me dat een leek een simpel programma'tje kan schrijven en begrijpen. Echter als het uitgebreider wordt, wordt het zo'n spaghetti dat zelfs en professional er niets meer van kan maken.
Grafisch programmeren klinkt leuk in theorie, maar in de praktijk laat het te wensen over.

[johnkeates]

Het probleem is inderdaad dat het heel aantrekkelijk is voor beperkt gebruik, maar zodra je meer moet heb je er ironisch genoeg eigenlijk niks meer aan: de gebruiker met grotere plannen is dan beter af met een 'echt' en vaak 'open' stuk software en heeft daar vaak meer trek in, en dan is dat hele LabVIEW opeens niet meer iets met toegevoegde waarde.

Dat gebeurt ook op veel andere vlakken, maar vaak is er dan een niche die er wel nut in ziet en zo blijft een product en die eerste funnel waar studenten dan vaak in gestopt worden bestaan. Zie je ook met Oracle, Microsoft en Cisco om maar wat te noemen. Het voelt ook allemaal vrij 90's aan, en dat is ook niet gek gezien we ergens in 1995 ook al verplicht wat met LabVIEW moesten doen en het toen al niet veel beter was dan een veredelde datalogger.

Eigenlijk kan je vanaf een basis studenten beginsel twee kanten op: of je gaat hardcore SCADA/ICS doen, of je gaat de python/c kant op.

[scholtnp]

Ik heb het filmpje even bekeken en herinnerde me andere, mijn inziens, 'GUI denkfout'. Namelijk dat bij elke actie / commando het icoontje groter wordt afgebeeld dan de beschrijvende tekst (die soms niet eens direkt zichtbaar is, pas bij 'hovering over'). Knippen en plakken herkend iedereen wel, maar die andere honderden miniscule symbolen maken het lastig te lezen en schrijven. Alsof je een nieuwe karakterset moet leren.
Kortom, fijn dat de meeste talen minder dan honderd karakters kennen en daarna uitbreiden met sequenties van karakters, die we woorden noemen. Maar ja, ik ben natuurlijk een CLI fan.
(Het woord eye-candy lijkt me bij deze zuurstang kleurige interface wel van toepassing, Tuft's boek wordt finaal genegeerd. Over de auteur zelf, zie de wiki)

[Reactie gewijzigd door scholtnp op 24 juli 2024 14:00]

[Tim_bots]

Het is goed te doen (ex-LabVIEW programmeur hier).
Maar het grote probleem is dat als je van een simpel programma naar een complex programma wil stappen de leercurve ineens gigantisch stijl wordt dat het (voor school) niet meer te doen is.
Als je dan toch een "net" programma wil schrijven adviseer ik om te kijken naar tools als het "Actor framework".
p.s. Als je de grafische interface te restrictief vind ("alleen aanpasbaar" tijdens design time). Je kunt ook .net componenten integreren. Of dat leesbare code oplevert. Alleen op zo'n scherm pricewatch: LG 86BH5C Zwart

[Reactie gewijzigd door Tim_bots op 24 juli 2024 14:00]

[basseytje]

In LabVIEW NXG heeft de UI een flinke overhaul gekregen waardoor er veel meer mogelijk is on-runtime, en het er ook gelijk een stuk gelikter uit ziet.

Daarnaast heb je een valide punt dat complexe programma's snel een rommeltje worden wanneer je nog niet echt programmeer ervaring hebt. En gelukkig zijn er ook tool die een minder stijlen leercurve hebben dan "actor framework", zoals DQMH of OpenGDS.

[_wolf_]

Net als elke andere programma taal is discipline en een programmeer stijl heel belangrijk om een leesbare applicatie te maken. Hierin is het niet beter of slechter dan andere programmeertalen

[Veneficus]

Bij ons in de labs hangt het enorm af van de toepassing. LabView wordt nog veel gebruikt voor meetopstellingen die vrijwel permanent draaien, of veelvuldig hergebruikt worden voor validaties. Dit omdat LabView goed gevalideerd is, en over het algemeen gewoon stabiel. Het is wel een draak van een pakket, en je moet inderdaad oppassen voor bijna letterlijke spaghetti-code.
Voor snelle tests op gevarieerde producten, door collega's die niet willen of kunnen programmeren heb ik SignalExpress in de labs geïnstalleerd (gebaseerd op LabView).
Edit: en zoals hieronder genoemd, real-time measurement&control is nog steeds het domein van LabView.

Voor echt specialistische programma's gebruiken we steeds meer Python. Ook omdat Python veel geschikter is voor het combineren van verschillende taken (data science, image analysis) en veel data analyse gewoon veel simpeler is met Python (hulde aan Pandas).

Maar uiteindelijk is het toch het meest afhankelijk van degene die de opstelling maakt of moet onderhouden. Als er niemand is die het onderhoud over kan nemen wanneer de programmeur er niet (meer) is, dan betaal je dubbel, omdat dan óf iemand de taal moet gaan leren, óf het programma opnieuw gemaakt moet worden. En aangezien Python voor velen makkelijker te leren en breder inzetbaar is dan LabView, zal Python steeds meer de overhand krijgen.

[Reactie gewijzigd door Veneficus op 24 juli 2024 14:00]

[_wolf_]

Labview is idd een tool wat, kennis en ervaring benodigd heeft van data flow programmeren. Jammer dat jullie niet de alliance partner naast de tud gevraagd hebben voor ondersteuning had je er graag mee geholpen

[Horatius]

Dit ja, de halve studie hier zweert bij IntelliJ en zijn (bijna) allemaal gewend om het te gebruiken. Hier in de omgeving zitten veel bedrijven die opgericht zijn door studenten of waar veel studenten gaan werken, velen gebruiken IntelliJ.

[smitae]

En de paar 100 euro per jaar is voor de meeste bedrijven geen probleem om de mensen te laten werken met IntelliJ. Meeste belangrijkste; je developers lekker laten knutselen met de tools waar ze de meeste value mee kunnen leveren.
Heb er de laatste paar jaren een hele rits IntelliJ subscriptions besteld en renewed.

[WillySis]

Ik heb er jaren geleden wel mee gewerkt om allerhande laboratorium instrumenten en experimentele opstellingen mee aan te sturen. Als je ziet hoe gemakkelijk dat gaat en hoe betrouwbaar alles blijft lopen, dan zijn die paar duizend euro's niet zo'n probleem. Het gebouw om de proefopstelling was flink wat duurder.

[Blokker_1999]

De prijs van labview valt nog mee hoor. Soms spendeer je honderd duizenden euro aan materiaal en werkuren om een opstelling mee te bouwen. Dan valt de prijs van de software heel goed mee, temeer omdat je de kost potentieel over meer dan 1 enkel project kunt delen.

[Bender]

LabVIEW, ik heb het op school gehad tijdens het vak programmeren maar wat vond ik het een verschrikkelijk programma.
Ik snapte er eigenlijk weinig van, terwijl het programmeren in C# me vlekkeloos afging..

[Immutable]

Maar heel veel dingen kun je in LabView die je niet kunt in C#. En dat is nou net waar Labview voor wordt gebruikt, en daarom C# niet. C# is totaal niet tijd-kritisch, en relatief performant voor een managed taal, maar ook daar is het zo dat als je performance wil ga je naar systeem talen. En niet C# en Java.

In allerlei testopstellingen die hard-realtime communiceren met de ECHTE wereld, zie je allemaal NI Hardware. Dat zal wel een HELE goede reden hebben, want dat zijn vaak geen domme mensen die iets kiezen vanwege "fanboy" gevoelens.

[Snippo]

Gelukkig bestaat LabWindows ook nog

Daarnaast, NI is gewoon een gevestigd merk wat het complete pakket aanbiedt en er zijn echt wel specifieke alternatieven die in sommige gevallen beter zouden kunnen zijn.

[jbhc]

Mensen zijn gewoontedieren en houden niet van verandering. Dat is waarom er vaak voor bepaalde oplossingen gekozen wordt. Niet omdat het simpelweg de beste oplossing is.

[sfranken]

Even voor mijn beeldvorming, maar wat is bij jou het verschil tussen een "systeemtaal" en C#, bijvoorbeeld? Zover ik weet wordt C# gewoon gecompileerd naar byte-code, net als C en C++ en is het resultaat (mits van dezelfde programmeur) vrijwel gelijk.

[air2]

C++ wordt omgezet in machine code voor de processor.
C# wordt omgezet in bytecode en tijdens het uitvoeren (of al eerder door windows -assembly cache-) omgezet in machine code voor de processor
Maar wat echt het grote verschil is tussen c++ en c# is natuurlijk dat c# net als java een managed memory model gebruikt

[ChillinR]

Je bedoelt waarschijnlijk native machine code i.p.v. bytecode. Bytecode zijn instructies voor de Java Virtual Machine, dus dat is juist geen native code.

Volgens mij kan gecompileerde C# managed code zijn of is het dat altijd, en dan zou het ook niet (direct) native zijn.

Update: ah, bytecode is generieker dan alleen Java. Java bytecode is één type bytecode. Het generiek concept is vergelijkbaar: het is just geen native code. Zie https://en.m.wikipedia.org/wiki/Bytecode

[Reactie gewijzigd door ChillinR op 24 juli 2024 14:00]

[Immutable]

Als je C# wil gebruiken voor tijdkritische software, dan moet je wel een HELE goede deterministische garbage collector hebben die dus wiskundig bewezen niet zijn tijd kan overschrijden. Hoe wil je dat ooit voor elkaar krijgen? Weet je überhaupt wel hoe gevaarlijk garbage collectors zijn voor allerlei systemen waar jij je nooit bewust van bent? Antwoord op je laatste zin is gewoon: Nee, dat is fout. Ik ben dan geen software programmeur en heb geen CS opleiding.(ik programmeer wel...) Maar waarom wordt dit niet onderwezen op school? Tegenwoordig worden bepaalde talen geopperd als oplossing voor ALLES. Terwijl er geen zilveren kogels zijn, en aan managed talen enorme nadelen kleven.

Zelfs C en C++ zijn gevaarlijk wanneer je dynamische geheugen allocatie doet. Je bent beter af met ADA bijvoorbeeld. Als je met C/C++ of Rust deterministische systemen gaat bouwen, moet je vaak gebruik maken van zeer specialistische bibliotheken, en je moet je aan bepaalde beperkingen houden. In C++ kun je dan bijvoorbeeld niet gebruik maken van vector<> container, omdat deze onderliggend dus dynamisch geheugen alloceert. Wat je vaak doet is, alle benodigde geheugen bij initialisatie alloceren en niet meer dynamisch wijzigen.

Er zit een verschil tussen Performance, en tijd-kritisch zijn. En dit soort systemen van National Instruments zitten dus in het tijd-kritische wanneer je je code draait op de hardware en interactie hebt met de wereld, waarbij je geen tijd deviatie mag hebben. Dit is al lastig met C/C++, en eigenlijk praktisch bijna onmogelijk met C#. Waarom zou je jezelf in de haren strijken met talen die daar niet voor bedoelt zijn? C# is gemaakt voor een breed publiek, relatief goede performance en snelle ontwikkeling met gemak voor de programmeur. Voornamelijk kantoor software. En python is helemaal gemaakt voor de ontwikkelaar, en is een geweldige taal. Performance is niet al te best, maar daarom is het niet populair. Het is populair omdat het heel makkelijk op te pakken is, multi-platform, zit geen groot bedrijf achter net als C++ en heeft een gigantische ecosysteem van bibliotheken (Die ook veelal in C en C++ geschreven zijn). De kracht van Python zit hem vooral bij de gebruiker van de taal. Niet de performance, niet het tijdkritische. Waarbij C# zich weer focust op een balans tussen de gebruiker & performance. Net als Java. Je moet de juiste tool kiezen.

[Reactie gewijzigd door Immutable op 24 juli 2024 14:00]

[2004billy]

Super leuk!
Ik heb ooit een metrologiemachine op de uni geautomatiseerd met turbo pascal. Na 15000 regels code had ik het wel gehad met turbo.
Toen voor de volgende machine 3 moderne oplossingen bekeken (het was 1991): keithley viewdac, hp vee, en labview. Viewdac was niet stabiel. Voor vee had je een unix machine nodig. Labview een mac. LV met de icoontjes sprak me enorm aan ( ver voor de mobieltjes). Het programmeren ging bij mij enorm veel sneller. Inmiddels spreek ik labview, en ik stamel matlab, C en python. Atijd LV blijven gebruiken. Ooit een SEMI compliant metrologie machine opgeleverd aan IBM San Jose (semi compliant interface, harel state management, SECS-GEM, ARAMS), volledig aangestuurd met labview. De sofware MTBi was meer dan een maand op windows NT. Dat vond ik toen so so. Nu weet ik dat dat best goed is.
Tegenwoordig gebruik ik labview alleen af en toe voor data-analyse. Mijn bedrijf zweert bij Matlab en Python.
Maar ik kan de jongens wel challengen met een labview analyse. Maar dat is denk ik met iedere taal waar je handig in bent.

[Reactie gewijzigd door 2004billy op 24 juli 2024 14:00]

[Blokker_1999]

MTBi?

[Anoniem: 511810]

mean time between incidents

[Techprice]

Wat leuk! Stilletjes kan ik nu ook hopen op een NI Multisim community edition dan...

Zou echt super gaaf zijn mocht NI een hele reeks applicaties openstellen voor het publiek.

[steveman]

Top tip: Bouw hier niet allerlei planningsoftware mee

hekjeTechDebt

[2004billy]

windows only, trouwens

[cold_as_ijs]

Aah labview, vroeger wilde ideeën gehad om het een en ander in te maken, maar die iedere keer wel stranden om dat ik het toch net niet goed genoeg kende . Het was ideaal voor test opstellingen uit te lezen, vele malen beter dan delphi waar we eerst mee moesten stoeien.

2 vrienden van mij hebben er ooit een videobel applicatie in gemaakt. Ik ga niet zeggen dat het een daverent succes was en heel goed werkte of zo, maar het geeft maar aan dat je best veel kan met labview.
[edit] en nu ik het runescape bericht lees bedenk ik me dat ze ook ooit een bot hadden gemaakt voor runescape om taarten te bakken [edit]

Verder hebben we op het werkt nog een paar data analyse tools die in labview zijn gemaakt. Vervelende is dat eigenlijk niemand anders dan de originele maker de bugs kan fixen, en dat terwijl de rest van het bedrijf in python en matlab werkt.

[Reactie gewijzigd door cold_as_ijs op 24 juli 2024 14:00]

[keverjeroen]

Voor wie het eens uit wil proberen in combinatie met (redelijk) goedkope hardware, koop een Lego Mindstorms setje en download: https://www.ni.com/nl-nl/...-for-lego-mindstorms.html

[P_d_B]

Misschien de stap voor G om meer mainstream te worden. Beter laat dan nooit.
Na 30 jaar LabVIEW denk ik in G en zou ik niet eens meer terug kunnen naar de toetsenbordtijd van voor de uitvinding van Jeff K. Ik had ook nimmer de hoeveelheid technische projecten als eenpitter kunnen uitvoeren denk ik.
De disruptieve, te onconventionele manier van programmeren is tevens zijn manco denk ik, tesamen met het duivelse dilemma van NI in de keuze tussen hardware of software en of ze de Test en Meetniche voor hun R&D klanten echt willen verbreden naar andere markten. Keuzes...