NI und ich

Hallo zusammen,

der ein oder andere erinnert ich vielleicht noch an mich. Ich bin nochmal kurz "aufgewacht" um zu verkünden, dass nach 20 Jahren die Geschäftsbeziehung zwischen mir und National Instruments, die vor über 20 Jahren damit begonnen hat, dass ich als Mitarbeiter von NI angefangen hatte, nun zu Ende geht.

Grund sind die neuen Lizenzmodelle, in Verbindung mit der Abkündigung des SSP-Programms, das ich nun seit über 15 Jahren gebucht hatte.
Die neuen Lizenzmodelle bedeuten, dass die Lizenzen künftig nur noch für ein Jahr gültig sind, aber fast doppelt so viel kosten.
Das ist pure Abzocke und danke, nein, ohne mich.

Schade, National Instruments, aber wenn ihr eine Zitrone braucht, die ihr auspressen könnt, damit euer Aktienkurs steigt, dann sucht euch einen anderen. Nicht mit mir.

Macht's gut!
cb

Anzeige

Hallo cb,

vielen Dank für die Info. Das bestärkt mich nur mehr meine LabVIEW Fähigkeiten nicht weiter auszubauen und die anderen Programmiersprachen auszubauen.
Mit der Entscheidung bist du ja nicht alleine, wenn man den Foren so glauben darf.

Gruß Max

Hallo cb,

diese Information war mir bisher nicht bekannt.

Was wäre denn als gleichwertige Alternative denkbar?
C# mit WPF? oder was wirst du in der Zukunft benutzen?

Gruß
Marcus

Servus,

ich zahle es zwar nicht, habe meinem Chef aber auch abgeraten das neue Model zu nehmen, uns reicht LV 2021, zumindest solange es noch läuft (Win10).
Anschließend hoffe ich das es noch diese debug Lizenzen gibt, weil das Abo Model ist wirklich nur abzocke und ergibt in keinen anderen Punkten Sinn..

Ich kann deine Entscheidung verstehen, leider bin ich kein Softwareentwickler und damit ist ein Sprachenwechsel für die Anlagen viel zu aufwendig.

Viel Erfolg,
Timo

(22.04.2022 07:34 )Winterkind schrieb:  Hallo cb,

diese Information war mir bisher nicht bekannt.

Was wäre denn als gleichwertige Alternative denkbar?
C# mit WPF? oder was wirst du in der Zukunft benutzen?

Gruß
Marcus

Ich werde mit meinen Kauf-Lizenzen noch so lange weiter arbeiten wie es eben geht, ich schätze mal maximal 2-3 Jahre. Ich hab mir jetzt noch mal das ISO von der Embedded Developer Suite 2021 gezogen und gut gesichert. Von der LabVIEW Runtime Engine hab ich zig Backups, die Software die ich kompiliert für mich selber schreibe läuft dann als Exe so lange das Betriebssystem mitspielt. Parallel dazu werden ich mich auf Eclipse, C/C++ und GTK umschulen. Und es wird dann halt einen Windwos 10 Rechner geben, mit zig Images von der Festplatte, der abgekoppelt vom Netzwerk als "Reparatur"-Rechner in der Ecke steht und den man mal ausmottet, wenn man ihn für die Änderungen an bestehender LabVIEW-Software braucht. Damit kann ich vermutlich die Lebensdauer meiner vorhanden / genutzen LabVIEW-Programme auf rund 10 Jahre rauszögern.

Wenn man mal ehrlich ist, wirklich was neues hat das SSP sowieso nicht mehr gebracht. Die Bugs in LabVIEW, die ich schon vor 10 Jahren gemeldet und angemahnt hatte, sind immer noch drin. Ich arbeite ATM auch noch mit 2018SP1, weil ein Update nicht wirklich viel bringt, außer erst mal Ärger und Anpassungen, aber keinen Benefit für die Entwicklung. NI denkt halt jetzt, dass sie mit einer neuen Oberfläche (NXG) was reissen kann, aber diese Korrekturen sind mMn nach erst mal nur optisch, an der Leistungsfähigkeit der IDE - mal abgesehen von der Integration der neuen Hardware - hat sich ja nicht mehr viel geändert. NI verfällt da genau in die Featuritis, vor der sie selbst in ihren CLA-Kursen seinerzeit (2007) gewarnt haben, und spendiert immer neue - teils sehr halbgare - Funktionen, die eig. kein Mensch mehr braucht - wie z.B. dieses bescheuerte Feature "drag wires outside structures", das ich direkt mal wieder deaktiviert habe, weil es eigentlich nur nervt.

Ich habe den Vorteil, dass ich aus dem klassischen LabVIEW Projekt-Geschäft schon länger raus bin. Ich entwickle jetzt Geräte mit Bedien-Software und ich hab in den letzten Jahren massiv in meine Skils auf STM32 Microcontrollern und C investiert. Da jetzt noch die Chip-Krise auf NI durchschlägt und ich z.B. gar keine cRIOs mehr bekomme, habe ich angefangen meine eigene Mess-Hardware zu entwickeln. Das ist zwar noch lange nicht auf dem Niveau des Portfolios, das NI bei den cRIO Modulen anbieten kann, aber mit jedem Projekt dass ich mache, wird es mehr. Und in 2-3 Jahren habe ich dann alles, was ich sonst von NI gekauft hatte dann auf eigenen Platinen, die ich zu sehr geringen Stück-Kosten jederzeit reproduzieren kann. Und die Funktionalität von kleinen cRIOs bekomme ich mit STM32 Microcontrollern schon ersetzt. Vielleicht bau ich mir sogar mal sowas wie ein cRIO Ecosystem, nur eben auf Basis von STM32. Vieles wofür ich bei NI im cRIO einen FPGA brauche, kann ich ohnehin besser mit Microcontrollern abbilden, bei einer Kostenersparnis von teilweise bis zu 95% beim HW-Einkauf.

Ich setzte auf KiCAD zur Entwicklung der Elektronik, ich setzte auf STM32CubeIDE /(basiert auf Eclipse) für die Entwicklung der Firmware der Microcontroller und für die Bedien-Software werde ich dann zukünftig auf Eclipse + GTK + C/C++ setzen. Das ist alles freie / Open Source Software. Es ist zwar noch mal ein riesen Aufwand, aber dafür bleibt mir halt alles "für immer" und es kommt nicht irgend ein Hersteller und zieht mir die Arbeits-Grundlage unter den Füssen weg oder erpresst mich damit, dass ich auf die Schnelle nicht wechseln kann. Und das schöne an Libraries, die ich mir mit C geschrieben habe, ist: die halten ewig. Ich habe jetzt schon Code, den ich seit 3 Jahren unverändert nutze. Das gleiche gilt für die Hardware: so lang es die Bauteile bei den Distributoren gibt, kann ich die Hardware reproduzieren, wenn ich sie brauche, und - nur um das mal kurz anzureissen - geht schneller als eine Bestellung bei NI, ich lade nur einen ZIP-File und 2 Excel-Tabellen bei JLCPCB hoch und 3 Wochen später kommen meine Platinen.

TL/DR: ich mach mich eben unabhängig von NI. Es war eine tolle Software, es war ein tolles System aus Software + Hardware und ich habe sehr viel mit/durch NI gelernt. Sie haben eine sehr niedrige Einstiegshürde geschaffen und dafür bin ich auch sehr dankbar. Die Geschwindigkeit mit der mir durch NI die Technologie zugängilich gemacht wurde und mit der man Projekte umsetzen konnte, war schon ein sehr großer Vorteil. NI macht jetzt - im Bezug auf mich - den Fehler zu glauben ich wäre abhängig und sie könnten das ausnutzen um den Preis zu verdoppeln und die Leistung massiv zu verschlechtern. Ich bin aber nicht abhängig und ich habe Alternativen.

