Fehlermeldung beim umwandeln einer llb

Servus zusammen.

Mein Projekt ist komplett in einer llb Datei, so habe ich immer alles beisammen. Auch beim Kopieren ist alles an einer Stelle.
Im Zuge einer Umstellung in der Firma wird jetzt "TortoiseSVN" zum Versionsmanagment verwendet. Hierfür finde ich es aber praktisch keine llb, sondern einzelne Dateien zu haben. Um einzelne Versionen von den Sub-Vis wiederherstellen zu können.
Nach langem suchen habe ich auch eine Option im llb-Manager gefunden, die Datei wieder in einen Ordner umzuwandeln. Nur leider kommt die eingefügte Fehlermeldung und es werden von den 36 Objekten (vi's und ctl's) aus der llb nur 14 davon im Ordner ausgegeben (vi's und ctl's). Kennt das Problem jemand oder weiß woran das liegt?

mfg Timo

Hat keiner eine Idee? Ich verwende keine Sonderzeichen im Namen.

Wie kann ich die Vi's sonst vereinzeln?

Hallo TPunktN,

- Bei "nur" 36 Dateien kannst du dir auch die Mühe machen, diese "von Hand" an ihren neuen Ort zu kopieren.
- Es wäre schön gewesen, wenn du in der Zwischenzeit nachgeschaut hättest, welche Dateien Probleme beim Kopieren machen (mit welchen Namen etc.)
- Idee: Die Fehlermeldung schreibt irgendwas von einer "llx"-Datei. Was soll das denn sein?
- Idee: HauptVI laden und Hierarchie an neuen Ort speichern lassen ("Speichern unter"). Ich weiß aber nicht, ob da nicht auch wieder eine LLB generiert wird.
- Tipp: Arbeite nicht mit LLBs. Diese sind nicht dafür gedacht, in der Entwicklungsumgebung als "Container für alles" zu dienen! Außerdem gab es immer mal wieder Fehlermeldungen, wo ein falsches Bit in der LLB-Datei alle enthaltenen VIs unbrauchbar machte...

Vielen Dank für die Antwort.

In den Namen gibt es keinerlei Auffälligkeiten. Es wird wohl auf die Handarbeit hinauslaufen. Danke für den Tipp, ich werde in Zukunft keine llb mehr dafür verwenden, sind die dann überhaupt noch für irgendwas geeignet (Aufgrund dieses Fehlers)?

Eine llx ist eine Sicherungsdatei beim umwandeln einer llb (über den LLB-Manager).
Beim "Hierarchie speichern unter.." kommt leider auch wieder eine llb bei raus.

Ich mach mich dann mal an die Handarbeit ..

Hallo T.N,

mir fällt kein (echter) Punkt für die Notwendigkeit von LLBs ein. Man könnte sie nutzen, um Code an andere weiterzugeben, aber dafür kann man (heutzutage) auch eine SourceDistribution im AppBuilder erstellen...

Mal schauen, hier sind einige Pro und Contra Punkte zu LLB:
http://labviewwiki.org/LLB

Der wichtigste Punkt "früher" war sicher das Durchbrechen der Dateinamen-Grenze unter DOS. Schließlich kommt LabVIEW aus der MAC-Welt.

Aus heutiger Sicht hat sich Format unter neueren LabVIEW-Versionen überlebt.

Gruß, Jens

Anzeige

Das ist dan wohl ein Überbleibsel aus verdammt alten Versionen

Danke für die Info, ich habe noch nicht mit Projekten gearbeitet, werde mich da mal einlesen.

mfg

Oje, wie peinlich...

Sollte dieses Problem noch jemand haben, die Lösung:

Sicherheitshalber die llb kopieren!

Im LLB-Manager alle VI's und ctl's aussschneiden, ein Ordner nach oben und einfügen.
Nach dem öffnen findet LabView den neuen Pfad sofort.

danke
Timo

Hallo T.N,

und worin liegt die Peinlichkeit?

Das beschriebene Verfahren ist doch die Standard-Vorgehensweise beim LLB-Manager!? Warum hat es im ersten Post noch nicht funktioniert?

(06.12.2012 10:10 )GerdW schrieb:  Hallo T.N,

und worin liegt die Peinlichkeit?

Das beschriebene Verfahren ist doch die Standard-Vorgehensweise beim LLB-Manager!? Warum hat es im ersten Post noch nicht funktioniert?

Gesehen die Länge des Pfades in der Fehlermeldung würde ich mal auf eine Pfadlängenbeschränkung von Windows APIs tippen. Windows hatte traditionel eine Beschränkung auf 260 Character für einen Pfad. LabVIEW selber kennt diese Beschränkung nicht, da das verwendete Format für Pfade nicht einfach ein String ist sondern eine private Datenstruktur die maximal 255 Character per Pfadebene haben kann, aber beinahe beliebig tiefe Verschachtelung der Ebenen (nun der Speicher wird wahrscheinlich vorher knapp!). Aber LabVIEW macht die eigentlichen Fileoperationen nicht selber sondern ruft dazu Windows API Funktionen auf. An sich sollten die neusten LabVIEW Versionen von API Funktionen Gebrauch machen die diese Einschränkung auf 260 Character nicht mehr haben (ist glaub ich nun 65630 oder so Character was wahrscheinlich wieder ein paar Jährchen genügen sollte) aber es ist sehr wohl möglich dass in der LLB Behandlung noch immer einige dieser älteren API Funktionen verwendet werden die halt nur 260 Character handhaben können, da LLBs aus praktischer Sicht tatsächlich schon ziemlich lange ein überholter Zopf sind, aber aus Kompatibiliteitsgründen auch nicht einfach abgeschnitten werden können.

Der schnellste Fix wäre dann halt einfach die ganze LLB in einen weniger tief verschachtelten Ordner zu legen und von dort aus zu entpacken, eventuel auch das Ziel ebenfalls einige Ebenen weniger tief zu wählen.