B&R Timerfunktion

gaiskasimir

Level-1
Beiträge
113
Reaktionspunkte
13
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo,

ist mir das peinlich:

Timer.jpg

Läuft in der TK1 (10ms)
wenn varx gesetzt wird, und vary "1" wird - welchen Wert hat dann anz?
Da kommt 77 'raus - ich kanns nicht fassen! Warum?

Gruß
Gaiskasimir
 
Servus gaiskasimir,

ich bin nur mal kurz über dein Codechen geflogen.
Wie es aussieht, ist deine erste Zeile so eine Art Taktgeber
und die zweite ein Impuls.
Du scheinst in AB zu programmieren?
Da ist die Nutzung der Zeiten in Funktionsblockform etwas einfacher.
D.h. test "blitzt" im 10ms Takt und vary gibt das für die Impulszeit 1000ms in der if-Bedingung frei.
Solange wird dann anz um eins pro zyklus erhöht. Scheint dann gerade 77 zu ergeben.
Ich habe leider gerade nichts zum Testen hier.

Wenn du mal schreiben würdest, was du damit erreichen willst?

Gruß
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Schneetreiber,

natürlich muß es in meiner Beschreibung heißen "solange vary '1' ist"
Aber: wenn ich in dem Zeitfenster von 10 Sekunden die "Blitze" die alle 100ms Sekunden kommen zähle,
muß "anz" dann nicht 100 werden - und nicht 77 ?!
Es war nur ein Test für Anwendung in der ich Impulse zählen wollte. Doch das Ergebnis war mir unverständlich.
Ich will kein Roundabout für Impulszählung - ich will wissen warum 77!

Danke

Gaiskasimir
 
Da gebe ich dir recht.
Das Problem liegt wohl darin, das deine 10ms Zeit im 10ms Task liegt.
Das läuft natürlich nicht 100% synchron. Mal kommt der Peak noch im Task, mal schafft er es nicht.
Ersetze mal die erste Zeile durch

test=NOT(test)

Dann kommt der Impuls in jedem zweiten Durchlauf der anz-Zähler sollte dann bis 1000/2 also 500 (oder 501?) hochzählen.
 
bin nun zu Hause. Werde Montag im Büro weiter testen. Aber zum "Mal kommt der Peak noch im Task, mal schafft er es nicht": es sind wiederholgenau immer 77
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ja natürlich, der Ausdruck "mal schafft er's, mal nicht", ist nicht sonderlich deterministisch, wie es eine Steuerung eigentlich ist.
Ich habe es mal getestet, es sind auch bei mir 77.
Achtung!! ich schieße jetzt mal ins Blaue:
Es hängt also nicht von der Steuerung oder der Programmkonstellation ab - bei mir läuft da sicherlich etwas anderes als bei dir.
Ich habe mir mal meinen 10ms Task im Profiler angesehen. Da dauert es von Aufruf zu Aufruf (Drei Zyklen habe ich mal ausgemessen)
9978.680µs
9975.664µs
9974.494µs
Es sind also knapp unter 10ms. (Falls ich den Profiler richtig bediene.) ;)
Wie exact jetzt die 10ms Zeit funktioniert???
Jetzt kann man sich ja mal die Mühe machen und ausrechnen, Wie viele Peaks entstehen bei 10ms Takskklassenzeit
und z.B. 10.1ms Timerzeit. Hmm... Da fiele ja quasi (Schönes Wort) ca. jeder 10'te Zyklus aus, müsste also Anz=90 sein.
Bei 10.2 ist es schon jeder fünfte => 80 usw.
Ob uns das jetzt weiterhilft?
Zu guter letzt ist aber klar das man eine 10ms Zeit wohl nicht in einem 10ms Task verwenden sollte.
Ich könnte meine Zykluszeit jetzt mal auf 1ms stellen und sehen was passiert, das würde aber einen Neustart erfordern
und das käme mir gerade etwas ungelegen.
Wenn ich am Montag wieder im Betrieb bin kann ich ja mal sehen, ob ich noch etwas herausfinde.