Das ist so im groben der Plan.
viele Grüße
cb

(22.04.2022 10:57 )cb schrieb:  ich setzte auf STM32CubeIDE

Zitat:Und das schöne an Libraries, die ich mir mit C geschrieben habe, ist: die halten ewig. Ich habe jetzt schon Code, den ich seit 3 Jahren unverändert nutze.

Drei Zauberworte: gekapselt, debugbar, wiederverwendbar ...

(22.04.2022 07:34 )Winterkind schrieb:  Hallo cb,

diese Information war mir bisher nicht bekannt.

Was wäre denn als gleichwertige Alternative denkbar?
C# mit WPF? oder was wirst du in der Zukunft benutzen?

Gruß
Marcus

Python, QT und C für Low-Level- und Performance-kritische Bibliotheken. MQTT für die Kommunikation in verteilten Systemen.

Glűcklich sind diejenigen, die den Mehraufwand für die Entwicklung von modularen Systemen in heterogenen Umgebungen nicht gescheut hatten.

Gruß Holger

(22.04.2022 20:17 )BNT schrieb:  Python, QT und C für Low-Level- und Performance-kritische Bibliotheken. MQTT für die Kommunikation in verteilten Systemen.

Glűcklich sind diejenigen, die den Mehraufwand für die Entwicklung von modularen Systemen in heterogenen Umgebungen nicht gescheut hatten.

Gruß Holger

MQTT nutze ich gar nicht bisher, ich hab - seit 2002 historisch gewachsen - mein eigenes Protokoll, basierend auf UDP (Broadcasts für die Geräte-Erkennung, vielleicht vergleichbar mit Apple Bonjour) und 2 TCP Sockets (Rx und Tx). Und es hat ebenfalls eine Art Broker, den ich Dispatcher nenne. Aber die Architektur ist sehr ähnlich. Und danke für den Hinweis, da muss ich ggf. mal stäker ein Auge drauf haben um meine Hardware ggf. auch für andere zugänglich zu machen.

Heterogene Systeme ist das Stichwort. So baue ich eig. jetzt immer meine Anlagen auf, mit TCP/IP als Kommunikations-Backbone.

In etwas fernerer Zukunft wird noch mal ein großer Umstieg auf Linux als HMI kommen. Grund ist, dass Microsoft angekündigt hat, dass man zukünfitg für Windows 11 zwingend eine Kamera braucht um sich mit Gesichtserkennung am System anzumelden. Damit wird dieses OS als Platform für einen PC mit einer Bedien-Software für ein Gerät quasi unbrauchbar.

(23.04.2022 06:49 )cb schrieb:  Grund ist, dass Microsoft angekündigt hat, dass man zukünfitg für Windows 11 zwingend eine Kamera braucht um sich mit Gesichtserkennung am System anzumelden. Damit wird dieses OS als Platform für einen PC mit einer Bedien-Software für ein Gerät quasi unbrauchbar.

Da muss ich wohl meine alten Unix-Kenntnisse auffrischen. Geräte (meistens solche mit serieller Schnittstelle) steuere ich schon jetzt zunehmend mit Hilfe von Python auf einem Raspberry PI an. Mit Hilfe von MQTT sind sie dann auch gleich im Netz einfach erreichbar. Stichwort IoT.

Gruß Holger

(23.04.2022 09:19 )BNT schrieb:  Da muss ich wohl meine alten Unix-Kenntnisse auffrischen. Geräte (meistens solche mit serieller Schnittstelle) steuere ich schon jetzt zunehmend mit Hilfe von Python auf einem Raspberry PI an. Mit Hilfe von MQTT sind sie dann auch gleich im Netz einfach erreichbar. Stichwort IoT.

Gruß Holger

Daran eine Raspberry Pi als HMI zu verwenden, hab ich noch gar nicht gedacht! Gute Idee, Danke!