LabVIEWForum.de
Cannot save a bad VI without its block diagram. - Druckversion

+- LabVIEWForum.de (https://www.labviewforum.de)
+-- Forum: LabVIEW (/Forum-LabVIEW)
+--- Forum: LabVIEW Allgemein (/Forum-LabVIEW-Allgemein)
+---- Forum: Application Builder (/Forum-Application-Builder)
+---- Thema: Cannot save a bad VI without its block diagram. (/Thread-Cannot-save-a-bad-VI-without-its-block-diagram)

Seiten: 1 2 3 4


RE: Cannot save a bad VI without its block diagram. - rolfk - 18.07.2012 17:12

(18.07.2012 13:02 )gottfried schrieb:  PPS.: Also beim (gratis) WATCOM C waren 1500 Seite Doku dabei und die Fehlermeldungen waren stringent. Zu MS Programmierprodukten kann ich nichts sagen, ich weiß nur das MS dauernd in den Zeitschriften kritisiert wird.

Ich kenne Watcom noch von der Zeit als er nicht gratis war. Damals konntest Du noch ein ziemlich dickes Bündel an Manuals dazu kaufen. Danach sind sie in der Versenkung verschwunden und inzwischen als Open Source wieder aufgetaucht. Ein guter Compiler, mit vielen Möglichkeiten aber auch Problemen. Die online NI Dokumentation zu LabVIEW ist ein Vielfaches von 1500 Seiten. 1500 Seiten wurden schon bei weitem erreicht als die Manuals noch in einem Schuber auf echter Zellulose gedruckt ausgeliefert wurden. Ich habe hier noch ein komplettes Set im Bücherregal stehen. Ob die Anzahl Seiten jetzt ein Qualitätskriterium ist bezweifle ich etwas, aber so wie Du es schreibst klingt es aber so, und dann wäre LabVIEW eindeutig besser. Big Grin

Ob die Fehlermeldungen wirklich so stringent waren weiss ich nicht mehr, aber ich habe kürzlich auf der Watcom Seite die Sanitorial Projects gelesen und eines davon war auch um die Fehlermeldungen aussagekräftiger zu machen, was angibt dass das bei Watcom eine Proirität hat aber nach eigener Meinung noch immer verbessert werden kann. Cool

Was ich damit sagen will, ist dass Du mit jeder Software irgendwann mal Frustmomente erlebst. Ich habe heute zufälligerweise einen alten eMac wiederzubeleben versucht. Apple ist ja bekannt um seine benützerfreundlichen Betriebssysteme und Applikationen aber ich kriege es nicht hin um ein Systemupdate zu starten da er sagt dass er keine Internetverbindung hat, was erwiesenermassen nicht stimmt, denn ich kann in Safari fröhlich browsen, ausser dass es bei jeder zweiten Seite einfach abstürzt weil es mit modernen Webseiten absolut nicht umgehen kann. Upgraden von Safari geht nicht weil die Update Funktion nicht läuft und Safari die Apple Seiten wo man Updates manual downloaden kann nicht gut darstellen kann. Allerdings gibt es gar keine Fehlermeldungen, nur einfach Pages wo die Buttons um einen Download zu starten schlichtweg nicht nur nicht sichtbar sind, sondern ganz einfach nicht vorhanden. Upgrade nach einem neueren OS X ist ziemlich lästig weil der eMac nur bis 10.5 unterstützt wird aber alte OS X Installer nur mehr über dubiose Kanäle zu erhalten sind.

Und so kannst Du bei jeder Software Deine Frustmomente erleben.


RE: Cannot save a bad VI without its block diagram. - NWOmason - 18.07.2012 20:47

(18.07.2012 13:02 )gottfried schrieb:  PS.: vor einiger Zeit habe ich mit dem Chef (?) von NI-de gesprochen, der war auch der Meinung, dass der AB eine ziemliche Baustelle ist

Rein interessehalber. Mit wem hast du denn über den AB gesprochen?

Beste Grüße,
NWO


RE: Cannot save a bad VI without its block diagram. - gottfried - 20.07.2012 13:47

> Und so kannst Du bei jeder Software Deine Frustmomente erleben.

das stimmt wohl wirklich

Gottfried


RE: Cannot save a bad VI without its block diagram. - gottfried - 26.07.2012 08:20

Was mich nachdenklich macht: der AB ist manchmal nicht deterministisch: Man startet die Erzeugung des EXE (linken) und bekommt eine Fehlermeldung das eine Datei nicht geschrieben werden konnte (ohne für mich verständliche Angabe eines Grundes); starte ich das Ding ohne Veränderung sofort noch einmal geht es (oft) ohne Fehler - was soll man sich da denken?

Auch der Error 1502 ist sonderbar: man müht sich durch Permutation der Linkeigenschaften diese Fehlermeldung zu vermeiden - und es gelingt auch sehr oft (unter Aufopferung von Arbeitszeit und Sicherheit - siehe "Debug erlauben"). Dann arbeitet man weiter an dem Projekt und neulich hat es mich interessiert ... plötzlich kann man wieder ganz normal linken.

Ich finde das nicht wirklich witzig

Gottfried


RE: Cannot save a bad VI without its block diagram. - GerdW - 26.07.2012 08:42

Hallo Gottfried,

Zitat:Was mich nachdenklich macht: der AB ist manchmal nicht deterministisch: Man startet die Erzeugung des EXE (linken) und bekommt eine Fehlermeldung das eine Datei nicht geschrieben werden konnte (ohne für mich verständliche Angabe eines Grundes); starte ich das Ding ohne Veränderung sofort noch einmal geht es (oft) ohne Fehler - was soll man sich da denken?
Ich habe folgende "Erfahrung" gesammelt: der von dir beobachtete "Fehler" taucht eher auf, wenn man ein Explorerfenster offen hat, welches den Build-Ordner anzeigt. Mein Eindruck war, dass sich die aktive Ordner-Überwachung durch den Explorer störend auswirkt. Kann mich natürlich täuschen...


RE: Cannot save a bad VI without its block diagram. - dimitri84 - 26.07.2012 09:25

Auch Virenscanner können ihren Teil beitragen.

Ich hatte mal Comodo auf meinen Entwicklungslaptop installiert - ein, wie ich im Nachhinein festgestellt habe, sehr aggressieves System aus Firewall und Virenechtzeitscanner. Danach hatte mein AB keine Zugriffrechte mehr auf dem lokalen Datenträger und konnte auch keine Applikationen mehr erstellen - erst als ich LV explizit als Admin gestartet habe.

Comodo wurde deinstalliert, das mit den Rechten tritt jetzt nur noch sporadisch auf - das mit dem nicht deterministischen Verhalten kann ich bestätigen.


Gruß


RE: Cannot save a bad VI without its block diagram. - rolfk - 26.07.2012 10:10

(26.07.2012 08:20 )gottfried schrieb:  Was mich nachdenklich macht: der AB ist manchmal nicht deterministisch: Man startet die Erzeugung des EXE (linken) und bekommt eine Fehlermeldung das eine Datei nicht geschrieben werden konnte (ohne für mich verständliche Angabe eines Grundes); starte ich das Ding ohne Veränderung sofort noch einmal geht es (oft) ohne Fehler - was soll man sich da denken?

Einer der möglichen Fehlerursachen hier sind Indexingservices und Virenscanner. Der AB öffnet fast alle seine Files als Write, auch wenn das für das Lesen der source VIs vielleicht nicht unbedingt nötig ist, und das gibt unter Windows Probleme, wenn dasselbe File gerade durch einen Indexservice oder Virenscanner geöffnet ist. Eine saubere Lösung ist leider nicht vorhanden, ausser den Virenscanner so zu konfigurieren dass er diese Files ausdrücklich nicht mitnimmt aber das artet schnell in einen Konfigurationsalptraum aus.

Und das Builddirectory im Explorer offen halten ist tatsächlich bei mir eine 100% Garantie, dass der AB den Build kurz vor dem Ende abbricht. Etwas lästig aber auch nicht mehr.


RE: Cannot save a bad VI without its block diagram. - jg - 26.07.2012 17:15

(26.07.2012 08:42 )GerdW schrieb:  Ich habe folgende "Erfahrung" gesammelt: der von dir beobachtete "Fehler" taucht eher auf, wenn man ein Explorerfenster offen hat, welches den Build-Ordner anzeigt. Mein Eindruck war, dass sich die aktive Ordner-Überwachung durch den Explorer störend auswirkt. Kann mich natürlich täuschen...
Das Phänomen kann ich bestätigen!!

Gruß, Jens


RE: Cannot save a bad VI without its block diagram. - gottfried - 29.07.2012 09:20

Da habe ich wieder viel gelernt.

Ich danke Euch

Gottfried


RE: Cannot save a bad VI without its block diagram. - gottfried - 18.09.2012 15:18

Sorry, da ist er schon wieder der 1502er. Jetzt habe ich das vom AB beschuldigte VI als EXE (testweise) erzeugt - ganz ohne jedes Problem.

Offensichtlich reicht das Probieren nicht für immer, wenn man etwas ändert geht das von Anfang an wieder los.

Ach du liebes Bischen...

Gottfried

PS.: [ERROR]
Code:1502
An error occurred while saving the following file:

C:\Programme\National Instruments\LabVIEW 2011\user.lib\visiongfr\Sharpness.vi


<Call Chain>Error 1502 occurred at AB_Source_VI.lvclass:Close_Reference.vi -> AB_Build.lvclass:Save.vi -> AB_Build.lvclass:Copy_Files.vi -> AB_Application.lvclass:Copy_Files.vi -> AB_EXE.lvclass:Copy_Files.vi -> AB_Build.lvclass:Build.vi -> AB_Application.lvclass:Build.vi -> AB_EXE.lvclass:Build.vi -> AB_Build.lvclass:Build_from_Wizard.vi -> AB_UI_Frmwk_Build.lvclass:Build.vi -> AB_UI_FRAMEWORK.vi -> AB_Item_OnDoProperties.vi -> AB_Item_OnDoProperties.vi.ProxyCaller