INFO: Dieses Forum nutzt Cookies...
Cookies sind für den Betrieb des Forums unverzichtbar. Mit der Nutzung des Forums erklärst Du dich damit einverstanden, dass wir Cookies verwenden.

Es wird in jedem Fall ein Cookie gesetzt um diesen Hinweis nicht mehr zu erhalten. Desweiteren setzen wir Google Adsense und Google Analytics ein.


Antwort schreiben 

LV Versionsumwandlung



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!

18.09.2012, 18:00
Beitrag #1

gottfried Offline
LVF-Guru
*****


Beiträge: 1.735
Registriert seit: Mar 2007

2019
2004
EN

20**
Oesterreich
LV Versionsumwandlung
Hallo,

Ihr habt mir ja sehr geholfen wie man programmatisch eine Liste von VIs in alte Versionen umwandeln kann - OK.

Nun meine naive Frage: Wieso ist das bei LV so ein Problem?

Die VIs sind doch "Sources", wenn ich Sources in einen alten Compiler lade, bekomme ich eben Fehlermeldungen wenn etwas damals nicht unterstützt war - ok, das bekomme ich bei LV ja auch. Aber warum muss ich den ganzen Zauber mit der Versionsumwandlung eigentlich spielen? Das Zeug dem alten "Compiler" in den Rachen werfen und er soll heulen wenn etwas nicht passt....

Offensichtlich ist irgend etwas an meiner überlegung falsch - aber was?

Danke

Gottfried

mein wöchentlicher (eigenwilliger) Beitrag zur Innovation
http://innovation1.wordpress.com/
Webseite des Benutzers besuchen Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
Anzeige
18.09.2012, 20:04 (Dieser Beitrag wurde zuletzt bearbeitet: 18.09.2012 20:07 von GerdW.)
Beitrag #2

GerdW Offline
______________
LVF-Team

Beiträge: 17.399
Registriert seit: May 2009

LV2021
1995
DE_EN

10×××
Deutschland
RE: LV Versionsumwandlung
Hallo Gottfried,

Zitat:Das Zeug dem alten "Compiler" in den Rachen werfen und er soll heulen wenn etwas nicht passt....
Macht er doch: er meckert, dass die Version des VIs ihm nicht bekannt ist...

Zitat:Wieso ist das bei LV so ein Problem?
Problem? Eher "Umständlichkeit"...
Im Ernst:
- NI will neue LV-Versionen verkaufen (oder dauerhafte SSP-Verträge)...
- NI verwendet ein nicht offengelegtes Dateiformat...
- NI erlaubt dir das Zurückkonvertieren, mittlerweile sogar schon für bis zu 7 Versionen (2012->8.0)...
- NI verspricht immer nur Aufwärtskompatibilität (mit Einschränkungen, die auf große Änderungen im Compiler/Dateiformat zurückzuführen sind)...

Auch wenn's dir (und mir, und anderen) nicht gefällt: Es ist eine Mischung dieser Argumente Punkte, die dieses Verhalten bewirken. Welcher Punkt mit welchen Prozentanteilen im Ergebnis wichtiger ist, sei dahingestellt...

Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
19.09.2012, 11:12 (Dieser Beitrag wurde zuletzt bearbeitet: 19.09.2012 11:15 von rolfk.)
Beitrag #3

rolfk Offline
LVF-Guru
*****


Beiträge: 2.302
Registriert seit: Jun 2007

alle seit 6.0
1992
EN

2901GG
Niederlande
RE: LV Versionsumwandlung
(18.09.2012 20:04 )GerdW schrieb:  Hallo Gottfried,

Zitat:Das Zeug dem alten "Compiler" in den Rachen werfen und er soll heulen wenn etwas nicht passt....
Macht er doch: er meckert, dass die Version des VIs ihm nicht bekannt ist...

Zitat:Wieso ist das bei LV so ein Problem?
Problem? Eher "Umständlichkeit"...
Im Ernst:
- NI will neue LV-Versionen verkaufen (oder dauerhafte SSP-Verträge)...
- NI verwendet ein nicht offengelegtes Dateiformat...
- NI erlaubt dir das Zurückkonvertieren, mittlerweile sogar schon für bis zu 7 Versionen (2012->8.0)...
- NI verspricht immer nur Aufwärtskompatibilität (mit Einschränkungen, die auf große Änderungen im Compiler/Dateiformat zurückzuführen sind)...

Auch wenn's dir (und mir, und anderen) nicht gefällt: Es ist eine Mischung dieser Argumente Punkte, die dieses Verhalten bewirken. Welcher Punkt mit welchen Prozentanteilen im Ergebnis wichtiger ist, sei dahingestellt...

Das grundsätzlich proprietäre Format ist ein wesentlicher Grund. Bei einer textbasiereten Programmiersprache ist das Format des Sourcecode die Syntax selber. In LabVIEW ist das binaire Fileformat der Container, die Syntax die verschiedenen Resourcen darin. Und LabVIEW speichert darin sehr viel mehr ab dann alleine die Abfolge von Programminstruktionen, wie das der textbasierte Code normalerweise tut.

Es wäre zwar grundsätzlich nicht unmöglich um eine Formatbeschreibung zu erstellen, die als offizieller Standard dient wie LabVIEW VIs abspeichern soll, diese bei IEC, IEEE oder welchem anderen Standardgremium auch einzureichen und jedesmal wenn LabVIEW ein neues Feature einführt oder ein bestehendes abändert, einen entsprechenden Änderungsvorschlag bei IEC einzureichen. Praktisch wäre das aber sicher nicht. Viele der Dinge die LabVIEW heute intern tut und auch im VI abspeichert waren vor ein paar Jahren noch nicht mal auszudenken. Ein Format zu entwickelen das garantiert immer in beide Richtungen kompatibel ist auch wenn man alle möglichen Dinge daran zufügt ist sehr komplex und verwaltungsintensiv.

Da ist es viel einfacher um ein Containerformat zu haben und nach Bedarf jeweils neue Dinge hinzuzufügen oder abzuändern und eine strikte Versionskontrolle zu implementieren. Und die Konvertierung von einem in ein anderes Format ganz spezifischen Codeteilen zu überlassen, statt das Format versionsunabhängig zu machen. Dass das auch als extra Anreiz dienen kann um Upgrades zu verkaufen ist sicher auch nicht unbedingt unwillkommen, aber es wirkt sich manchmal auch dahingehend aus dass manche Leute gerade deshalb kein Upgrade kaufen und bei einer bestimmten Version bleiben.

Die Hauptursache liegt meines Erachtens echt mehr im technischen Bereich als im Marketing. Sehr viel Zeit ginge in die Erstellung, Pflege und Dokumentation eines solchen Formats, auch wenn die Dokumentation nicht öffentlich gemacht würde. Ein beikommender Effekt ist dass auf diese Weise das Reverseengineering des VI Formats mehr oder weniger ein hoffnungsloses Unterfangen ist, weil im Prinzip mit jeder neuen LabVIEW Version wieder zum Teil überholt.

Rolf Kalbermatter
Technische Universität Delft, Dienst Elektronik und Mechanik
https://blog.kalbermatter.nl
Webseite des Benutzers besuchen Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
30
Antwort schreiben 


Gehe zu: