TIA Hupe/Leuchte mit definierter Anzahl

Dataworld-EDV

Level-2
Beiträge
114
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Zusammen,
ich bin dabei eine Sequenz zu bauen, die mir auf ein Signal hin (M230.0) eine definierte Anzahl von Blinktakten ausgibt (hier genau 2).
Ich bräuchte aber im gesamten auch 3,4,6 Takte.
Das Netzwerk läuft soweit, aber stoppt nicht immer korrekt. Mal sind es 2 Takte, mal 3??
Kann mir da jemand einen Tip geben, wie man das evtl. besser machen kann.
Danke.
Gruss
 
persönlich hätt ich's mit 2 Timern (Puls und Pause) und einer Zählervariable statt dem dritten Timer gelöst, dann lässt sich's auch einfach für 3..6 Pulse abändern, könnte so oder so ähnlich aussehen:


1655104055921.png
 
Sollen die 2,3,4,... Pulse einmalig ausgegeben werden oder zyklisch immer wieder mit einer Pause dazwischen?
Wie wird bestimmt, wieviele Pulse ausgegeben werden sollen?
Kann es vorkommen, daß die Bedingungen für 3,4,5... Pulse gleichzeitig erfüllt sind? Gibt es da einen Vorrang was ausgegeben werden soll? Oder sollen dann nacheinander erst 3, dann 4, dann 5, dann wieder 3, dann 4 ... Pulse ausgeben werden?

Kannst Du mal insgesamt beschreiben, wofür die Pulsausgabe der unterschiedlichen Anzahl Pulse benötigt wird?

Vielleicht inspiriert Dich auch diese Aufgabe mit der Ausgabe von 16 verschiedenen Blinkcodes:

Harald
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Oder ohne Timer mit einer ZählVariablen, die zur Aktivierung mit 2 * n geladen wird.
Dabei ist n die Anzahl der gewünschten Impulse.
Das TastVerhältnis wäre 1:1, d.h. das Aufleuchten dauert solange wie die Pause zwischen LeuchtEreignissen.
Die ProgrammPassage, die das Blinken macht, wird in regelmässigen zeitlichen Abständen aufgerufen (z.B. alle 500 ms) und rechnet ...

Code:
IF Zählerstand > 0 THEN
    Zählerstand := Zählerstand - 1  ;
END_IF ;
Leuchte := (Zählerstand MOD 2) > 0 ;

Edit:
Zur Aktivierung mit 2 * n laden - nicht, wie ich ursprünglich geschrieben hatte, mit 2 * n - 1.
Im zyklischen Programm (nicht im ZeitAlarm) z.B.:
Code:
IF Start AND NOT StartZuvor THEN
    Zählerstand := 2 * n  ; // Zähler laden ("aktivieren") bei positiver Flanke von Start
END_IF ;
StartZuvor := Start  ; // StartZuvor muss statisch (NICHT temporär) sein

Der Takt wird auch nur einmal durchlaufen, bis dann wieder eine positive Flanke kommt.
Dann startet die Taktung neu.
Falls die nächste positive Flanke von Start zu erwarten ist, bevor eine laufende Blinkaktion beendet ist, müsste man sich noch überlegen, wie der Ablauf sein soll - z.B. eine längere Pause zwischen zwei BlinkAktionen einfügen - und das Programm entsprechend anpassen.
 
Zuletzt bearbeitet:
Gerade wenn eine unterschiedliche Anzahl Pulse ausgegeben werden soll, dann muß man eine Ebene abstrakter denken und nicht jede Pulszahl separat mit einzelnen Gattern voll ausprogrammieren. Da bietet sich so ein Rückwärtszähler wie bei Heinileini förmlich an, der zum Start mit einem Wert passend zur gewünschten Anzahl Pulse geladen wird und bis 0 herunterzählt und bei 0 wieder stehenbleibt. Da spart man jede Menge Logikverknüpfungen.

Harald
 
Hallo Zusammen,
es wird immer nur eine Taktung ( 2,3,4,....) aktiviert.
Auf die steigende Flanke sollen dann, die Anzahl der Takte wird vorher definiert, entweder durch eine Zahl oder durch verschiedene Programmierung (Netzwerke), die Anzahl der Takte ausgegeben werden, unabhängig davon ob der Signal am Eingang noch ansteht oder nicht.
Der Takt wird auch nur einmal durchlaufen, bis dann wieder eine positive Flanke kommt.
Dann startet die Taktung neu.
Danke.
Gruss

Edit:
Die nächste positive Flanke kommt definitiv erst, wenn die vorherige Sequenz fertig ist!!
 
Zuletzt bearbeitet:
Der Programmteil von @Heinileini darf dann aber nicht zyklisch durchlaufen werden, oder?

In einem ZeitAlarm (z.B. alle 500 ms) aufrufen:
Code:
IF Zählerstand > 0 THEN
    Zählerstand := Zählerstand - 1  ;
END_IF ;
Leuchte := (Zählerstand MOD 2) > 0 ;

Zyklisch durchlaufen:
Code:
IF Start AND NOT StartZuvor THEN
    Zählerstand := 2 * n  ; // Zähler laden ("aktivieren") bei positiver Flanke von Start
