Laufzeitproblem

Moin,

ich habe ein Programm, dass einen Ausgang verzögert Schaltet. Da teilweise sehr lange Schaltzeiten eingegeben werden und man sehen soll, wo das Programm gerade ist, habe ich einen Fortschrittsbalken eingebaut, der in einer For Schleife alle 100 ms aktualisiert wird. Die For Schleife ist sowieso nötig, da ich das Programm eventuell auch anhalten will, wenn die Verzögerung gerade läuft.

Leider ist es so, dass durch while Schleife Zeitprobleme entstehen: Wenn ich die zeit nachmesse und mit der eingegebenen Zeit vergleiche bestehen immer gewisse unterschiede.

   

Mir ist klar, dass die 3 Lokalen Variablen in der Schleife alles andere als optimal sind, allerdings hat sich auch nicht viel geändert, nachdem ich die "verz0" aus der gelesen wird, durch ein Shift register ersetzt habe.

Falls jemand einen Vorschlag hat, wie ich das Laufzeitproblem beheben kann, bin ich dankbar.

Anzeige

Hallo,

mit der Funktion "Wait", die du verwendest hältst du den gesamten Programmablauf (in dem jeweiligen VI) bei jedem mal Ausführen der while Funktion für 100ms an.

Du kannst dir zum Beispiel einen periodischen Trigger bauen, mit dem du alle 100ms sozusagen eine aktualisierung auslößt.

lG nookie

Wege der lokalen Variable muß Du Dir hier keine Gedanken machen. Ich für für meinen Teil scheue aber Konvertierungpunkte wie der Teufel das Weihwasser. Ich würde die Verzögerungsanzeige auf I32 umstellen, und das IQ aus dem Divisorausgang in I32 konvertieren. Die Lokale Vrz0 schreibend könnte man durch eine Konstante ersetzen, und man brauchte in "Fortschritt2" nicht dauernd eine Null hineinschreiben. Und die Wait-Funktion würde ich hier durch einen Metronom ersetzen.

Und was LV-Professional nookkie sagt ist falsch: Die Wait-Funktion blockiert nicht den "gesamten Programmablauf". Die Wartezeit wird im Gegenteil dazu genutzt, daß alles getan wird, was sich in anderen Teilen des Programmes noch erledigen läßt.
Blockieren würde das Wait nur dann, wenn das ganze Programm in eine Sequenzstruktur eingebettet wäre - was leider Anfänger sehr gern tun, da sie dem Datenflußprinzip nicht so recht trauen. Während das Programm in einer Sequenz wartet, werden alle anderen Sequenzen blockiert.

Das heißt also, dass solange die Funktion wartet nichts anderes abläuft... Dann dauert das Schreiben und Lesen bei den lokalen Variablen ja gar nicht so lange...

Wie kann ich einen externen Trigger realisieren?

@Lucki:

Ich habe die Verzögerung durch ein Metronom ersetzt, was zur Folge hatte, dass die Abweichungen noch größer wurden. Die funktion wartet ja auf das nächste Vielfache von der Zahl die man übergibt. und wenns da noch ein bischen hin ist, dauerts halt.
Die Datentypen werd ich ändern und mal schaun.

Bitte keine externen Bilderlinks von VIs!! :rulez:Ich habe den Link gelöscht und das Bild hier hochgeladen.

Gruß Markus

' schrieb:Moin,

ich habe ein Programm, dass einen Ausgang verzögert Schaltet. Da teilweise sehr lange Schaltzeiten eingegeben werden und man sehen soll, wo das Programm gerade ist, habe ich einen Fortschrittsbalken eingebaut, der in einer For Schleife alle 100 ms aktualisiert wird. Die For Schleife ist sowieso nötig, da ich das Programm eventuell auch anhalten will, wenn die Verzögerung gerade läuft.

Leider ist es so, dass durch while Schleife Zeitprobleme entstehen: Wenn ich die zeit nachmesse und mit der eingegebenen Zeit vergleiche bestehen immer gewisse unterschiede.

