' schrieb:
Super, nun können wir "richtig" Pingen in LabVIEW.
Also mit einer Einschränkung! Das geht nur wenn der entsprechende Prozess Administratorprivileges hat (oder man die in der ICMP Funktion beschriebenen Registrysettings einstellt, was ich aber ehrlich gesagt noch nicht getestet habe).
Zitat:Was ich sehr interessant finde, sind die eigenen Property's.
Irgendwie steht das in den rc und rch File.
Wie macht man das, bzw. wie sind verkettet ?
Hast du da irgenwelche Links/Dokus?
Sorry das ist alles mit viel trial and error zusammengehackt und ist deutlich kein Feature das NI für Enduser gedacht hat. Vieles da drin funktioniert manchmal nur in bestimmten Kombinationen, obwohl das scheinbar nicht direkt sinnvoll ist. Auch muss man aufpassen da gewisse logische Dinge in 7.1 und 8.0 nicht oder nur scheinbar funktionieren und irgendwann in 8.x plötzlich schon. LabVIEW 8.6 und 2009 unterstützt auch noch ein RCVersion: 4 Format aber ich habe keine Idee was da die Neuerungen sind.
Ich werde mich mal hinsetzen und versuchen das bischen was ich weiss sauber zu dokumentieren, da ich im Moment allerlei schwer lesbare kleine Dokumente habe mit alles ausser sauberer Syntaxbeschreibung. Aber mit dem RC Format alleine ist es noch nicht getan. Die Userdata Refnums (die es auch noch in Tag Form (schaut aus wie ein VISA Refnum, und man kann im selben File keine Generic und Generic Tag Refnums mixen vor LabVIEW 8.2 weil das der Objekt Parser scheinbar nicht schnallt) und noch in verschiedenen weiteren Varianten gibt, Generic Tag Flatten, etc) sind völlig undokumentiert soweit ich weiss.
Es gibt da einige private Nodes mit denen man aus einem 32 bit Integer eine Userdata Refnum machen kann. Selber habe ich diese Funktionen aus verschiedenen technischen Gründen gleich im C code ausgeführt, was noch viel undokumentierter ist und absolut frustrierend weil man konstant crasht wenn man etwas nicht richtig hat, was bei undokumentierten Features absolut unvermeidlich ist
Ein anderer frustrierender Aspekt ist das Syntax Errors im RC file die Objekte völlig unsichtbar machen und LabVIEW nirgendwo eine gute Fehlermeldung gibt. Eine minimale Lösung ist das hinzufügen zum INI File von:
createLogFile=True
DPrintfLogging=True
DPrintfToFile=True
promoteDWarnInternals=True
Ich weiss jetzt gerade nicht welche davon wirklich nötig sind und habe keine Lust das auszuprobieren.
Mit diesen Settings kriegt man manchmal eine Zeile mit der Angabe "OMParse: <kurze generike Fehlermeldung mit Zeilennummer>" im dprintf.txt file im LabVIEW Folder.
Die RC Files werden nur beim Starten geparst, (und es gibt scheinbar keine andere Möglichkeit das in LabVIEW anzustossen), also nach jedem Fehler: LabVIEW abschliessen, File editieren, LabVIEW starten, schauen, und in 99% der Fälle ganz fest fluchen
.
Das ist also wirklich eine frustrierende Erfahrung!
EDIT: Was ich noch zu sagen vergass, dies alles ist eindeutig nur sinnvoll im Zusammenhang mit einer externen Library (DLL, shared library) da das ganze "Object Manager" Interface darauf gebaut ist. Das RC File übernimmt die Aufgabe zwischen dieser externen Library und dem LabVIEW Property und Method Interface zu vermitteln und gibt LabVIEW die nötigen Informationen um den Maschinencode zu erzeugen um diese externe Library aufzurufen. Das bedeutet aber auch dass die externe Library ganz spezifische Funktionen exportieren muss und alle Datentypen die diese Funktion empfängt für Property und Method Implementation sind immer native LabVIEW Datentypen (String und Array Handles) und müssen mit den entsprechenden LabVIEW Manager Funktionen erzeugt, verändert und frei gegeben werden.
Das alles wird es für die meisten potentielen Benützer wohl eher unwahrscheinlich machen dass sie sich überhaubt da hinein arbeiten wollen da die shared Library ganz explizit für LabVIEW und dieses Interface geschrieben werden muss, und man wirklich sehr viele Kenntnisse über die LabVIEW C Datentypen und Schnittstellen haben muss.