Wenn dein Problem oder deine Frage geklärt worden ist, markiere den Beitrag als "Lösung",
indem du auf den "Lösung" Button rechts unter dem entsprechenden Beitrag klickst. Vielen Dank!
Ich habe noch nicht ganz verstanden, was das Abonnement Modell für laufende Applikationen (unter RTE) bedeutet.
Heißt das, dass auch die Run-Time (RTE) von dem Abonnement betroffen ist?
Wenn mein Abonnement nach einem Jahr dann abgelaufen ist und ich es nicht verlängert habe (z.B. im Jahr 2023) weil z.B. die Einkaufsabteilung sich weigert oder so,
hört die Prüfstands-Applikation (die ja auf einer RTE läuft) auf zu laufen? Und erst wenn ich das Abonnement bezahlt habe, erst dann läuft die Applikation wieder?
Zitat:Heißt das, dass auch die Run-Time (RTE) von dem Abonnement betroffen ist?
Wenn mein Abonnement nach einem Jahr dann abgelaufen ist und ich es nicht verlängert habe (z.B. im Jahr 2023) weil z.B. die Einkaufsabteilung sich weigert oder so,
hört die Prüfstands-Applikation (die ja auf einer RTE läuft) auf zu laufen? Und erst wenn ich das Abonnement bezahlt habe, erst dann läuft die Applikation wieder?
Executables mit RTE sind davon nicht betroffen, du kannst also unbesorgt sein!
Du kommst nur nicht mehr an deinen Sourcecode, wenn das Abo nicht verlängert wird…
Das neue Abomodell gilt übrigens für alle seit Jahresanfang abgeschlossenen Verträge (wenn nicht ausdrücklich per intensiver Absprache noch einmal ein Altvertrag geschlossen wurde). Außerdem gibt es die "Deploy and Debug"-Lizenzen, auf die in den von dir verlinkten Threads auch hingewiesen wird.
Heißt das dann wirklich, dass man dann 3020 € jedes Jahr für die LabView Professional Version bezahlen muss, um neue Applikationen entwickeln zu können?
Hier steht es zumindest so: https://www.ni.com/de-de/shop/labview/se...ition.html
Zitat:Heißt das dann wirklich, dass man dann 3020 € jedes Jahr für die LabView Professional Version bezahlen muss, um neue Applikationen entwickeln zu können?
Ja.
Das Schlimme ist, dass du den Betrag nicht nur zahlen musst, um "neu" zu entwickeln, sondern auch, um den alten Code anschauen zu können. Es gibt vermehrt Beiträge im NI-Forum, die davon berichten, dass die Firmen bei LV2021 stehen bleiben, da damit der Code unbegrenzt bearbeitbar bleibt…
Sehe ich genauso, vorallem finde ich das Argument lustig es einfacher zugänglich zu machen mit einem niedrigeren Preis. (Es kostet nun 30% weniger?)
Anders betrachtet gibt es deutlich teurere Software, vorallem im Industriebereich. Da sich LabVIEW jetzt langsam etabliert hat, will man den Preis anziehen. Leider ist die Leistung die NI bringt imho so weit zurückgegangen, das es nicht zu rechtfertigen ist.
MfG Timo
Justieren ist dem Gerät sagen was es anzeigen soll, kalibrieren ist die Kontrolle dieser Anzeige. Eichen ist ein längerer Prüfprozess und darf nur das Eichamt!
(16.08.2022 09:04 )TpunktN schrieb: Sehe ich genauso, vorallem finde ich das Argument lustig es einfacher zugänglich zu machen mit einem niedrigeren Preis. (Es kostet nun 30% weniger?)
Anders betrachtet gibt es deutlich teurere Software, vorallem im Industriebereich. Da sich LabVIEW jetzt langsam etabliert hat, will man den Preis anziehen. Leider ist die Leistung die NI bringt imho so weit zurückgegangen, das es nicht zu rechtfertigen ist.
MfG Timo
Ist das mit dem Etablieren wirklich so? Wenn ich einen Blick auf LabVIEW Stellen werfe, sehe ich da recht wenig Bedarf am linken Niederrhein. Schaue ich auf die LabVIEW Foren ist es dort auch sehr ruhig.
Gefühlt ist es hier ja auch etwas ruhiger geworden oder täusche ich mich da?
Es handelt sich um einen Aktor-basierten Ansatz, welcher dem NI Actor Framework sehr ähnlich ist, und die Ideen des CS++ umsetzt. Die Basisklassen sind in einer Version Null fertig, Branch: feature/pykka. Die Basisklassen für GUI's mit Tkinter sind in Vorbereitung, Branch: TKGui. Prozessvariablen werden als Alternative zu Shared Variablen mit MQTT im Netz publiziert. Es gibt auch einen Beispiel-Aktoren SerDevSim, der mit einer Simulation eines Gerätes auf einem Raspi via RS232 kommuniziert. Diese Klasse dient auch als Template für weitere Device-Klassen.
Als generisches GUI und Ersatz für den Distributed System Manager kann der MQTT Explorer zum Einsatz kommen. InfluxDB erscheint mir als Ersatz für das LabVIEW Data Logging and Supervisory Control Modul geeignet.
Zuvor hatte ich im Branch feature/qt mit einem QT basierten Ansatz probiert.
Pykka ist aber pur Python und Tkinter ist bereits enthalten. Da meine Anwendungen im Wesentlichen IO getrieben sind, erscheint mir das Python threading ausreichend zu sein. Und es wird die Frage zur QT Lizensierung vermieden.
