INFO: Dieses Forum nutzt Cookies...
Cookies sind für den Betrieb des Forums unverzichtbar. Mit der Nutzung des Forums erklärst Du dich damit einverstanden, dass wir Cookies verwenden.

Es wird in jedem Fall ein Cookie gesetzt um diesen Hinweis nicht mehr zu erhalten. Desweiteren setzen wir Google Adsense und Google Analytics ein.


Antwort schreiben 

Programm zu langsam



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!

22.04.2010, 15:21 (Dieser Beitrag wurde zuletzt bearbeitet: 22.04.2010 19:16 von jg.)
Beitrag #1

oswald1 Offline
LVF-Grünschnabel
*


Beiträge: 13
Registriert seit: Nov 2009

studentenversion labview 2009
-
de

70563
Deutschland
Programm zu langsam
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

Lv86_img
Sonstige .vi  PID.vi (Größe: 42,89 KB / Downloads: 246)
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
Anzeige
22.04.2010, 15:30
Beitrag #2

eg Offline
LVF-SeniorMod


Beiträge: 3.868
Registriert seit: Nov 2005

2016
2003
kA

66111
Deutschland
Programm zu langsam
Ich weiss jetzt nicht direkt wo das Problem liegt, aber warum nimmst du den Treiber von Eurotherm nicht?

Webseite des Benutzers besuchen Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
22.04.2010, 19:36
Beitrag #3

oswald1 Offline
LVF-Grünschnabel
*


Beiträge: 13
Registriert seit: Nov 2009

studentenversion labview 2009
-
de

70563
Deutschland
Programm zu langsam
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
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
22.04.2010, 20:06
Beitrag #4

jg Offline
CLA & CLED
LVF-Team

Beiträge: 15.864
Registriert seit: Jun 2005

20xx / 8.x
1999
EN

Franken...
Deutschland
Programm zu langsam
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:
   
-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:
   
-Bei den DataSocket Read und Write VIs auch einen Timeout anschließen?!

Gruß, Jens

Wer die erhabene Weisheit der Mathematik tadelt, nährt sich von Verwirrung. (Leonardo da Vinci)

!! BITTE !! stellt mir keine Fragen über PM, dafür ist das Forum da - andere haben vielleicht auch Interesse an der Antwort!

Einführende Links zu LabVIEW, s. GerdWs Signatur.
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
23.04.2010, 08:18
Beitrag #5

oswald1 Offline
LVF-Grünschnabel
*


Beiträge: 13
Registriert seit: Nov 2009

studentenversion labview 2009
-
de

70563
Deutschland
Programm zu langsam
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
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
24.04.2010, 10:23 (Dieser Beitrag wurde zuletzt bearbeitet: 24.04.2010 10:27 von IchSelbst.)
Beitrag #6

IchSelbst Offline
LVF-Guru
*****


Beiträge: 3.697
Registriert seit: Feb 2005

11, 14, 15, 17, 18
-
DE

97437
Deutschland
Programm zu langsam
' 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.

Jeder, der zur wahren Erkenntnis hindurchdringen will, muss den Berg Schwierigkeit alleine erklimmen (Helen Keller).
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
30
Antwort schreiben 


Gehe zu: