Current Path seit heute 22.11.2012 fehlerhaft

(29.11.2012 13:18 )GerdW schrieb:  Hallo Hadry,

Zitat:LV 2012 hat aber schon SP3

Falsch. Du hast schon Patch 3 und damit LV2012f3. Im Frühjahr kommt die LV2012SP1 (dann auch mit Win8-Unterstützung)!

Korrekt, mein Fehler (Im Endeffekt ist aber ein notwendiger Patch Zeichen für nicht zu Ende entwickelt. Vielleicht sehe ich das als Embedded Entwickler ein bischen zu streng)

Zitat:

Zitat:Aber es scheint im Allgemeinen überhaupt Niemanden mehr zu interessieren was uns die Software Hersteller alles auf den Rechner schieben.

Doch schon. Aber ich hatte/habe damit weder auf einem betagteren Core2Quad noch auf dem aktuellen i7Quad+HT Probleme
Und auch mein "Unterwegs"-Laptop mit i5 läuft ohne Probleme... Ich installiere übrigens nicht blind alles, was die Lizenz hergibt, sondern nur dass, was ich brauche. Bei mir kommt da mit RT und FPGA auch ein bisschen was zusammen.

Ich gehe mal davon aus, dass du nicht den selben Rechner wie zu LV6/7-Zeiten für die Entwicklung nutzt...

Doch Intel Core2 CPU 6300 @ 1,86GHz

Ich habe es aber gerade mal auf meinem neuen Laptop (Intel Core i5 @2,5GHz) probiert, da ist schon ein Unterschied.
Dann plane ich mal einen neuen Rechner ein.

Danke

Anzeige

Hallo Hardy,

Zitat:(Im Endeffekt ist aber ein notwendiger Patch Zeichen für nicht zu Ende entwickelt. Vielleicht sehe ich das als Embedded Entwickler ein bischen zu streng)

Das siehst du nicht zu streng, wobei: Welche Software wurde jemals fehlerfrei ausgeliefert? Da sind schon Raumsonden über dem Mars abgestürzt und MS hat sogar einen festen Patch-Day eingerichtet!
Es hat schon seine Gründe, warum in meinem Profil nur die x.1 (oder seit LV2009 die SP1)-Versionen aufgeführt sind. Was nicht heißt, dass es für diese nicht auch noch Patches geben würde...

Hallo,

ich bin es nochmal wegen der Pfadangabe.
Ich befördere gerade eine ältere Applikation von LV6.1 nach LV2012.
Die Pfadangabe ist immer noch nicht ganz richtig. Öffne ich das Haupt Vi im Projekt Manager, erzeugt Applikation Pfad den Pfad wo die Projekt Datei steht, beim direkten Öffnen des Vi wird der Pfad des Vi ausgegeben.

Wieso ist es so schwer den Pfad des vi auszugeben. Was interessiert mich der *.proj Pfad.

Also ist immer noch Handarbeit angesagt. Das ist nun schon seit meinem Einstieg mit LV2.5x so, dass aktueller Pfad eben nicht den aktuellen Pfad anzeigt, sondern irgendwas. Diese Funktion ist für

Hallo Hardy,

Zitat:Die Pfadangabe ist immer noch nicht ganz richtig. Öffne ich das Haupt Vi im Projekt Manager, erzeugt Applikation Pfad den Pfad wo die Projekt Datei steht, beim direkten Öffnen des Vi wird der Pfad des Vi ausgegeben.
Wieso ist es so schwer den Pfad des vi auszugeben. Was interessiert mich der *.proj Pfad

Du verwechselt 2 verschiedene Dinge - oder gibst keine ordentliche Aufgabenbeschreibung...
Wenn dich der App-Path nicht interessiert, warum fragst du ihn dann ab?

"Application Path" gibt dir den Pfad zur Anwendung! Seit LV8 gibt es die (sinnvolle, nützliche, andere positive Adjektive) Projektverwaltung. Ein VI, welches in einem Projekt verwendet wird, wird bei Aufruf aus diesem Projekt heraus dieses als "App Path" angeben. (Ich persönlich finde es gut, wenn ich auch in der DeveloperEnvironment den Pfad auf die Hilfsdaten - die ebenfalls im Projektpfad liegen - bekomme!) Wenn dieses VI in einer EXE aufgerufen wird, bekommst du den Pfad zur EXE. Wenn das VI ohne Projektumgebung aufgerufen wird (wer macht sowas schon?), bleibt als sinnvolle Ausgabe nur der Pfad aufs VI übrig...

