Ich fang mal hier an:
' schrieb:* fast nichts was man anklickt funktioniert
Du musst dir so ein LV-Programm aus vielen parallelen Programmteilen vorstellen. Ein jeder dieser Programmteile heißt Thread. Jeder Thread hat eine Priorität. Es gibt Threads, die "nur selten" aktiviert werden brauchen und solche, die unbedingt "sehr oft" aktiviert werden müssen. Die Threads werden von einem übergeordneten Manager ausgeführt (respektive aktiviert) - und zwar dummerweise hintereinander (es sei denn du hast einen MultiCore). Ob der Manager das Betriebssystem ist oder ob er ein Teil des LV-Runtimesystems ist, spielt für das allgemeine Verständnis keine Rolle. Es gibt zwei Typen von Threads: Solche die sich freiwillig nach einer bestimmten Zeit beenden, und solche, die sich nicht freiwillig beenden - die "beendet" der Thraed-Manager dann mittels eines TimeShareing-Mechanismusses. Wenn ich hier von Zeiten spreche, dann sind das Zeiten zwischen 1 und 50 µs!
Stell dir vor, du hast einen Thread, der aus welchen Gründen auch immer eine (relativ) hohe Priorität hat. Das kann z.B. bedeuten, dass jedes zweite Zeitintervall von genau diesem Thread belegt wird. Für einen "niederwertigen" Thread könnte das jetzt aber bedeuten, dass er bis (um nur mal so eine Zahl zu sagen) zu einer Sekunde warten müsste, um einmal aufgerufen zu werden. Während dieses einen Mals kann der Thread selbst aber nur wenig tun.
Hier hast du jetzt also den Fall, dass ein Thread einen anderen ausbremsen kann. Wenn der ausgebremste Thread z.B. für das Abfragen der Mausklicks zuständig ist, wirst du feststellen: "fast nichts was man anklickt funktioniert". Wer der ausbremsende Thread ist, kann man durch diese Feststellung (nichts funktioniert) nicht feststellen.
Ein solcher Fall tritt z.B. dann ein, wenn in einer While-Schleife keine Zeitverzögerung ist. Die While-Schleife hat bezogen auf das Frontpanel eine sehr hohe Priorität - sie soll ja schließlich was leisten. Das Frontpanel braucht nur relativ langsam aktualisiert werden. Schneller als 100ms kann sowieso keiner kucken. Kommen jetzt aber doch mal viele Daten zum Refreshen an das FP, wird das FP Schwierigkeiten haben, diese auch anzuzeigen - es bleibt einfach nicht genug Zeit übrig, weil die While-Schleife zu viel für sich beansprucht.
Laufzeitprobleme dieser Art würde man über ein Abfragen von Errorclustern nicht feststellen können.
"Vorteil" dieses Fehlers: Die Rechenzeit liegt oft über 50%, sodass ein Erreichen von 100% sehr wahrscheinlich ist.
Zitat:* In diesem Zustand verbraucht LV 0% Rechenzeit
Hierfür habe ich folgende Erklärung.
Ein Thread höchster Priorität blockiert alle anderen Threads - und wartet selbst auf ein Ereignis von außen. Nur zu dumm: das Ereignis kommt nicht. Warum es nicht kommt, kann viele Gründe haben. Einer ist: der externe Programmteil hat "vergessen", dass er ein Event schicken soll. Mit anderen Worten: Ein Handle ist ihm kaputt gegangen.
Zitat:Unklar ist mir aber noch immer, wie kann man LV "hereinlegen" da ist doch (fast) alles abgesichert. In C kann ich einem Pointer einen Text zuweisen und als Zieladresse für einen Sprung verwenden - zoiiing .... aber in LV?
Softwarefehler in LV?
Guckst du meinen Thread über NI-CAN. Einmal hatte ich den Fall, dass mitten im Programmablauf sporadisch der Handle einer Queue verschwunden war. Warum? Keine Ahnung. Problem: Plötzlich ist das sporadische Verschwinden nicht mehr aufgetreten. Warum? Keine Ahnung.
Zitat:1. Code aufräumen - ist leider "organisch" gewachsen (na immerhin ist er bio...)
Dazu rate ich sehr.
Ganz extrem sage ich immer: Je weniger in einem Blockdiagramm steht, um so besser ist das SubVI. Unterprogramme, Unterprogramme, Unterprogramme ...
(Kleines Späßchen: Wenn nix mehr drinnen steht, kann auch kein Fehler mehr auftreten). Ob das Aufräumen des gewachsenen Codes nun "unangenehm" ist oder nicht - es gehört auf jeden Fall gemacht.
Zitat:2. manche Teile mit disable "ausschalten" und schauen was dann passiert
Das ist manchmal die einzige Möglichkeit.
Es gibt auch ganz ordinäre Möglichkeiten, warum dein Programm nicht geht. Du verwendest z.B. eine DLL, die einen Fehler hat. Der bewirkt, dass der Speichermanager oder der Threadmanager von LV durcheinander kommt. Der Fehler in der DLL (oder in der Konfiguration des DLL-Knotens) muss nicht zwangsläufig zu einer AccessViolation führen. Das ist ja das Dumme an gewissen Fehlern: Die Ursache und die Auswirkung eines Fehlers müssen nicht zwangsläufig zusammenhängen. Übertrieben gesagt: Der Fehler an sich kann hier und heute auftreten, eine Auswirkung aber erst übermorgen an einer ganz anderen Stelle.
Es bleibt dir praktisch nur das Disablen übrig. Und eine gewisse Erfahren, die du im Laufe des Programmiererlebens erwirbst, im Umgang mit Fehlern. Eine Erfahrung z.B. sagt: Die Vorschriften sind einzuhalten. Und zwar immer. Beispiel: Und selbst wenn eine einzige globale Variable das Programmieren erheblich vereinfachen würde - sie ist nicht zu verwenden.
