Step 7 Ampelsteuerung für Parkplatz

Frank2728

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

ich muss eine Steuerung für eine Parkplatz-Ampel entwerfen (bin absoluter Anfänger). Es gibt 50 Stellplätze, Ampel soll rot sein wenn voll, sonst grün. Die Ein- und Ausfahrt ist gemeinsam. Vor dem Eingang liegen 2 Induktionsschleifen (E20.1 und E20.2), die eine "1" liefern, wenn ein Auto drüber ist. Sie sind so dicht beieinander, das für eine gewisse Zeit beide gleichzeitig aktiviert werden, wenn ein Auto drüberfährt.

Um die Fahrtrichtung zu erkennen, will ich eine Flankenerkennung einbauen.

Würde das in FUP so passen, wie ichs mir vorstelle?:

SAM_3892.jpg

Und dann muss ich das ganze noch in AWL umsetzen, da hab ich bisher folgendes:

U E 20.1
FP #Flankenmerker1
= M21.1
U E20.2
FP #Flankenmerker2
= M21.2
U M21.1
UN E20.2
ZV "Zähler"
U M21.2
UN E20.1
ZR "Zähler"

Danke schonmal für alle Tipps!
 
... Um die Fahrtrichtung zu erkennen, will ich eine Flankenerkennung einbauen. ...
Mit Radio Eriwan möchte ich antworten "Im Prinzip ja, aber nur, wenn es Dir nichts ausmacht, unnötigen Ärger mit einzubauen".
Das Stichwort "Flankenerkennung" ist absolut richtig, aber Du machst laut Deinen FUP- und AWL-Darstellungen einen Fehler, auf den schon viele hereingefallen sind, egal, ob sie das Problem per Hardware- oder Software-Lösung knacken wollten. Zum Glück möchtest Du es per Software lösen. Da muss ich nicht gegen die GesichtsPunkte "SchaltungsVereinfachung" und "Einsparung von Bauelementen" argumentieren.
Deine beiden EingangsSignale verlaufen wie folgt:
Code:
[FONT=courier new]Signal 1 : ____:=========:_________

Signal 2 : _________:=========:____

Flanke   :     0    1    2    3

[/FONT]
Es ist egal, welche der vier Flanken 0, 1, 2 oder 3 Du auswertest, ABER bitte suche Dir eine davon aus und werte nur diese eine aus!
Die Auswirkung dieser Massnahme auf den SoftwareAufwand ist kaum bis nicht spürbar, während der HardwareAufwand - je nach Lösungsweg und verwendeten Bauteilen - schon nennenswert sein kann.
Deine Lösung liefert richtige Ergebnisse, aber leider nur solange nicht ein RichtungsWechsel zwischen den beiden Flanken stattfindet, die Du auswertest.
Erspar Dir diesen Ärger - er wird üblicherweise erst (viel zu) spät erkannt bzw. nicht wirklich durchschaut und dann werden obskure StörImpulse bekämpft. Du suchst Dir einen Wolf nach der wirklichen Ursache.
Es ist schlicht und einfach ein logischer Fehler, nicht dieselbe Flanke für beide ZählRichtungen auszuwerten!

Habe Deinen AWL-Code angepasst:
Code:
[FONT=courier new]     UN   E 20.1
     U    #Flankenmerker
     =    M 21.1           neg. Flanke
     U    E 20.1
     FP   #Flankenmerker
     =    M 21.2           pos. Flanke
     U    M 21.1
     U    E 20.2
     ZV   "Zähler"
     U    M 21.2
     U    E 20.2
     ZR   "Zähler"
[/FONT]
Wenn Dir die Einsparung des einen FlankenMerkers nicht geheuer ist, geht es auch so, unter Ver(sch)wendung eines zweiten:
Code:
[FONT=courier new]     U    E 20.1
     FN   #Flankenmerker1
     =    M 21.1           neg. Flanke
     U    E 20.1
     FP   #Flankenmerker2
     =    M 21.2           pos. Flanke
     U    M 21.1
     U    E 20.2
     ZV   "Zähler"
     U    M 21.2
     U    E 20.2
     ZR   "Zähler"
[/FONT]
Gruss, Heinileini

FlankenAuswertung.jpg

