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!
' schrieb:Was heisst das eigentlich.? Da ist kein C++ code von mir.
Nee, das ist ein Fehler Abfangen in der LV-IDE.
Mit Assertions werden z.B. Sicherheitsüberprüfungen gemacht. Hier: Eigentlich sollte COMMAND, das wohl ein String ist, nicht leer sein, da der nachfolgende Code mit einem leeren String nichts anfangen kann. Assertions fangen also Fehler ab, die gar nicht auftreten können bzw. sollten. Dumm nur, das bei diesem Assertion die Weiterleitung des Fehlers an den Fehlermanager (=> Errorcluster) der IDE fehlt.
Jeder, der zur wahren Erkenntnis hindurchdringen will, muss den Berg Schwierigkeit alleine erklimmen (Helen Keller).
Gelegentlich kommt es ja vor, dass die angezeigte Fehlermeldung mit der Fehlerursache gar nichts zu tun hat. Aus deiner Fehlermeldung würde ich jetzt schließen, dass du zu viele Threads, also z.B. parallele Schleifen, hast. Kann das wahr sein?
Was ich mir als Extremfälle auch vorstellen kann: Zuwenig Hauptspeicher oder zu wenig Plattenspeicher auf der Systemplatte.
Jeder, der zur wahren Erkenntnis hindurchdringen will, muss den Berg Schwierigkeit alleine erklimmen (Helen Keller).
Gelegentlich kommt es ja vor, dass die angezeigte Fehlermeldung mit der Fehlerursache gar nichts zu tun hat. Aus deiner Fehlermeldung würde ich jetzt schließen, dass du zu viele Threads, also z.B. parallele Schleifen, hast. Kann das wahr sein?
Was ich mir als Extremfälle auch vorstellen kann: Zuwenig Hauptspeicher oder zu wenig Plattenspeicher auf der Systemplatte.
zu viele Schleifen kann ich mir fast nicht vorstellen. Ich verwende ständig und bei jeder passenden und unpassenden Gelegenheit While-Schleifen und ich hab z.T. sehr große Projekte mit bis zu 800 selbst geschriebenen VIs, und ich hab nie auch nur ansatzweise mal Probleme gehabt, die daher rühren könnten, dass ich zu viele While-Schleifen verwende.
Soweit ich weiß ist auch lange nicht jede While-Schleife gleich ein Thread unter Windows, aber dazu kann Rolf K. bestimmt mehr sagen ...
' schrieb:zu viele Schleifen kann ich mir fast nicht vorstellen. Ich verwende ständig und bei jeder passenden und unpassenden Gelegenheit While-Schleifen und ich hab z.T. sehr große Projekte mit bis zu 800 selbst geschriebenen VIs, und ich hab nie auch nur ansatzweise mal Probleme gehabt, die daher rühren könnten, dass ich zu viele While-Schleifen verwende.
Soweit ich weiß ist auch lange nicht jede While-Schleife gleich ein Thread unter Windows, aber dazu kann Rolf K. bestimmt mehr sagen ...
Es kommt immer drauf an wie die Schleifen ineinander verschachtelt sind. Wenn die schleifen nacheinander ablaufen können ja sämtliche daten aus den schleifen ausm speicher entfernt werden wenn sie durch sind,.. aber sonst wird der arbeitasspeciher schon ziemlich belastet. wenn man dann noch sequenzvariablen verwendet kann da schon ein speicher volllaufen.
Ich bin noch nicht drüber gestolpert aber gibt es sowas wie endlosschleifen in LabVIEW?
rekursionen können auch böse enden.
*nur ein paar abendliche wochenend gedanken von mir*
LG
Torsten
"Über Fragen, die ich nicht beantworten kann, zerbreche ich mir nicht den Kopf!" (Konrad Zuse)
' schrieb:zu viele Schleifen kann ich mir fast nicht vorstellen. Ich verwende ständig und bei jeder passenden und unpassenden Gelegenheit While-Schleifen und ich hab z.T. sehr große Projekte mit bis zu 800 selbst geschriebenen VIs, und ich hab nie auch nur ansatzweise mal Probleme gehabt, die daher rühren könnten, dass ich zu viele While-Schleifen verwende.
Soweit ich weiß ist auch lange nicht jede While-Schleife gleich ein Thread unter Windows, aber dazu kann Rolf K. bestimmt mehr sagen ...
Also dann tue ich mal. Nein eine LabVIEW Loop ist nicht automatisch ein Thread. Und internes quasi-parallelels Abarbeiten von LabVIEW Diagrammen funktionierte auch zu Zeiten und auf Plattformen wo kein Multithreading verfügbar war (Windows 3.1 und MacOS Classic). LabVIEW verwendet dazu einen eigenen Clumpmanager, wie sie das nennen, der Code in Clumps aufteilt die am Ende eines Clumps jeweils zu anderen unabhängigen Clumps umgeschaltet werden können, wenn den vorhanden. Dieses LabVIEW eigenen Multithreading ist noch immer vorhanden.
Aber mit Multithreading im OS alloziert LabVIEW per Execution System eine Anzahl Threads. Früher waren das zwei, dann vier unabhängig ob SMP oder nicht und heutzutage glaube ich ungefähr acht per CPU core. LabVIEW verteilt dann die Clumps auf die verschiedenen Threads.
Die Fehlermeldung hat aber wohl nichts damit zu tun. Was hier passiert ist, dass der LabVIEW Code, der in C++ geschrieben ist einen ungültigen Parameter erlebt hat. Das verursacht eine Exception in der Library Funktion die aber vom aufrufenden Code nicht abgefangen und behandelt wird. Daher endet die Exception im Standard Exception Handler der verwendeten Library und der kann nicht viel mehr tun als eine Message Box anzeigen. Von da aus gibts zwei Alternativen: Die Applikation abschiessen oder weiterlaufen lassen. Die zweite rennt dann wegen irgendwas gleich wieder in diese Exception und alles beginnt aufs Neue. Nach ein paar mal in diesem Hamsterrad rundgedreht zu haben beginnt die C++ Runtime Library doch langsam Stack- oder andere ähnliche Problem zu bekommen und von da an geht es nur noch in mehr und mehr komischen Fehlern weiter bis irgend ein Exceptionhandler ganz einfach das Ganze brutal abschiesst.
Exceptions sind praktisch aber die konsequente Abhandlung davon ist sehr lästig.
Was uns Rolf ( ) uns, speziell gottfried, gesagt hat ist: Die zweite Fehlermeldung kannst/musst du ignorieren. Die ist mit an 100% grenzender Wahrscheinlichkeit ein Folgefehler der ersten Meldung. Bereits bei der ersten Meldung muss du das Programm beenden.
Was du jetzt machen kannst?
Erstens:
Die (erste) Fehlermeldung an NI schicken. Und auf einer Antwort bestehen. Ggf. weitere Daten mitschicken wie z.B. Zeile und Modul, in der der Fehler aufgeterten ist.
Zweitens:
Das gesamte Projekt hinschicken.
Drittens, interessan:
Durch Weglassen diverser Codeteile feststellen, welcher Code den Fehler auslöst. Was nur, wie auch bei zweitens, sinnvoll ist, wenn der Fehler zuvor zu 100% reproduzierbar ist. Dabei hoffen, dass der Fehler nicht nur in Kombination mehrerer Codeteile auftritt.
Viertens:
Wenn der Fehler nur selten auftritt, also sporadisch und nicht wiederholbar, dann Ansehen wie einen kleinen Schlaganfall: Ignorieren und durch. Irgendwann behebt er sich von ganz von selbst.
Jeder, der zur wahren Erkenntnis hindurchdringen will, muss den Berg Schwierigkeit alleine erklimmen (Helen Keller).
) uns, speziell gottfried, gesagt hat ist: Die zweite Fehlermeldung kannst/musst du ignorieren. Die ist mit an 100% grenzender Wahrscheinlichkeit ein Folgefehler der ersten Meldung. Bereits bei der ersten Meldung muss du das Programm beenden.