END_IF ;
StartZuvor := Start  ; // StartZuvor muss statisch (NICHT temporär) sein

Das "VerbindungsGlied" zwischen dem zyklischen Programm (in dem "nur" eine BlinkAbfolge gestartet wird) und dem ProgrammSchnippsel im ZeitAlarm (der den Zählerstand in ein Blinken umsetzt) ist einzig die ZählVariable.
Irgendwo muss der Wert für n vorgegeben werden, entsprechend der gewünschten Anzahl Blink-Impulse.
Für den Zählerstand am einfachsten (?) eine globale INT-Variable deklarieren.
 
Zuletzt bearbeitet:
Hallo Zusammen,
ich habe die Programmsequenzen von @Heinileini mal erstellt, aber irgendwie läuft der Baustein nicht los.
Keine Fehlermeldungen, aber die Sequenz läuft nicht.
Was habe ich falsch gemacht?
Danke für einen Tip.
Gruss
 

Anhänge

Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Servus,

die beiden Bausteine müssen ein wenig zusammen kommunizieren. Nur weil die beiden Parameter im jeweiligen Baustein gleich heißen, heißt das nicht das es die selbe Variable ist.

Schieben wir mal im FB "AufrufTimer" den Zählerstand in die InOuts damit wir von außen die Zählvariable anhängen können und im FB lesend und schreibend darauf zugreifen zu können..

Und da du die Leuchte auch irgendwie ansteuern willst, schieben wir die Leuchte in die Outputs.
1657610004851.png
Wir sehen, dass der Staticbereich leer ist, was es uns erlaubt aus dem FB doch eher einen FC zu machen.
1657610230136.png

Weiter zum FC "Baustein_1".
Der Zählerstand wird hier nur schreibend verwendet sollte aber nicht kontinuierlich auf den berechneten Wert geschrieben werden, also können wir ihn in die Durchgangsparameter InOuts schieben.
Eine Inputvariable kann man nämlich nur in bestimmten Fällen beschreiben.

In einem Kommentar steht, dass "StartZuvor" im statischen Bereich sein soll.
Leider haben wir hier einen FC und keinen FB, also kann man hier im InOut ein Hilfsbitanlegen oder wir machen aus dem FC doch lieber einen FB und schieben das "StartZuvor" in den Staticbereich.

Der Ausgang "Leuchte" wird im FC/FB gar nicht verwendet, den können wir verwerfen.

1657611679977.png

Im Weckalarm-OB rufen wir unseren neuen FC auf und Hängen die Zählvariable an und den Ausgang für die Leuchte.
1657611092798.png
Im OB1 versorgen wir den neuen FB mit dem Eingang zum Starten und den Eingang mit der Anzahl der Leuchtzyklen.
Am Ausgang hängen wir noch die selbe Zählvariable die wir im Weckalarm-OB am FC "AufrufTimer_2" verwendet haben.
1657611288510.png

Wenn du jetzt im OB1 die n mit einer Zahl größer 1 und kleiner 16.383 versorgst und "Start" auf true setzt, wird im Weckalarm-OB der Ausgang der Leuchte n-mal auf true und false gesetzt.

Edit:
Sollte sogar bis 32.767 gehen, da sich der Integeroverflow und -underflow aufheben.
 

Anhänge

  • 1657611269407.png
    1657611269407.png
    26,2 KB · Aufrufe: 8
  • 1657610756778.png
    1657610756778.png
    47,2 KB · Aufrufe: 8
Zuletzt bearbeitet:
Edit:
Sollte sogar bis 32.767 gehen, da sich der Integeroverflow und -underflow aufheben.
Wenn im "WeckAlarm-Baustein" die ZählVariable als INT interpretiert wird, bleiben aber die Problemchen, dass der Vergleich auf > 0 nicht wunschgemäss funktioniert und auch das Subtrahieren von 1 nicht wirklich zweckmässig ist.
Und gab's da nicht auch ein Problem mit der ModuloFunktion bei negativen Dividenden? Oder negativen Divisoren? Oder war das bei CodeSys?

Na ja, wenn's wirklich um Blink- bzw. HupSignale geht, hat wohl keiner ein Interesse daran, die OberGrenze von 16.383 Impulsen zu knacken.
Und wenn doch, könnte man statt INT einfach UINT oder sogar DINT oder UDINT wählen ...

Nichtsdestotrotz, besten Dank für Deine tatkräftige und ausführliche Unterstützung!
Leider konnte ich mit der ZIP-Datei bzw. der "entzippten" Datei des nicht funktionierenden Programms nichts anfangen (ausser sie in einem HexEditor zu "bewundern") und hatte deshalb nicht darauf reagiert ...
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Leider konnte ich mit der ZIP-Datei bzw. der "entzippten" Datei des nicht funktionierenden Programms nichts anfangen (ausser sie in einem HexEditor zu "bewundern") und hatte deshalb nicht darauf reagiert ...
Sieht nach einer standard Zip-Datei aus in der sich ein V15.1 Archiv befindent :P
 
Zurück
Oben