PS: in AWL geht's noch einfacher, wenn Du die ImpulsMerker M 20.1 und M 20.2 nicht noch an anderen Stellen auswerten willst:
Code:
     UN   E 20.1
     U    #Flankenmerker
     U    E 20.2
     ZV   "Zähler"
     U    E 20.1
     FP   #Flankenmerker
     U    E 20.2
     ZR   "Zähler"
 
Zuletzt bearbeitet:
Es geht noch etwas einfacher mit nur einer einzigen Flankenauswertung, wenn man die Zählrichtung mit dem zweiten Signal umschaltet. Das ist die vereinfachte Schul-Lösung. Um Falschzählungen zu verhindern, wenn Bodo mit der Werkzeugtasche die Fahrbahn quert, sind in der Praxis weitere Maßnahmen erforderich.

Gruß, Onkel
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Es geht noch etwas einfacher mit nur einer einzigen Flankenauswertung, wenn man die Zählrichtung mit dem zweiten Signal umschaltet.
Na, Onkel Dagobert, da bin ich aber gespannt, wie das ganz konkret aussehen soll! Ich glaube, nein, fürchte, dass Du auch zu den Kandidaten zählst, die sich mit einer vermeintlichen Vereinfachung den unerkannten, aber dann unvermeidlichen Ärger einfangen!
Das ist die vereinfachte Schul-Lösung. Um Falschzählungen zu verhindern, wenn Bodo mit der Werkzeugtasche die Fahrbahn quert, sind in der Praxis weitere Maßnahmen erforderich.
Das Stichwort "SchulLösung" könnte die Erklärung dafür sein, dass das Phänomen so weit verbreitet ist und sich niemand den Kopf über die Ursache zerbricht.
Lieber wird dann über WorkArounds nachgedacht, wie man solche StörImpulse wie den Bodo mit der WerkzeugTasche ausfiltern kann. Aber das geht prinzipiell nicht!
Am einfachsten ist und bleibt es, das "system-immanente" Problem gar nicht erst einzubauen.
Gruss, Heinileini
 
Danke für die ausführliche Antwort! Jetzt hab ich nur noch das Problem, daß ich laut Aufgabenstellung keine Simatik-Zähler verwenden soll, d.h. ich muss den selbst aus FFs zusammenfrickeln. Als Aufwärts-abwärts-Zähler finde ich aber nur solche mit einem Zähleingang und einem Steuereingang für vorwärts/rückwärts. Ich brauche aber ja einen mit 2 Eingängen, einen zum Aufwärts- und einen zum Abwärtszählen. Kennst du da vielleicht eine geeignete Lösung?
 
Na, Onkel Dagobert, da bin ich aber gespannt, wie das ganz konkret aussehen soll! ..
Heinileini, wenn man über die Systematik mal ein wenig nachdenkt, dann ist es doch so dass das Fahrzeug vier Stellen passiert, die man problemlos detektieren kann. Die Reihenfolge ist je nach Fahrtrichtung eine andere. Gezählt wird erst dann, wenn das Fahrzeug alle vier Punkte in der jeweiligen Richtung überfahren hat. Das muss Bodo erst einmal nachmachen. Damit hat man Fehlzählungen WEITESTGEHEND verhindert. Bei deinem vereinfachten Modell mit nur einem Zählpunkt kann es sehr leicht mal vorkommen, eine Werkzeukiste oder Opas Geldbörse zu zählen. Oder mache ich mir zu viele Gedanken?

Nachtrag:
Mein Vorschlag mit nur einer einzigen Flankenauswertung ist zugegebenermaßen noch schlechter als dein Modell. Zum Logic-Lernen ist das alles ok, dann vor allem auch das Diskutieren über die verschiedenen Vor- und Nachteile. Aber für eine praktische Anwendung würde ich dann alle Möglichkeiten ausreizen, um die eigentliche Funktionalität sicherer zu machen.
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Moin Frank2728!
Musst Du nur selbst zusammenfrickeln oder musst Du tatsächlich auch FFs verwenden?
Ohne FFs ist es einfach: Eine INT-Variable nehmen und zum VorwärtsZählen 1 drauf addieren, zum RückwärtsZählen 1 subtrahieren. Die Tatsache, dass Du ein Signal (=ImpulsMerker) für's VorwärtsZählen und ein anderes Signal (=ImpulsMerker) für's RückwärtsZählen hast, ist hierfür ideal.
Mit FFs wird es kompliziert. Du müsstest einen Zähler mit (mindestens) 6-Bit realisieren. Das ist nicht unmöglich, aber ich finde das unangemessen aufwendig im Rahmen Deiner Aufgabe.
Ist das denn wirklich so gemeint? Eine solche Schaltung auszutüfteln, mag für HardwareEntwickler im letzten JahrTausend eine interessante Herausforderung gewesen sein. Aber für jemanden, der lernen soll, einfache SoftwareLösungen zu finden und umzusetzen? "Einfach" ist hier absolut nicht negativ oder despektierlich gemeint - Du weisst ja: kompliziert kann jeder - die Kunst besteht darin, eine einfache Lösung zu finden!
Darum möchte ich es uns ersparen, auf Deine FF-Variante einzugehen.

Die bisherige Lösung, mit ZV und ZR einen S5-/S7-Zähler zu inkrementieren/dekrementieren beinhaltet übrigens ein Problem, das ich in diesem Thread bisher verschwiegen hatte:
Du kannst damit Probleme bekommen, wenn es zu einem Zähler-Unterlauf oder -Überlauf kommt. Bei maximal 50 Fahrzeugen dürftest Du nie auf einen Zählerstand >999 kommen, aber die Untergrenze 0 ist gar nicht so unkritisch, wie man wahrscheinlich annimmt!
Tatsächliche StörImpulse werden sozusagen automatisch korrigiert, wenn sie nicht auf beiden Eingängen gleichzeitig auftreten. Dazu muss man den Zähler nur "machen lassen". D.h. aber, man muss zulassen, dass der Zähler auch mal einen Unterlauf (oder Überlauf) klaglos verarbeitet und nicht verhindert. So gesehen ist die Methode, das Zählen über eine Variable, die inkrementiert/dekrementiert wird, sogar besser.
Gruss, Heinileini
 
Zuletzt bearbeitet:
Von FFs steht nichts in der Aufgabe, ich habs mir nur so gedacht, weil ich eben die Zähler aus der Digitaltechnik-Vorlesung aus T-FF's und so in Erinnerung hatte. Aber wenn es auch einfacher geht, um so besser :D

Das mit der INT-Variablen geht dann aber nur in AWL, oder? (Bis jetzt hab ich nur mit FUP gebastelt, da läßt sich das wohl nicht irgendwie einfügen?)
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Und ich bin so furchtbar ungeübt in FUP. "Bedingtes" Addieren bzw. Subtrahieren (Inkrementieren bzw. Dekrementieren) geht in AWL, indem man die Anweisungen "normalerweise" überspringt und nur ausführt, wenn die Bedingung erfüllt bzw. der entsprechende ImpulsMerker 1 ist. Die FUP-Variante kann ich Dir aus dem Ärmel nicht sagen. Die bedingte Ausführung über den EnableEingang des ADD- bzw. SUB-"Kästchens" sollte es geben.

Vermutlich
FUP.jpg
 
Zuletzt bearbeitet:
... dann ist es doch so, dass das Fahrzeug vier Stellen passiert, die man problemlos detektieren kann. Die Reihenfolge ist je nach Fahrtrichtung eine andere. Gezählt wird erst dann, wenn das Fahrzeug alle vier Punkte in der jeweiligen Richtung überfahren hat. ...
Vorbehaltlos einverstanden!

... Das muss Bodo erst einmal nachmachen. Damit hat man Fehlzählungen WEITESTGEHEND verhindert. Bei deinem vereinfachten Modell mit nur einem Zählpunkt kann es sehr leicht mal vorkommen, eine Werkzeukiste oder Opas Geldbörse zu zählen. Oder mache ich mir zu viele Gedanken? ...
Die Geldbörse ist eher unkritisch. Für die findet sich schnell ein ehrlicher oder unehrlicher Finder, der sie entfernt und die Zählung dadurch korrigiert.
Was aber, wenn ein Auto die Schleifen überfährt, während der StörFaktor Geldbörse noch dort liegt? Dann nix 4 Flanken in einer der beiden erwarteten Reihenfolgen!
Alle 4 Flanken auszuwerten ist nicht das Problem, auf das ich hinweisen wollte. Das gibt es nur wenn man 1 oder 2 oder 3 der 4 Flanken auswertet.
Wenn Du nicht der Meinung bist, dass man für die eine ZählRichtung genau dieselben Flanken benutzen muss, wie für die andere, dann bist Du auf die Falle hereingetappt.
Dann hast Du Dir nicht zu viele Gedanken gemacht, sondern zu wenige.

... Mein Vorschlag mit nur einer einzigen Flankenauswertung ist zugegebenermaßen noch schlechter als dein Modell. Zum Logic-Lernen ist das alles ok, dann vor allem auch das Diskutieren über die verschiedenen Vor- und Nachteile. Aber für eine praktische Anwendung würde ich dann alle Möglichkeiten ausreizen, um die eigentliche Funktionalität sicherer zu machen.
Gerade "zum Logic-Lernen" finde ich es absolut verkehrt, den logischen Fehler unerwähnt zu lassen oder gar sehenden Auges zu tolerieren.
Er hat verheerende Folgen, nur weil man sich einredet "wann wird schon mal der Fall eintreten, dass ausgerechnet zwischen (z.B.) Flanke 1 und 2 die Richtung umgekehrt wird?"
Möglicherweise wird dort nie eine RichtungsUmkehr stattfinden. Aber es gibt auch die real existierenden StörImpulse und die können durchaus genau dort auftreten.
Ich möchte nicht wissen, wie viele Stunden schon nutzlos damit verbraten wurden, diesem Fehler hinterherzusuchen und schlimmer noch, vermeintliche Gegenmassnahmen auszutüfteln und wegen ihrer Wirkungslosikeit wieder zu verwerfen.
Es ist sooo einfach, diesen Fehler zu vermeiden und so verführerisch, ihn wegen vermeintlicher Vereinfachungen dann doch zu begehen.
Gruss, Heinileini

PS: In der Zeitschrift elektor (Nr. 555, Seite 114 und 115) gab es in diesem Jahr einen Beitrag, bei dem der Autor auf die kleine, unscheinbare Falle hereingefallen ist, selbstverständlich motiviert durch eine "raffinierte" SchaltungsVereinfachung mit zwei D-FFs. Das eine Signal geht auf den D-Eingang des einen FFs und auf den TaktEingang des anderen und umgekehrt. Die Resets wurden auch noch verwurstet und die EingangsSignale durch TiefPässe verflacht und durch SchmittTrigger wieder "entflacht" - aber damit fängt man sich eine zusätzliche EmpfängnisBereitschaft für StörImpulse ein, ohne jedoch den grundsätzlichen Fehler beheben zu können.
 
Zuletzt bearbeitet:
Ist ja witzig, wenn dann (noch) Merker verwendet werden dürfen?!
:rolleyes:

Es ist wörtlich von "speziellen Siemens-Funktionen" die Rede, die nicht vorkommen sollen. Ich dachte da an Zähler und Timer. Gehören Merker denn auch dazu?

O.k., die kann man doch einfach durch einen beliebigen Eingang oder Ausgang ersetzten, der nicht als solcher genutzt wird (so hab ich es verstanden).

Wie ist es denn mit der Flankenerkennung? Ist das auch irgendwie "speziell"? Dann sollte ich die vielleicht auch noch ersetzen.


@Heinileini: Danke, das mit dem ADD und SUB - Kasten versuche ich mal.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
O.k., die kann man doch einfach durch einen beliebigen Eingang oder Ausgang ersetzten, der nicht als solcher genutzt wird (so hab ich es verstanden).
Ganz schlimm.
;)

Für Zwischenspeicher, die nur in diesem Baustein benutzt werden, sollten lokale Variablen verwendet werden.
Werden sie über den Zyklus hinaus benötigt (z.B. Flankenmerker, Setzen/Rücksetzen, Zähler) als statische Variablen.
Werden sie nur im aktuellen Zyklus erst beschrieben und danach nur noch in diesem Zyklus benötigt (z.B. erkannte Flanke), können sie temp sein.
Im Zweifelsfall statisch benutzen.

Speicher für mehrere Bausteine sind z.B. globale Datenbausteine.
 
