Programm zu langsam - Druckversion +- LabVIEWForum.de (https://www.labviewforum.de) +-- Forum: LabVIEW (/Forum-LabVIEW) +--- Forum: LabVIEW Allgemein (/Forum-LabVIEW-Allgemein) +---- Forum: Datenkommunikation (/Forum-Datenkommunikation) +---- Thema: Programm zu langsam (/Thread-Programm-zu-langsam--2557) |
Programm zu langsam - oswald1 - 22.04.2010 15:21 Hallo, Ich habe ein Problem: Ich benutze mein angehängtes Programm dazu, einem drei Regler von Eurotherm die Sollwerte vorzugeben und die Temperatur-Istwerte und Sollwerte auszulesen. Das Programm funktioniert auch, allerdings ist es extrem langsam, so dass sich LabVIEW teilweise sogar aufhängt. Kann mir da bitte jemand weiterhelfen. Gruß Oswald [attachment=25925] Programm zu langsam - eg - 22.04.2010 15:30 Ich weiss jetzt nicht direkt wo das Problem liegt, aber warum nimmst du den Treiber von Eurotherm nicht? Programm zu langsam - oswald1 - 22.04.2010 19:36 Ich habe ursprünglich ein Demo-Programm von Eurotherm umgeschrieben, allerdings war das Programm mit diesen VIs eher noch langsamer. Da aber ein paar VIs Passwort geschützt sind und ich nicht wusst, warum das Programm so langsam ist, habe ich das Programm mit Standard-VIs umgeschrieben. Falls du mir aber sagen kannst, mit welchen VIs ich das hinkriege, verwende ich die sehr gerne. Gruß Oswald Programm zu langsam - jg - 22.04.2010 20:06 Dann geh doch einmal schrittweise an das Problem. Fragen und Vorschläge zum Testen und Probieren: -Was heißt "langsam", der Begriff ist sehr dehnbar... -Wie sieht es mit der CPU-Auslastung aus? -Wie schnell laufen deine Schleifen wirklich? Hierzu folgendes einbauen: [attachment=25936] -Wie sieht es aus, wenn du nur eine Schleife laufen lässt und die anderen deaktivierst? Was mir gar nicht gefällt, sind die PropertyNode "Visible", die du dauernd schreibst. Eine PropertyNode erzwingt immer ein Update des FP, und das jetzt bei jeder Schleife ein- bzw. sogar zweimal im 20 Hz Takt, finde ich nicht gut. Und eigentlich muss doch nur etwas umgeschaltet werden, wenn du etwas in dem Optionsfeld auswählst. Hierzu ein Vorschlag: eine weitere parallele Schleife mit Event-Struktur. Als Anregung sowas hier: [attachment=25937] -Bei den DataSocket Read und Write VIs auch einen Timeout anschließen?! Gruß, Jens Programm zu langsam - oswald1 - 23.04.2010 08:18 Danke erstmal für eure schnellen Antworten. Also am CPU liegts nicht. Der Task-Manager zeigt praktisch keine Auslastung an. Langsam bedeutet, dass alle Programme, die ich parallel zu diesem VI laufen lasse extrem träge sind. Ich kann im Frontpanel beispielsweise kaum hin-und herscrollen und die Diagramme (anderes VI) zeichnen nicht kontinuierlich, sondern ruckartig. Ich habe einige der Dinge, die du mir geraten hast schon vorher ausprobiert und das Problem liegt (da bin ich mir eigentlich sicher) am Schreiben der Werte. Ich habe auch mal die Zeit für einen Schleifendurchlauf ermittelt, wie du es mir geraten hast und demnach dauert es ca. 700-1400ms (also ewig!). Ich hoffe ihr habt noch eine Idee, woran es liegen kann. Vielen Dank Gruß Oswald Programm zu langsam - IchSelbst - 24.04.2010 10:23 ' schrieb:Ich hoffe ihr habt noch eine Idee, woran es liegen kann.Ich tippe ja auf den OPC als solchem. Du greifst hier parallel mit mindestens fünf (wenn ich's noch richtig im Kopf habe) Datenflüssen auf den OPC zu. Möglicherweise verlangsamt das den OPC - Folge wäre, dass die komplette Applikation hängt, weil der OPC den kompletten Prozess blockiert. Ich selbst greife nur nacheinander auf den OPC zu. Weiterhin könnte eine Möglichkeit für das stockende Arbeiten des FP's daran liegen, dass in den While-Schleifen Wartezeiten fehlen (Wait[ms] oder Metronom mit 1ms wäre ausreichend). Ist die Prozessorauslastung bei 0% und die Applikation hängt (scheint zu hängen), dann kann das darauf hindeuten, dass die Applikation auf eine Rückmeldung vom Betriebssystem wartet. Manche dieser Zustände (Warten auf Rückmeldung) sind mit einem totalen Stopp der Applikation (des gesamten Prozesses) verbunden. Ich kann mir vorstellen, dass dieser Effekt durch den OPC ausgelöst wird, weil er eben parallelen betrieben wird. Das "Stottern" der FP-Anzeige kommt dann dadurch, weil der OPC z.B. nur alle 250ms "zurückkommt" und damit für 10ms Zeit ist, das FP zu refreshen. 10ms deswegen, weil sofort der nächste OPC-Aufruf blockierend wirkt (wegen des fehlenden Wait und der parallelen Ausführung). Noch ein Hinweis. Manche OPCs haben eine Reaktionszeit bis zu 300ms. Daher ist es nicht unbedingt ratsam, die OPC-Befehle kontinuierlich in einer Schleife ohne Wartezeit zu betreiben. |