-> Hier kostenlos registrieren
Hab den Haken schon gefunden: Der Zählerstand muß nochmal transferiert werden mit T #Zaehlerstand, dann läuft es 
Step 7 Ampelsteuerung für Parkplatz
- Ersteller Frank2728
- Erstellt am
-> Hier kostenlos registrieren
- Beiträge
- 7.015
- Reaktionspunkte
- 2.700
Woher soll denn #Zaehlerstand wissen, dass sich Zaehlerstand_out erhöht hat?
Die Baustein-interne Rechnung sollte normalerweise nur mit der STAT-Variable durchgeführt werden und abschließend wird der Wert von STAT an OUT übergeben.
In Deinem Fall in einem Abwasch:
PS: Da hab' ich doch glatt die neue Thread-Seite übersehen.
Die Baustein-interne Rechnung sollte normalerweise nur mit der STAT-Variable durchgeführt werden und abschließend wird der Wert von STAT an OUT übergeben.
In Deinem Fall in einem Abwasch:
Code:
...
M002: T #Zaehlerstand
T #Zaehlerstand_out
...PS: Da hab' ich doch glatt die neue Thread-Seite übersehen.
Zuletzt bearbeitet:
-> Hier kostenlos registrieren
Hallo Forum,
vielen Dank für die Idee (Anregung).
Da ich nur "hobbymäßig" programmiere, finde ich solche 'Aufgaben' für mich immer sehr willkommen.
Tatsächlich habe ich festgestellt, daß die Flankenauswertung wie in #2 beschrieben, einfach und sehr "schmerzfrei"
funktioniert. (ich hatte auch andere Ideen und Herangehensweisen ... die waren nicht so gut )
Danke :s12:
Daraufhin habe ich ein ganzes Parkhaus im Visier gehabt ... das Thema war ja eine Parkfläche.
Hat man da einen gescheiten FB 'gebastelt' - ist das Parkhaus fast schon fertig
Meine Frage:
- Ich nutze das Taktmerker- Byte der CPU. (Bsp.: MB100)
Ist der FB multiinstanz- fähig, wenn ich im FB z.B. ein M100.4 verknüpfe ?
Das Taktmerker- Byte wird doch über die Hardware generiert.
Mfg mega_ohm
vielen Dank für die Idee (Anregung).
Da ich nur "hobbymäßig" programmiere, finde ich solche 'Aufgaben' für mich immer sehr willkommen.
Tatsächlich habe ich festgestellt, daß die Flankenauswertung wie in #2 beschrieben, einfach und sehr "schmerzfrei"
funktioniert. (ich hatte auch andere Ideen und Herangehensweisen ... die waren nicht so gut )
Danke :s12:
Daraufhin habe ich ein ganzes Parkhaus im Visier gehabt ... das Thema war ja eine Parkfläche.
Hat man da einen gescheiten FB 'gebastelt' - ist das Parkhaus fast schon fertig
Meine Frage:
- Ich nutze das Taktmerker- Byte der CPU. (Bsp.: MB100)
Ist der FB multiinstanz- fähig, wenn ich im FB z.B. ein M100.4 verknüpfe ?
Das Taktmerker- Byte wird doch über die Hardware generiert.
Mfg mega_ohm
- Beiträge
- 6.692
- Reaktionspunkte
- 1.687
Moin mega_ohm!
MultiInstanz-fähig? Parkhaus schon fertig? Hmmm!
Kann man so sehen - muss man aber nicht wirklich.
Unter Parkhaus stelle ich mir mehrere Parkflächen vor.
Will man denn für jede ParkEbene im Parkhaus einen eigenen FüllStandsZähler spendieren? Z.B. um dem Sucher das Kreisen auf einer vollen Ebene zu ersparen?
Wie sieht es denn mit Einfahrt(en) zum und Ausfahrt(en) aus dem Parkhaus aus? Auch insgesamt nur ein einziges Nadelöhr für ein- und ausfahrende Fahrzeuge?
Oder kann ein Fahrzeug einfahren, während ein anderes ausfährt? Können mehrere Fahrzeuge gleichzeitig einfahren? Können mehrere Fahrzeuge gleichzeitig ausfahren?
Du solltest Dir schon Gedanken machen,
- wieviele Zähler Du benötigst und
- wieviele Stellen Du hast, an denen Änderungen "wahrgenommen" werden sollen und
- welche dieser Stellen sich auf welchen Zähler auswirken sollen und
- natürlich auch, ob nicht auch im "Übereifer" zuviel des Guten getan wird und es zu Widersprüchen kommen kann.
Du benötigst evtl. mehrere (Instanzen für) Zähler.
Du benötigst wahrscheinlich mehrere (Instanzen für) Flanken"Merker".
Denkbar ist ohne weiteres, dass
- ein ImpulsBit auf verschiedene Zähler wirken soll und/oder
- mehrere ImpulsBits auf denselben Zähler wirken sollen,
so dass die "Grenzen zwischen den einzelnen Instanzen" bezüglich ImpulsBildung und Zählung nicht identisch sind.
Das Thema "Taktmerker-Byte der CPU" würde ich hier am liebsten ausschliessen - für mein Verständnis hat das rein gar nichts mit Deinen Flanken"Merkern" zu tun und sollte auch nicht für eigene Zwecke missbraucht werden.
Ich gehe mal davon aus, dass Dein FB unter diesen GesichtsPunkten keineswegs als MultiInstanz-fähig abgesegnet werden kann und schon gar nicht, wenn Du meinst, für alle ImpulsBildungen ein und denselben Flanken"Merker" zu benutzen und noch weniger, wenn dafür 1 SystemMerker missbraucht werden soll, den Du und das System für zwei verschiedene Aufgaben benutzen.
Sorry, dass ich Deine Frage nicht in Deinem Sinne beantworten kann und stattdessen neue Fragen aufwerfe ...
Gruss, Heinileini
MultiInstanz-fähig? Parkhaus schon fertig? Hmmm!
Kann man so sehen - muss man aber nicht wirklich.
Unter Parkhaus stelle ich mir mehrere Parkflächen vor.
Will man denn für jede ParkEbene im Parkhaus einen eigenen FüllStandsZähler spendieren? Z.B. um dem Sucher das Kreisen auf einer vollen Ebene zu ersparen?
Wie sieht es denn mit Einfahrt(en) zum und Ausfahrt(en) aus dem Parkhaus aus? Auch insgesamt nur ein einziges Nadelöhr für ein- und ausfahrende Fahrzeuge?
Oder kann ein Fahrzeug einfahren, während ein anderes ausfährt? Können mehrere Fahrzeuge gleichzeitig einfahren? Können mehrere Fahrzeuge gleichzeitig ausfahren?
Du solltest Dir schon Gedanken machen,
- wieviele Zähler Du benötigst und
- wieviele Stellen Du hast, an denen Änderungen "wahrgenommen" werden sollen und
- welche dieser Stellen sich auf welchen Zähler auswirken sollen und
- natürlich auch, ob nicht auch im "Übereifer" zuviel des Guten getan wird und es zu Widersprüchen kommen kann.
Du benötigst evtl. mehrere (Instanzen für) Zähler.
Du benötigst wahrscheinlich mehrere (Instanzen für) Flanken"Merker".
Denkbar ist ohne weiteres, dass
- ein ImpulsBit auf verschiedene Zähler wirken soll und/oder
- mehrere ImpulsBits auf denselben Zähler wirken sollen,
so dass die "Grenzen zwischen den einzelnen Instanzen" bezüglich ImpulsBildung und Zählung nicht identisch sind.
Das Thema "Taktmerker-Byte der CPU" würde ich hier am liebsten ausschliessen - für mein Verständnis hat das rein gar nichts mit Deinen Flanken"Merkern" zu tun und sollte auch nicht für eigene Zwecke missbraucht werden.
Ich gehe mal davon aus, dass Dein FB unter diesen GesichtsPunkten keineswegs als MultiInstanz-fähig abgesegnet werden kann und schon gar nicht, wenn Du meinst, für alle ImpulsBildungen ein und denselben Flanken"Merker" zu benutzen und noch weniger, wenn dafür 1 SystemMerker missbraucht werden soll, den Du und das System für zwei verschiedene Aufgaben benutzen.
Sorry, dass ich Deine Frage nicht in Deinem Sinne beantworten kann und stattdessen neue Fragen aufwerfe ...
Gruss, Heinileini
-> Hier kostenlos registrieren
Den "Taktmerker" benötige ich für die Vorwarnung, falls eine Schranke zum Einsatz kommt. (z.B. an der Zufahrt für das
Parkhaus )
Für jedes Parkdeck wird der FB aufgerufen.
Dem FB werden die "max. Anzahl Stellplätze", "Vorwarnen bei Belegung in %", die Eingänge für die Induktionsschleifen
(bei mir müssen Lichtschranken reichen ) und eine Kontroll-Lichtschranke in der Mitte zwischen den beiden Schleifen etc.
übergeben.
Die 3. Lichtschranke wird für die Fehler- Selektierung der beiden anderen LS benötigt.
Der FB hat in seinem Bauch den "Stellplätze frei"- Zähler, die Berechnung der Vorwarnung bzw. "Belegt" etc.
Ausgegeben werden "Rot" ( belegt ), "Gelb" (Vorwarnung ), "Grün" (frei ), die Schrankenvorwarnung, der Ausgang für
die Schranke (wenn alle Sensoren frei sind, der Schlüsselschalter "Not-Öffnen" nicht belegt etc. ), die Fehler "LS1 def.",
"LS2 def." bzw. "LS3 def." <-- die Kontroll- LS.
Das funktioniert auch alles so, wie es mir vorstelle.
Meine Frage war tatsächlich, ob ein FB noch multi ist, wenn ich in dem FB feste Adressen (M100.4 für Blinken ) verwende.
Mfg Mega_ohm, der sich für Deine ausführliche Erklärung zur Herangehensweise noch mal bedankt.
Parkhaus )
Für jedes Parkdeck wird der FB aufgerufen.
Dem FB werden die "max. Anzahl Stellplätze", "Vorwarnen bei Belegung in %", die Eingänge für die Induktionsschleifen
(bei mir müssen Lichtschranken reichen ) und eine Kontroll-Lichtschranke in der Mitte zwischen den beiden Schleifen etc.
übergeben.
Die 3. Lichtschranke wird für die Fehler- Selektierung der beiden anderen LS benötigt.
Der FB hat in seinem Bauch den "Stellplätze frei"- Zähler, die Berechnung der Vorwarnung bzw. "Belegt" etc.
Ausgegeben werden "Rot" ( belegt ), "Gelb" (Vorwarnung ), "Grün" (frei ), die Schrankenvorwarnung, der Ausgang für
die Schranke (wenn alle Sensoren frei sind, der Schlüsselschalter "Not-Öffnen" nicht belegt etc. ), die Fehler "LS1 def.",
"LS2 def." bzw. "LS3 def." <-- die Kontroll- LS.
Das funktioniert auch alles so, wie es mir vorstelle.
Meine Frage war tatsächlich, ob ein FB noch multi ist, wenn ich in dem FB feste Adressen (M100.4 für Blinken ) verwende.
Mfg Mega_ohm, der sich für Deine ausführliche Erklärung zur Herangehensweise noch mal bedankt.
- Beiträge
- 6.692
- Reaktionspunkte
- 1.687
Das hatte ich total missverstanden! Verknüpfen, also nur abfragen, das steht der MultiInstanzFähigkeit nicht im Wege.
Freue mich, dass Du so prima klar gekommen bist.
Hast mich neugierig gemacht mit "Die 3. Lichtschranke wird für die Fehler- Selektierung der beiden anderen LS benötigt."
Stelle mir vor, die 3. LS ist so angeordnet, dass wenn sie meldet, auch die beiden anderen melden müss(t)en - sonst liegt ein Fehler vor.
Gruss, Heinileini
Freue mich, dass Du so prima klar gekommen bist.
Hast mich neugierig gemacht mit "Die 3. Lichtschranke wird für die Fehler- Selektierung der beiden anderen LS benötigt."
Stelle mir vor, die 3. LS ist so angeordnet, dass wenn sie meldet, auch die beiden anderen melden müss(t)en - sonst liegt ein Fehler vor.
Gruss, Heinileini
Die 3. LS:
Die 3. LS ist mittig zwischen LS1 und LS2 angeordnet ... es muß also irgandwann ein Zustand eintreten,
bzw.
Das steht im "Bauch" des FB ... wird also pro "Parkdeck" geprüft ...
Hmmm... z.Zt. ärgere ich mich noch ein bisschen mit dem Schranken- Ausgang rum - Vorwarnung kommt, Taktmerker-
gesteuerte "Zeit" (eigentlich ist es ja ein Zähler ... ) ist erfüllt ... die Vorwarn- Blinkleuchte tut ... aber die Schranke redet nicht
mit mir.
Naja ... da ist ja schon viel Gutes bei. Den Rest finde ich morgen.
;.)
Mfg Mega_ohm
Code:
UN LS1
UN LS 2
U LS3
= #LS3_Err // Damit wird die 3 LS überwachtDie 3. LS ist mittig zwischen LS1 und LS2 angeordnet ... es muß also irgandwann ein Zustand eintreten,
Code:
U LS1
UN LS2
U FM_LS2 // neg. Flanke von LS2
UN LS3
=#LS1_Err
Code:
U LS2
UN LS1
U FM_LS1 // neg. Flanke von LS1
UN LS3
=#LS2_ErrDas steht im "Bauch" des FB ... wird also pro "Parkdeck" geprüft ...
Hmmm... z.Zt. ärgere ich mich noch ein bisschen mit dem Schranken- Ausgang rum - Vorwarnung kommt, Taktmerker-
gesteuerte "Zeit" (eigentlich ist es ja ein Zähler ... ) ist erfüllt ... die Vorwarn- Blinkleuchte tut ... aber die Schranke redet nicht
mit mir.
Naja ... da ist ja schon viel Gutes bei. Den Rest finde ich morgen.
;.)
Mfg Mega_ohm
Zuletzt bearbeitet:
holgermaik
Level-3
- Beiträge
- 1.433
- Reaktionspunkte
- 373
-> Hier kostenlos registrieren
technisch gesehen ja. aber nur innerhalb der CPU. Wir sind bestrebt FB so zu entwickeln, dass sie unabhängig vom Projekt benutzt werden können. Da der Taktmerker im nächsten Projekt evtl. ganz woanders liegt, wäre es meiner Meinung nach besser ihn zu übergeben als fest zu programmieren.
Holger
Ok... das ist natürlich ein Argument !
Ein FC oder FB wird ja hauptsächlich erstellt, weil man sich zukünftig viel Arbeit ersparen möchte.
Man hat sich einmal richtig mit einem Problem beschäftigt ... und kann zukünftig, sobald eine ähnliche Aufgabe
ansteht, diese Funktion verwenden.
Alles Klar ... dann übergebe ich eben den Taktmerker auch an den FB.
Mfg mega_ohm
Ein FC oder FB wird ja hauptsächlich erstellt, weil man sich zukünftig viel Arbeit ersparen möchte.
Man hat sich einmal richtig mit einem Problem beschäftigt ... und kann zukünftig, sobald eine ähnliche Aufgabe
ansteht, diese Funktion verwenden.
Alles Klar ... dann übergebe ich eben den Taktmerker auch an den FB.
Mfg mega_ohm