Zuletzt bearbeitet:
Es ist wörtlich von "speziellen Siemens-Funktionen" die Rede, die nicht vorkommen sollen. Ich dachte da an Zähler und Timer. Gehören Merker denn auch dazu?
O.k., die kann man doch einfach durch einen beliebigen Eingang oder Ausgang ersetzten, der nicht als solcher genutzt wird (so hab ich es verstanden).
Wie ist es denn mit der Flankenerkennung? Ist das auch irgendwie "speziell"? Dann sollte ich die vielleicht auch noch ersetzen.
Hallo Frank2728!
Die Merker sind zumindest keine "Funktion". Und es ist eher "nicht zeitgemäß", sie bedachtlos zu verwenden. Als FlankenMerker wird man sie Dir wohl durchgehen lassen.
Ich denke, es ist wichtig, dass Du weisst, wann Du temporäre Variablen benutzen kannst und solltest und auch, wann Du auf Variablen angewiesen bist, die "langlebig" sein müssen.
Du wirst Deine Software in einen (oder mehrere) "Baustein(e)" packen, OB, FB oder FC. Am Anfang eines FB oder FC legst Du Deine temporären Variablen an (L...), die nur in diesem Baustein verfügbar sind.
Gleichnamige temporäre Variablen anderer Bausteine sind damit nicht identisch.
Selbst wenn Du denselben Baustein wieder neu aufrufst - im selben oder im nächsten Zyklus, haben diese temporären Variablen nicht mehr den Inhalt vom vorherigen Aufruf. Ausnahmen gibt es nur, wenn das BetriebsSystem schlampt und sie sind dann nur rein zufällig.
Deine ZählerVariable und die Flanken"Merker" dürfen nicht temporär sein.
Ihr Zustand muss mindestens von einem Aufruf zum nächsten Aufruf des Bausteins erhalten bleiben (die Flanken"Merker") oder sogar noch viel länger (die ZählerVariable).
Deine Impuls"Merker" (M 20.1 ...) oder andere Hilfs"Merker" sollten temporär sein - es gibt keinen Grund, weshalb sie ausserhalb des Baustein(aufruf)s noch gültig sein müssten.
Freie Eingänge oder Ausgänge (der ProzessAbbilder) kann man als Merker missbrauchen - aber das solltest Du nicht tun - wenn das keine dicken MinusPunkte gibt, dann darfst Du Deinem Lehrer von mir vor's Schienbein treten ;o)
Die Begriffe "FlankenMerker" und "ImpulsMerker" und "HilfsMerker" stammen noch aus einer Zeit, als man keine grosse Auswahl hatte und sich noch selbst Bereiche definieren musste, die man entweder temporär oder global benutzen wollte. Deshalb bin ich dazu übergegangen, hier Flanken"Merker", Impuls"Merker" und Hilfs"Merker" zu schreiben, weil ich damit nur sagen will, dass es Bits sind, die sich etwas merken können. Ob im Bereich der Merker oder sonstwo, ist damit nicht festgelegt.
Die FlankenErkennung gehört allerdings schon in den Bereich "Funktion" und ob man sie als Siemens-spezifisch einordnet oder nicht, sei dahin gestellt.
Die FlankenErkennung ist Gott sei Dank keine Zauberei und es gab sie schon lange bevor FP und FN erfunden wurden - mit allereinfachsten Mitteln selbst gebastelt! Da kann ich Dir helfen.
Ich möchte sogar jedem empfehlen, der bei der Anwendung von FP bzw. FN ins Grübeln oder Straucheln kommt, sich einmal anzusehen, wie das funktioniert.
Es ist so einfach, dass man es versteht und nie wieder vergisst - was ich von der Anwendung von FP bzw. FN nicht wirklich behaupten möchte - wer hätte da nicht schon mal vorsichtshalber nachgeschlagen oder so lange herumprobiert, bis es plötzlich und unerwartet dann doch funktioniert hat.
Code:
[FONT=courier new]POS:
     U    Signal                      neuer Zustand ist 1 und
     UN   Flanken"Merker"             alter Zustand war 0 dann
     =    ImpulsBeiPositiverFlanke    liegt eine positive Flanke vor

NEG:
     [FONT=courier new]UN   Signal                      neuer Zustand ist 0 und
     U    Flanken"Merker"             alter Zustand war 1 dann   
     =    ImpulsBeiNegativerFlanke    liegt eine negative Flanke vor