Wenn du den Pfad des VIs haben willst, musst du "Current VI path" verwenden. Dies gibt dir immer den Pfad auf das VI, mit dem altbekannten und dokumentierten Feature, dass eine EXE als zusätzlicher Pfad-Bestandteil auftaucht. Da hatten wir ja weiter oben schon drüber gesprochen...

Außerdem gibt es auch schon seit einigen LV-Versionen die ConditionalDisableStructure, die sich wunderbar einsetzen lässt, um für Developer- und Runtime-Environment unterschiedlichen Code zu benutzen. Anscheinend ist dies auch ein Feature, welches dir bei diesem Umstieg (von LV6.1 zu LV2012, da liegen doch locker +10 Jahre dazwischen) noch nicht aufgefallen ist.

Hinweis: Wenn du LV2012 verwendest, solltest du dein Profil anpassen...

Hallo Gerd,

also da haben wir doch das Problem.
Ich möchte einfach nur, egal ob während der Erstellung oder nach dem Applikation builder nur den Pfad des Haupt Vi's wissen.
Das geht aber anscheinend nicht. Ich muss wohl programmatisch unterscheiden bin ich(vi) nun in der Entwicklungsumgebung oder bin ich(vi) eine exe. Das kann es doch aber nicht sein? Oder gibt es eine Konstante die genau das macht?

Außerdem bin ich gelegenheits LabView Anwender und kein Informatiker. Daher kenne ich nicht alle Tricks und Gegebenheiten von LabView.
Eine Projektverwaltung sehe ich bei drei vier Applikationen die ich parallel zu meiner Entwicklung als Hilfsmitte erstelle als etwas übertrieben an. Bei vielen sich ständig wechselnden Projekten mag das nützlich sein.


P.S.
hier die Liste der ni software im Taskmanager

niDiscSvc.exe*32 National Intstruments Netweork Discovery Service
nidsmrv.exe *32 nidmsrv
nierserver.exe*32 NI Error Reporting Server
niLxiDiscovery.exe *32 National Instruments LXI Discovery Service
nimdnsResponder.exe *32 National Instruments Zeroconf Service
nimxs.exe*32 NI-PAL Service Manager
nipalsm.exe*32 NI-PAL Service Manager
nipalsm.exe*32 NI-PAL Service Manager
nimxs.exe*32 NI-PAL Service Manager
tagsrv.exe*32 National Instruments Variable Engine
lkads.exe National Instruments Part of Logos
lkcitdl.exe National Instruments Part of Logos
lktsrv.exe National Instruments Part of Logos

Ich kann mit dem Zeug nichts anfangen.

(03.12.2012 14:11 )Hardy43 schrieb:  Ich möchte einfach nur, egal ob während der Erstellung oder nach dem Applikation builder nur den Pfad des Haupt Vi's wissen.
Das geht aber anscheinend nicht. Ich muss wohl programmatisch unterscheiden bin ich(vi) nun in der Entwicklungsumgebung oder bin ich(vi) eine exe.

Das Problem gab es aber schon in LabVIEW 5 (oder sogar noch früher? Da kann ich nicht mehr mitreden.)
Die Standardlösung damals: 2x Strip Path, dann nachschauen, ob der Dateiname auf *.exe endet. Das musst du schon so in LabVIEW 7.1 gemacht haben, da ging das auch nicht anders.

Seit LabVIEW 2009 funktioniert das nicht unbedingt. Den Grund hat dir Gerd erklärt, eine mögliche Lösung in Beitrag #6 beschrieben (Erzwingen der flachen Filestruktur innerhalb der Exe).

(03.12.2012 14:11 )Hardy43 schrieb:  Das kann es doch aber nicht sein? Oder gibt es eine Konstante die genau das macht?

Nein, leider nicht. Aber es gibt inzwischen gute "Programmierhilfsmittel", wie z.B. "Conditional Disable Structure" oder diese schöne PropertyNode:
   
Dahinter noch eine Case-Struktur, und du kannst dir wunderbar den Pfad der Exe oder des VIs ausgeben lassen-

(03.12.2012 14:11 )Hardy43 schrieb:  Außerdem bin ich gelegenheits LabView Anwender und kein Informatiker. Daher kenne ich nicht alle Tricks und Gegebenheiten von LabView.
Eine Projektverwaltung sehe ich bei drei vier Applikationen die ich parallel zu meiner Entwicklung als Hilfsmitte erstelle als etwas übertrieben an. Bei vielen sich ständig wechselnden Projekten mag das nützlich sein.