Schönes Wochenende
 
Hallo,
also meine Tests haben ergeben dass du 2 mal Zeiten 'verlierst'

einmal, da du ja immer einen Zyklus wartest (nachdem es "blitzt") bist du das Zeitglied wieder startest.

D.h. hier verlierst du schon mal....

Ich habe dann versucht das Zeitglied im selben Zyklus wieder zu starten (--> ton_1 statt dem direkten Aufruf). Dann wird's zwar schon besser, aber es passt noch nicht.
Dann ist mir noch aufgefallen, dass hier schon eine 'zu hohe' Startzeit im Zeitglied eingetragen wird. Das stimmt wahrscheinlich für eine 'einfache' Zeitmessung. Du willst ja quasi die 10ms in dieser Taskbearbeitung 2 Mal zählen, sonst müsstest du eben 90 ms verwenden und im selben Zyklus Re-Initialisieren.

Jedenfalls kommt nun DAS VERBOTENE: xx und der Zugriff auf die interne Variable des Zeitgliedes - und zack-bumm: das Ergebnis ist exakt 100 :), besser wäre wahrscheinlich 9 statt 10 zu verwenden :cool:

bg
bb

Code:
		ton_1.IN = NOT test
		ton_1.PT = 10
		ton_1 FUB TON_10ms()
		test = ton_1.Q
		
		TP_10ms(varx, 1000, vary, LDummy1)
		varx = 0
		IF (vary AND test) THEN
			anzahl = anzahl + 1
		ENDIF		

		IF (test = 1) THEN
			xx ACCESS ADR(ton_1.StartTime)
			ton_1.IN = 0
			ton_1 FUB TON_10ms()
			ton_1.IN = 1
			ton_1 FUB TON_10ms()
			xx = ton_1.StartTime - 1
			test = 0
		ENDIF


Pulscnt.jpg
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Gaiskasimir!

das liegt an den 'Nulldurchgängen' im Code.
Wie folgt anders dargestellt ...

TON_10ms_1.IN = test
TON_10ms_1.PT = 10
TON_10ms_1 FUB TON_10ms()
IF (TON_10ms_1.Q = 1) THEN
test = 0
ELSE
test = 1
ENDIF

TP_10ms_1.IN = varx
TP_10ms_1.PT = 1000
TP_10ms_1 FUB TP_10ms()
IF TP_10ms_1.ET = 1000 THEN
varx = 0
ENDIF

IF (TP_10ms_1.Q = 1) AND (TON_10ms_1.Q = 1) THEN
anz = anz + 1
ENDIF

Arbeitet ident und es kommt ebenfalls 77 dabei raus.

Wenn man nun davon ausgeht dass die CPU startet so hat "test" = 0 und wird im ersten Zyklus auf 1 gesetzt.
Im zweiten Zyklus laufen die 10ms und das wird nach 10ms fertig.
Durch die IF wird "test" auf 0 gesetzt und die TK fertig abgearbeitet.
Im nächsten Durchlauf ist "test" = 0 und wird durch die IF auf 1 gesetzt (Der Timer läuft aber noch nicht !)
sondern der startet erst wieder im nächsten Zyklus.
Das heisst also dass es einen "leeren" Zyklus gibt.

Noch klarer wird das wenn man den Task in 1ms abarbeiten lässt.
10ms Timer + 1ms totzeit = 11ms
10 Sekunden / 11ms = 909 ....... im Watch wird bis 91 gezählt bei einer 1ms TK

Somit sind das mehrere "Punkte" die sich hier auswirken:

1) TONs (TNs,.....) haben einen "Nulldurchgang"
2) eine 10ms Taskklasse

Wenn klarer warum dies realisiert werden soll bzw. auch was mit den Impulsen passieren soll gäbe es u. U. noch andere Möglichkeiten.
 
Zurück
Oben