ALL:
[/FONT] [FONT=courier new]    X    Signal                      neuer Zustand ist so und
     X    Flanken"Merker"             alter Zustand war anders dann
     =    ImpulsBeiJederFlanke        liegt irgendeine (pos. oder neg.) Flanke vor

IMM:
     U    Signal                      neuen Zustand für nächsten Zyklus "langlebig" speichern
     =    Flanken"Merker"             weil er dann als alter Zustand benötigt wird
[/FONT][/FONT]
Anmerkung: Die "SprungZiele" POS:, NEG:, ALL: und IMM: werden nicht als SprungZiele benutzt - habe sie nur als MiniKommentare missbraucht!
IMM: soll heissen, dass die folgenden beiden Befehle immer durchlaufen werden müssen. Also nicht überspringen und nicht den Baustein vorher beenden!
Für die jeweils 3 Befehle nach POS:, NEG: oder ALL: gilt: wenn man sie nicht benötigt - weglassen.
Es ist nur 1 Flanken"Merker" erforderlich, denn es gibt ja nur 1 Signal, von dem man sich den aktuellen Zustand für später merken muss.
Aber Achtung: diese "Weisheit" gilt nicht, wenn man mit FP und FN arbeitet! Habe in #2 gezeigt, wie man FP oder FN (nur 1 von beiden!) mit "konventionell" kombinieren könnte.

Gruss, Heinileini
 
Zuletzt bearbeitet:
Ich nenne den Flanken"Merker" meistens "Zustand_vorher" - da ist die simple Funktion der Flankenerkennung und warum man für mehrere Auswertungen nur 1 "Merker" braucht noch einfacher zu verstehen.

Harald
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Frank2728!
Ich möchte auf das Diagramm aus #2 zurückkommen ...
Deine beiden EingangsSignale verlaufen wie folgt:
Code:
[FONT=courier new]Signal 1 : ____:=========:_________

Signal 2 : _________:=========:____

Flanke   :     0    1    2    3
[/FONT]
... und einen Aspekt ergänzen, der mir persönlich sehr zum Verständnis geholfen hat.
Ich finde es überflüssig und sogar verwirrend, wenn man obiges Diagramm für die Betrachtung der einen Richtung nutzt und für die Betrachtung der umgekehrten Richtung ein zweites Diagramm erstellt, in dem die beiden Signale andersherum gegeneinander verschoben sind.
Ich verwende nur das eine Diagramm und lese es von links nach rechts für die eine Richtung und von rechts nach links für die andere Richtung.
Viele denken dabei an "Zeit rückwärts laufen lassen" und sträuben sich deshalb vehement dagegen, sich mit "meiner" Betrachtungsweise anzufreunden.
Vielleicht kannst Du Dich damit anfreunden und vielleicht hilft auch Dir diese Betrachtungsweise, wie sie mir geholfen hat.
Das Thema "RichtungsWechsel" ist dann nicht mehr mit Umdenken verbunden und man gerät auch nicht mehr in Zweifel, ob man von dem einen Diagramm auch wirklich an die entsprechende Stelle des anderen Diagramms gesprungen ist.
Mich würde interessieren, wie Du damit klar kommst - hilft es Dir, oder bist Du da eher skeptisch?

Gruss, Heinileini
 
Vorbehaltlos einverstanden! ..

Ich dachte schon, du hättest es verstanden.

.. Wenn Du nicht der Meinung bist, dass man für die eine ZählRichtung genau dieselben Flanken benutzen muss, wie für die andere, dann bist Du auf die Falle hereingetappt.
Dann hast Du Dir nicht zu viele Gedanken gemacht, sondern zu wenige ..

Was hast du denn an #8 nicht verstanden? Ich habe mich doch eigentlich sehr präzise ausgedrückt.
 
Moin Harald!
Ich nenne den Flanken"Merker" meistens "Zustand_vorher" - da ist die simple Funktion der Flankenerkennung und warum man für mehrere Auswertungen nur 1 "Merker" braucht noch einfacher zu verstehen.
Ja! Absolut.
Lese ich aus Deinem Beitrag (sozusagen zwischen der einen Zeile ;o) auch eine gewisse Zustimmung, dass FP und FN eigentlich so überflüssig sind wie ein Kropf und leider dazu beitragen, dass sie immer wieder Zweifel und VerständnisSchwierigkeiten auslösen?

Grusss, Heinileini
 
Zurück
Oben