Auch schon bei einer Applikation lohnt sich Anlegen eines Projekts unter LabVIEW. Alleine die Übersicht über alle verwendeten VIs oder das dass du wunderbar einmal erzeugte Exe-Erzeugungen mit im Projektfile hast, macht die anfangs sicher gewöhnungsbedürftige Umstellung am Ende weg.

Gruß, Jens

Anzeige

Danke Jens,

für die Unterstützung.

Manchmal muss man Leute zu ihrem Glück (hier: Projektverwaltung) zwingen...

Komisch, ich hatte noch nie Probleme mit den Pfaden (oder besser: nach LV3.irgendwas nicht mehr). Man erstellt sich einmal ein subVI zur Pfadgenerierung, welches dann in der user.lib aufbewahrt wird. Dieses überprüft man einmal bei einem Versionsupdate: dies ist übrigens ein Punkt, den man in jeder Programmiersprache hat, wenn es zu Versionswechseln kommt. Dann noch (insbesondere bei Versions-Updates) das Manual lesen: NI liefert immer UpgradeNotes mit, die neue und geänderte Funktionen aufführen! Wenn man nach (gefühlten) 10 Jahren die Entwicklungsumgebung erneuert, kann man nicht voraussetzen, dass immer noch alles wie zu seligen Win95/NT-Zeiten funktioniert! Auch MS hat da vieles verändert - und dafür ein MSDN bereitgestellt...

P.S.: Zu deiner Taskliste:
- ErrorReporting: LV2011/12 möchten Fehlerberichte "nach Hause telefonieren", was nicht grundsätzlich schlecht ist...
- Network Discovery: Ich finde es sehr positiv, dass LV (oder MAX) irgendwelche cRIOs von allein entdeckt, ohne dass ich sie mit der Nase drauf stubsen muss...
- LOGOS ist (AFAIK) der Lizenzmanager, den NI verwendet...
- usw usf. Alles Sachen, die ich gern hinnehme und die mich nicht stören...

Hallo, Hardy,

in einem Punkt stimme ich dir zu:
Die Liste an Diensten, die NI bei einer LabVIEW-Installation inzwischen im Hintergrund installiert, ist in den letzten Version wirklich immer größer geworden. Für jemand, der nahtlos von 7.1 auf 2011/12 geht, muss das wirklich erschreckend sein.

In diesem Zusammenhang, stimme doch hierfür:
http://forums.ni.com/t5/LabVIEW-Idea-Exc...-p/2152018
Immerhin ist auch schon Aristos Queue dafür, scheint also bei NI nicht auf taube Ohren zu stoßen.

Einiges hast du auch übersehen, wie z.B.
ApplicationWebserver.exe
SystemWebserver.exe
...

Gruß, Jens

Hallo Jens und Gerd,

zu meinem Glück brauche ich ganz bestimmt keinen Projektmanager.
Und das mit dem Pfad habe ich ja gemacht. Das ist erst wieder herausgeeitert als MS vor zwei Wochen durch irgendein Update was geändert hat. Gut, dafür kann NI nichts, ändert aber nichts an der Tatsache, dass es eben keine Konstante gibt die genau das macht was sie soll. Ich stehe eben auf dem Standpunkt, dass eine Konstante eben Konstant sein muss und nicht mal so mal so ein Ergebnis bringt.

Grundsätzlich ärgert mich hier und auch im Allgemeinen, dass vieles geändert wird, aber es schlechter wie vorher ist. Das zieht sich jetzt schon seit ein paar Jahren durch alle Bereiche des Lebens. Da ist diese nun nicht mehr gleich funktionierende Pfadangabe ja noch erträglich, da selbst behebbar.

Der Link zum NI Forum ist gut. Ja, das ist genau was ich meinte mit zumüllen.
Die übersehenen weiteren Tasks mag daran liegen, dass ich das auf meinem Notbook unter W7 installierte angeschaut habe. Auf meinem XP Arbeitsplatzrechener, habe ich schon einiges gekillt.

Ich hab mein Problem nun gelöst und werde wohl die nächsten 2-3 Monate nichts mehr mit LV machen. Jetzt stehen wieder andere Aufgaben auf dem Programm, wie Platinen Layouten, Mechanik konstruieren und nebenbei noch ein bischen Assembler programmieren.
So nach dem Motto ich mache(kann) alles, aber nichts richtig.

Ich wünsche Euch ein schönes Weihnachtsfest.