[attachment=57207:boxdv8bk.png]

Mir ist klar, dass die 3 Lokalen Variablen in der Schleife alles andere als optimal sind, allerdings hat sich auch nicht viel geändert, nachdem ich die "verz0" aus der gelesen wird, durch ein Shift register ersetzt habe.

Falls jemand einen Vorschlag hat, wie ich das Laufzeitproblem beheben kann, bin ich dankbar.

' schrieb:Ich für für meinen Teil scheue aber Konvertierungpunkte wie der Teufel das Weihwasser.

Kleines Gegenargument: Die Konvertierung mit dem Punkt geschieht meist inplace, die händische immer mit einer Datenkopie.

Anzeige

' schrieb:Kleines Gegenargument: Die Konvertierung mit dem Punkt geschieht meist inplace, die händische immer mit einer Datenkopie.

Das hab ich nicht verstanden.

' schrieb:Ich habe die Verzögerung durch ein Metronom ersetzt, was zur Folge hatte, dass die Abweichungen noch größer wurden. Die funktion wartet ja auf das nächste Vielfache von der Zahl die man übergibt. und wenns da noch ein bischen hin ist, dauerts halt.

Wenn das so ist, dann ist in Deinem VI ewas ganz anderes faul. Das was Du hier machst ist so lächerlich wenig, das es, wenn überhaut, im einstelligen Millisekunden-Bereich zu erledigen ist. Dann hast Du in Deinem VI oder in Deiner Windows-Umgebung etwas laufen, was 100% Prozessorlast beansprucht - z.B eine zweite While-Schleife mit vergessenem Wait drin.
Wenn Du nichts findest, dann lade doch mal Dein VI hoch.

@Dimitri

Zitat:Kleines Gegenargument: Die Konvertierung mit dem Punkt geschieht meist inplace, die händische immer mit einer Datenkopie.

Interessant, aber glauben tue ich das erst beim Nachweis, daß NI das so gesagt hat. Ungläubig bin ich schon deshalb, weile eine Inplace-Struktur mir bisher noch niemals Schhnelligkeit gebracht hat, sondern es geht ausschließlich um die Einsparung von Speicherplatz. Also Du mögest mit der Inplace-Struktur durchaus recht haben. Damit ist noch lange nicht geagt, daß Dein Argument hier zieht.

' schrieb:Das hab ich nicht verstanden.

Das hat nicht zwangsläufig mit deinem Thema zu tun. Ich wollte nur kurz einschieben, dass ich auch meine ästhetischen Ansprüche an das BD zurückgeschraubt habe und den roten Punkt (subjektiv impliziert dieser ja subtil ein Fehlverhalten des Programmiers) zähneknirschend akzeptiere.

Fazit: Ein roter Punkt ist halb so wild, da oft weniger Datenkopien angelegt werden, als wenn man es selbst konvertiert.

OK, hier mal die VI


  Verz_gerung.vi (Größe: 26,42 KB / Downloads: 226)


Es stimmt schon, dass die Verzögerung im Bereich von sehr wenig ist. Also, der Fehler liegt immer bei unter 1% meistens sogar unter 0,5%. Dennoch möchte ich wissen, ob es einen Weg gibt, komplett ohne Fehler auszukommen.

Zum Metronom wollte ich noch anfügen: Die Funktion geht nach der Systemzeit und wartet sozusagen darauf, dass diese einen bestimmten wert erreicht. Danach läuft die Schleife dann (idealerweise) mit dem eingegebenen WErt getaktet ab. Also ist der erste Schleifendurchlauf definitv kürzer als man eigentlich will und so entsteht dabei die Abweichung.

Eine Konsequenz, die ich gerade ausgetestet habe, wäre die zeit einfach radikal runterzudrehen. Also mit T = 2ms. Dann ist die Abweichung maximal 2 ms. Das ist natürlich recht Rechenintensiv.