(03.12.2012 18:23 )GerdW schrieb:  - LOGOS ist (AFAIK) der Lizenzmanager, den NI verwendet...

LOGOS ist die Netwerkinfrastruktur die von Lookout übernommen wurde und bei DSC, aber auch bei vielen anderen Komponenten wie der Device Discovery usw. und meines Wissens auch für Shared Variables benützt wird. Datasocket ist davon im Prinzip ein sehr eingeschränktes Subset.

(04.12.2012 11:14 )Hardy43 schrieb:  zu meinem Glück brauche ich ganz bestimmt keinen Projektmanager.

Ich habe mich im Beginn auch gegen die Projektverwaltung gewehrt weil ich sie umständlich fand. Und in 8.0 war sie auch tatsächlich ziemlich holprig. Aber es lohnt sich diese einmal anzusehen und Dinge wie eine Applikation zu builden oder einen Installer zu machen sind ohne viel eigenen extra Programmieraufwand kaum noch zu realisieren ohne die LabVIEW Projektverwaltung. Wenn Du dann noch cRIO, RT und andere distributierte Targets an eine Applikation hinzufügst ist es die einzige sinnvolle Art um bei allem doch die Übersicht zu halten.

Zitat:Und das mit dem Pfad habe ich ja gemacht. Das ist erst wieder herausgeeitert als MS vor zwei Wochen durch irgendein Update was geändert hat. Gut, dafür kann NI nichts, ändert aber nichts an der Tatsache, dass es eben keine Konstante gibt die genau das macht was sie soll. Ich stehe eben auf dem Standpunkt, dass eine Konstante eben Konstant sein muss und nicht mal so mal so ein Ergebnis bringt.

Das was Du da beschreibst kann fast nicht möglich sein. Current VI Path liefert nicht einfach plötzlich einen anderen Pfad weil das MS System ändert. Der Pfad war wahrschienlich schon immer anders aber aus irgendeinem Grund hast Du das nicht eher bemerkt.

Zitat:Grundsätzlich ärgert mich hier und auch im Allgemeinen, dass vieles geändert wird, aber es schlechter wie vorher ist. Das zieht sich jetzt schon seit ein paar Jahren durch alle Bereiche des Lebens. Da ist diese nun nicht mehr gleich funktionierende Pfadangabe ja noch erträglich, da selbst behebbar.

Nun ich bin auch kein Befürworter vieler Änderungen aber Dein Problem scheint auch daher zu kommen dass Du beinahe 10 Jahre LabVIEW Entwicklung mehr oder weniger verpasst hast. Da ändert sehr viel was an sich bei jeder Veränderung alleine keine grosse Sache ist aber alles zusammen ist es dann halt schon ein Riesenunterschied.

Und die frühere Bemerkung dass ein Bugfix release wohl darauf hinweist dass die Software nicht wirklich fertig ist: Wieoft änderst Du Deine Firmware in Deinen Embedded Projecten nachdem es sogenannt schon gelaufen ist, und wie gross schätzt Du die Komplexität Deiner embedded Applikationen ein im Vergleich zu einer LabVIEW Entwickelsoftware wo inzwischen vollzeitlich mehrere 100 Leute dran programmieren und das mit etwas weniger Leuten im Beginn schon seit 25 Jahren?

Zudem es gab zwischen 7.1 und ungefähr 2009 eine Zeit wo NI offiziel keine Bugfixes herausgab, (inoffiziel bekamen grössere Kunden bei spezifischen Problemen schon Bugfixes aber die durften nicht publiek gemacht werden). Der Grund war genau der um Reklamationen wie oben erwähnt zu vermeiden. Ich bevorzuge offenen Zugang zu Bugfixes gegenüber vermeintlicher Qualität nur dem Image zuliebe. Die Forderung Software nur zu releasen wenn sie keine Bugs mehr enthält würde dazu führen dass wir noch immer mit DOS programmieren oder vielleicht gar Relaiscomputer hätten da die noch genügend unkompleziert sind um wirklich zu übersehen ob sie noch Bugs enthalten.

Aber ich bin mir sicher dass Du ein sehr stringentes Qualitätsmanagement hast, wo NI noch davon lernen könnte und dass Du nie etwas released weil es funktioniert sondern nur wenn es garantiert keine Bugs mehr hat . Oder vielleicht doch nicht, denn dann wäre die Rentabilität wahrscheinlich ziemlich schwierig. Perfektionismus ist ein gutes Bestreben aber als Endziel leider eine pure Vision.