Step 5 Lüfteranlage in der Fahrzeughalle

Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Heinileini,
Ich habe den neuen Code in meine Software-Simulation eingegeben, dabei fiel mir auf:
Beim Einschalten (Taster) und anstehender Anforderung (Luftsensor) kommt es vor,
dass zwei Lüfter zeitgleich eingeschaltet werden.
Im Betrieb (anstehender Anforderung) ist dann die Reihenfolge immer 1-3-2 ohne Zufall.
Gruß Dani
 
FB 1 oder PB1 geht. Kein OB oder andere Bausteine.
Den DB 1 scheint es auch noch zu geben, laut Doku. Danke für selbige, @SPS-Bitschubser !

Ich habe den neuen Code in meine Software-Simulation eingegeben, dabei fiel mir auf:
Beim Einschalten (Taster) und anstehender Anforderung (Luftsensor) kommt es vor,
dass zwei Lüfter zeitgleich eingeschaltet werden.
Das ist mir beim Simulieren der LOGO!-Variate noch nie passiert. Vielleicht war ich in der S5-Variante zu sparsam mit Befehlen. ;)
Im Betrieb (anstehender Anforderung) ist dann die Reihenfolge immer 1-3-2 ohne Zufall.
Für den Zufall bleibt ja auch nicht mehr viel Raum, nachdem nun auch dafür gesorgt ist, dass der zuletzt eingeschaltete Lüfter nicht mehr zur Auswahl steht. ;)

Werde mir beide Problemchen mal ansehen.

Hast Du beim Simulieren die Anforderung manuell angesteuert oder über einen TaktGeber?
 
Im Betrieb (anstehender Anforderung) ist dann die Reihenfolge immer 1-3-2 ohne Zufall.
Besser wird's, wenn die PausenZeit (geringfügig) kürzer als die AktivZeit gewählt wird.
Z.B. L KT 599.2 statt L KT 601.2

Habe jetzt ein weiteres Problem gefunden:
Wenn zwei MotorSchutzSchalter ausgefallen sind, wird gar kein Ausgang mehr angesteuert, da der einzig übrig gebliebene (dauerhaft!) verriegelt bleibt. Dieses Problem habe ich in der S5-Variante gelöst, aber noch nicht in der LOGO!-Variante (die Änderung ist zeitaufwändiger als bei "good old" S5).
 
Zuletzt bearbeitet:
Bin ich Falsch oder geht das in S5 gar nicht.
Ich kenne es nur so, dass in S5 einzelne Bytes nur einmal zugewiesen werden können. Also E0.0 - E0.7 -> A1.0-A1.7, aber nicht AB0 gleichzeitig mit EB0 etc.
nene das geht schon. Ausgänge bitweise ansteurern.

was byte- oder wortweise gehen könnte ist Steuerspannung wegschalten, meinst du das?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hast Du beim Simulieren die Anforderung manuell angesteuert oder über einen TaktGeber?
=> 1-Signal über Schalter, auch über längere Zeit (Dauerbetrieb mit Wechsel der Lüfter)

Besser wird's, wenn die PausenZeit (geringfügig) kürzer als die AktivZeit gewählt wird.
=> Ich habe die Zeiten für den Test etwas verkürzt 😊, aber Pausenzeit kürzer.

Habe jetzt ein weiteres Problem gefunden: Wenn zwei MotorSchutzSchalter ausgefallen sind...
=> Oh, ist mir noch nicht aufgefallen, da auch hier 1-Signal über Testschalter.
 
Besser wird's, wenn die PausenZeit (geringfügig) kürzer als die AktivZeit gewählt wird.
=> Ich habe die Zeiten für den Test etwas verkürzt 😊, aber Pausenzeit kürzer.
Und? Trotzdem keinerlei Zufälligkeit zu bemerken?

Kannst Du Dein QuellProgramm als TextDatei hochladen?
Bei S5 war es möglich die DruckAusgabe vom PG in eine (LST?) TextDatei "umzuleiten".
Ich unterstelle einfach mal, dass Du mit "meinen" symbolischen Namen in S5 nicht arbeiten kannst und Dir die Umsetzung immer wieder Arbeit macht, wenn ich geänderte Versionen hochlade?
 
nene das geht schon. Ausgänge bitweise ansteurern.

was byte- oder wortweise gehen könnte ist Steuerspannung wegschalten, meinst du das?
Nein, ich meinte die Hardware-Adressierung der einzelnen Karten.
Ich kenne es nur so, dass bei S5 z.B. je Steckplatz die Adressen eindeutig sind.
Bei 3 Stück 8-Kanal-Karten mit 2xDI und 1xDO -> E0.0-0.7 + E1.0-1.7 + A2.0-2.7

Was nicht geht, ist die spätere (S7) Standard-Variante mit z.B. als Hardware-Adressen E0.0-0.7 + A0.0-0.7 gleichzeitig.
Ich kenne allerdings auch nur S5 95U, 100U und 115U 941 bis 943B aus Instandhaltungssicht. An 135U hab ich nie gearbeitet, kenne ich nur vom sehen.
 
Kannst Du Dein QuellProgramm als TextDatei hochladen?
Gestaltet sich etwas schwierig, ich habe den Code aber sicher geprüft.
Mit den symbolischen Namen im Code komme ich gut zurecht, eine neue geänderte Version ist unproblematisch.

Und? Trotzdem keinerlei Zufälligkeit zu bemerken?
Es funktioniert solange am E_LüfAnf ein Wischersignal ankommt, auch mit zufälligen A_Lüf_1-3.
Ein Wischer während des Betriebs eines Lüfters wird allerdings ignoriert.
Gibt der Sensor (E_LüfAnf) ein dauerhaftes 1 Signal, ist die Reihenfolge der Ausgänge immer gleich …
 
Mit den symbolischen Namen im Code komme ich gut zurecht, eine neue geänderte Version ist unproblematisch.
(y)
Es funktioniert solange am E_LüfAnf ein Wischersignal ankommt, auch mit zufälligen A_Lüf_1-3.
(y)
Ein Wischer während des Betriebs eines Lüfters wird allerdings ignoriert.
❓... (y) Soll das denn nicht so sein? Welche Reaktion wird erwartet?
Sind wir hier schon beim Thema der angedeuteten ProgrammErweiterung, bei der auch 2 Lüfter gleichzeitig in Betrieb sein können/sollen?
Gibt der Sensor (E_LüfAnf) ein dauerhaftes 1 Signal, ist die Reihenfolge der Ausgänge immer gleich …
❓... (y) Angeblich tritt ja dieser Fall in der Praxis kaum bis nie auf. Besteht hier noch HandlungsBedarf?
Beim Einschalten (Taster) und anstehender Anforderung (Luftsensor) kommt es vor,
dass zwei Lüfter zeitgleich eingeschaltet werden.
❓Habe zu diesem Phänomen noch keine Ursache geschweige denn Lösung finden können.
Ich kann nicht nachvollziehen, wie das passieren soll.
Programmtechnisch macht es ja keinen Unterschied, ob ...
- eine LüfterAnforderung bereits ansteht, wenn eingeschaltet wird oder
- eine LüfterAnforderung kommt, wenn bereits eingeschaltet ist.
Besteht das Problem denn weiterhin? Evtl. nur in der Simulation?

Was gibt's Neues zum Thema Absturz der CPU?

Hier noch die Änderung/Erweiterung wegen des Deadlocks bei 2 ausgeflippten MotorSchutzSchaltern:
Code:
// "ZufallsGenerator": nacheinander 1 aus 3 Bits = TRUE
      U   M_Zuf_2                                       
      =   M_Zuf_3                                       
                                                        
      U   M_Zuf_1                                       
      R   M_Zuf_1                                       
      =   M_Zuf_2

      UN  M_Zuf_2
      UN  M_Zuf_3
      =   M_Zuf_1

// mit pos. Flanke von Eingang Ein/Aus den Ein/Aus-Status umknippsen     
      ON  E_EinAus
      O   M_EinAus
      SPB SKIP
      UN  M_EIN
      =   M_EIN
SKIP: U   E_EinAus
      =   M_EinAus

// ggfs Aktiv-Timer 1..3 starten [10 min] bzw. rücksetzen
      L   KT 600.2

      U   M_Anf
      U   M_Zuf_1
      UN  M_Lst_1
      UN  T_Pse_1
      SA  T_Akt_1

      ON  E_MSS_1
      ON  M_EIN
      R   T_Akt_1
      
      U   M_Anf
      U   M_Zuf_2
      UN  M_Lst_2
      UN  T_Pse_2
      SA  T_Akt_2

      ON  E_MSS_2
      ON  M_EIN
      R   T_Akt_2
      
      U   M_Anf
      U   M_Zuf_3
      UN  M_Lst_3
      UN  T_Pse_3
      SA  T_Akt_3

      ON  E_MSS_3
      ON  M_EIN
      R   T_Akt_3

// ggfs Pause-Timer 1...3 starten [9 min 59 s]
      L   KT 599.2  // geändert
      
      U   T_Akt_1
      =   M_Lüf_1
      SA  T_Pse_1
      
      U   T_Akt_2
      =   M_Lüf_2
      SA  T_Pse_2
      
      U   T_Akt_3
      =   M_Lüf_3
      SA  T_Pse_3
      
// wenn Eingang LüfterAnforderung ansteht und kein Lüfter aktiv ist ...
      UN  M_Lüf_1
      UN  M_Lüf_2
      UN  M_Lüf_3
      U   E_LüfAnf
      =   M_Anf

// merken, welcher Lüfter zuletzt aktiv war
      U   M_Lüf_1
      UN  A_Lüf_1  // mit pos. Flanke von Lüfter-1 Ein
      S   M_Lst_1  // den Merker zuletzt-aktiver-Lüfter setzen
      R   M_Lst_2  // und die beiden anderen rücksetzen
      R   M_Lst_3

      U   M_Lüf_2
      UN  A_Lüf_2
      S   M_Lst_2
      R   M_Lst_1
      R   M_Lst_3

      U   M_Lüf_3
      UN  A_Lüf_3
      S   M_Lst_3
      R   M_Lst_1
      R   M_Lst_2
      
// Merker zuletzt-aktiver-Lüfter löschen, wenn 2 von 3 MSS Aus sind
      UN  E_MSS_2  // hinzu
      UN  E_MSS_3  // hinzu
      R   M_Lst_1  // hinzu
      
      UN  E_MSS_1  // hinzu
      UN  E_MSS_3  // hinzu
      R   M_Lst_2  // hinzu
      
      UN  E_MSS_1  // hinzu
      UN  E_MSS_2  // hinzu
      R   M_Lst_3  // hinzu

// Merker LüfterAktiv auf Ausgänge umsetzen
      U   M_Lüf_1
      =   A_Lüf_1

      U   M_Lüf_2
      =   A_Lüf_2

      U   M_Lüf_3
      =   A_Lüf_3
Der verbliebene Lüfter wird dann aktiviert, hält aber seine PausenZeiten trotzdem eisern ein. ;)

Häwenaissuiikend!

Gruss, Heinileini
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Grundsätzlich ist damit mein Problem gelöst, super!
Alle jetzt eingebauten Codes, sind schon Extras ...
In der Simulation läuft das Programm schon echt gut!

Soll das denn nicht so sein? Welche Reaktion wird erwartet?
Nett wäre bei dauerhaften 1-Signal des Sensors ein umschalten auf den nächsten zufällig ausgewählten Lüfter.
Bei Impuls des Sensors, sollte der Ablauf so beibleiben ...

Angeblich tritt ja dieser Fall in der Praxis kaum bis nie auf. Besteht hier noch HandlungsBedarf?
Richtig, wäre nützliches Extra das die Anlage noch verbessern würde ...

Besteht das Problem denn weiterhin? Evtl. nur in der Simulation?
War event. eine Zeitüberschreitung, werde ich im Auge behalten.

Was gibt's Neues zum Thema Absturz der CPU?
Leider immer noch, ich muss den Fehler noch suchen.
Befehl nicht interpretierbar, Bausteinfehler: SA T 1 ein Zeitproblem?

Die Änderung/Erweiterung wegen des Deadlocks bei 2 ausgeflippten MotorSchutzSchaltern
Habe ich eingefügt, danke …
 
Grundsätzlich ist damit mein Problem gelöst, super!
Alle jetzt eingebauten Codes, sind schon Extras ...
In der Simulation läuft das Programm schon echt gut!

Soll das denn nicht so sein? Welche Reaktion wird erwartet?
Nett wäre bei dauerhaften 1-Signal des Sensors ein umschalten auf den nächsten zufällig ausgewählten Lüfter.
Bei Impuls des Sensors, sollte der Ablauf so beibleiben ...
Wie wäre es damit: bau jedem Lüfter einen Betriebsstundenzähler ein und schalte nicht zufällig den nächsten ein sondern den mit den wenigsten Betriebsstunden.
 
Soll das denn nicht so sein? Welche Reaktion wird erwartet?
Nett wäre bei dauerhaften 1-Signal des Sensors ein umschalten auf den nächsten zufällig ausgewählten Lüfter.
Bei Impuls des Sensors, sollte der Ablauf so beibleiben ...
Das hatte ich schon befürchtet! ;) Man sollte doch im Auge bzw. Hinterkopf behalten, welche Änderungs- bzw. Erweiterungs-Wünsche absehbar sind ...
Wenn zwei Lüfter laufen dürfen, dann benötigen wir zusätzlich zur Information, welcher der letzte war, noch die Info, welcher der vorletzte war!?
Das Konzept, hier irgendetwas dem Zufall abringen zu wollen, wird immer aussichstloser!

Angeblich tritt ja dieser Fall in der Praxis kaum bis nie auf. Besteht hier noch HandlungsBedarf?
Richtig, wäre nützliches Extra das die Anlage noch verbessern würde ...
In meiner LOGO!-Simulation ist noch der Zufall zu spüren. Allerdings nur, wenn - wie bereits gesagt - die Pausenzeit kürzer als die Aktivzeit gewählt wird. Macht man die Pausenzeit länger als Aktivzeit, kann sich der Zufall nicht mehr austoben.

Was gibt's Neues zum Thema Absturz der CPU?
Leider immer noch, ich muss den Fehler noch suchen.
Befehl nicht interpretierbar, Bausteinfehler: SA T 1 ein Zeitproblem?
Zähler verwendest Du doch nicht? Wird doch wohl kein "DB1-Problem" sein?
T 0 .. T 15 sind zulässig.

Kannst Du statt Deines QuellCodes vielleicht mal eine ZuordnungsListe posten?
D.h. etwas, woraus man entnehmen kann, welche E, A, M, T Du für welche symbolischen Namen verwendest?

Wie wäre es damit: bau jedem Lüfter einen Betriebsstundenzähler ein und schalte nicht zufällig den nächsten ein sondern den mit den wenigsten Betriebsstunden.
Darauf wurde anfangs schon verwiesen, aber der Zufall ist doch das Salz dieses Threads in der Suppe der bereits in anderen Threads durchgekauten LösungsAlternativen. ;)
Aber ein Umschwenken dieses Threads in Richtung BetriebsstundenZähler (oder andere Prioritäten) und Verzicht auf Zufälligkeit ist ja ohnehin durch die angestrebte Erweiterung schon in Sichtweite gerückt.
Die 101U "kann" Zähler, Addition und Vergleiche. Ob das aber wirklich ausreicht für ein sinnvolles Umstellen der Strategie?
Laut BetriebsAnleitung: "Es (das AG 101U) wurde als Kompaktgerät für kleinere Steuerungsaufgaben konzipiert und stellt eine "wirtschaftliche Alternative" zu bisher verwendeten Relais- und Schützsteuerungen ... dar. ..."
Vielleicht erstmal die ZufallsStrategie noch etwas verfeinern, um ggfs danach erst eine Neuauflage mit der BetriebsstundenStrategie zu versuchen?
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Ausgänge
A 0.6​
A_Lüf_1 MotorSchütz Lüfter-1
A 1.0​
A_Lüf_2 MotorSchütz Lüfter-2
A 1.2​
A_Lüf_3 MotorSchütz Lüfter-3
Eingänge
E 0.2​
E_EinAus Taster (S) Anlage EIN/AUS
E 0.4​
E_LüfAnf Sensor LüfterAnforderung
E 0.6​
E_MSS_1 MotorSchutzSchalter Lüfter-1
E 1.0​
E_MSS_2 MotorSchutzSchalter Lüfter-2
E 1.2​
E_MSS_3 MotorSchutzSchalter Lüfter-3
Merker
M 0.2​
M_EIN Anlage eingeschaltet
M 0.3​
M_Anf LüfterAnforderung
M 0.4​
M_EinAus FlankenMerker Eingang Ein/Aus
M 10.1​
M_Lüf_1 Merker Lüfter-1 aktiv
M 10.2​
M_Lüf_2 Merker Lüfter-2 aktiv
M 10.3​
M_Lüf_3 Merker Lüfter-3 aktiv
M 11.1​
M_Zuf_1 Merker zufällige Aktivierung Lüfter-1
M 11.2​
M_Zuf_2 Merker zufällige Aktivierung Lüfter-2
M 11.3​
M_Zuf_3 Merker zufällige Aktivierung Lüfter-3
M 12.1​
M_Lst_1 Merker Lüfter-1 war zuletzt aktiv
M 12.2​
M_Lst_2 Merker Lüfter-2 war zuletzt aktiv
M 12.3​
M_Lst_3 Merker Lüfter-3 war zuletzt aktiv
Timer
T 1​
T_Akt_1 Timer Lüfter-1 aktiv
T 2​
T_Pse_1 Timer Lüfter-1 Pause
T 3​
T_Akt_2 Timer Lüfter-2 aktiv
T 4​
T_Pse_2 Timer Lüfter-2 Pause
T 5​
T_Akt_3 Timer Lüfter-3 aktiv
T 6​
T_Pse_3 Timer Lüfter-3 Pause
Keine Zähler !
 
Zuletzt bearbeitet:
Wie wäre es damit: bau jedem Lüfter einen Betriebsstundenzähler ein und schalte nicht zufällig den nächsten ein sondern den mit den wenigsten Betriebsstunden.
Mit "echtem" Zufall sollte keine Vergleichmäßigung mehr notwendig sein, weil der Wahrscheinlichkeit nach jeder gleich oft an der Reihe ist. Außer die externe Anforderung kommt auch nicht einigermaßen gleichmäßig. Vielleicht war das ja die Idee hinter dem "zufällig" ;-)
 
Mit "echtem" Zufall sollte keine Vergleichmäßigung mehr notwendig sein, weil der Wahrscheinlichkeit nach jeder gleich oft an der Reihe ist. Außer die externe Anforderung kommt auch nicht einigermaßen gleichmäßig. Vielleicht war das ja die Idee hinter dem "zufällig" ;-)
Mag sein - aber dann ist der Zufall eher eine Krücke zur Lösung. Und wenn wir ehrlich sind, können wir keine echt zufälligen Ereignisse hervorrufen. Wir können es nur so aussehen lassen wie Zufall in dem wir den Algorithmus oder die Variablen verschleiern, so dass es für den Betrachter so aussieht wie Zufall.
Es könnte auch zufällig immer Lüfter 1 angehen ;)
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Wenn verfügbar, könnte man z. B. mit einem freien Analogeingang mit einer passenden Beschaltung Rauschen einfangen, und vom Eingangswort immer das letzte Bit verwenden um das in einen "Zufalls-Pool" zu schieben. Ich meine bei Linux wird das auch so in der Art gemacht, da gehen noch ein paar mehr Dinge mit ein. Wenn der "echte" Zufalls-Pool leer ist, gibt es nur noch Pseudo-Zufall. Wobei das hier auch ausreichend wäre.
 
Leider hat mich die Zuordnungsliste kein Stück weiter gebracht.
Habe nochmals die Betriebs- und die ProgrammierAnleitung der 101U durchgesehen, konnte aber nichts verdächtiges entdecken.
Es sollte alles im grünen Bereich sein.

Zu "Befehl nicht interpretierbar, Bausteinfehler: SA T 1 ein Zeitproblem?":
Bei SA T 1 vermute ich kein Problem.
Aber vielleicht bei
SPB SKIP und bei
SKIP: U E_EinAus.
In S5 muss man stattdessen SPB =SKIP schreiben. Und der Doppelpunkt hinter der SprungMarke wird nicht mit eingetippt, sondern in jeder Zeile automatisch angezeigt. Ich hoffe, dass ich jetzt nicht Unsinn geredet habe - S5 war für mich irgendwann im letzten JahrTausend.
Andererseits: Simulation und PG sollten sich eigentlich gleich verhalten - warum meckert nur die CPU? Womit simulierst Du?

... gibt es nur noch Pseudo-Zufall. Wobei das hier auch ausreichend wäre.
Eben. Allemal. In diesem Thread haben wir nicht einmal einen PseudoZufallsGenerator, sondern der Zufall ergibt ausschliesslich aus dem ZeitPunkt, zu dem versucht wird, einen Lüfter "zufällig" auszuwählen. Und der Zufall wird auch ständig in seinen AuswahlMöglichkeiten eingeschränkt durch die Forderung, den zuletzt aktiven Lüfter erstmal nicht wieder zu wählen und durch die Forderung, der Einhaltung der PausenZeiten den Vorrang zu geben. Das kann dazu führen, dass der Zufall im ExtremFall nur ein einzigen Lüfter zur Auswahl hat.
Na und? Selbst wenn die Reihenfolge deshalb "einfriert", in der die Lüfter aktiviert werden, kommt jeder der drei Lüfter mal dran und kann anschliessend seine PausenZeit geniessen. ;)
 
Zuletzt bearbeitet:
Ich bin im übrigen in meinen Programmen von diesem pauschalen Betriebsstundenausgleich wieder weggegangen. Der Nachteil ist nämlich dabei, dass wenn ein Antrieb mal längere Defekt ist, dieser nach Wiederinbetriebnahme damit versucht seine Zeit wieder aufzuholen, und demensprechend ggf. andere Antriebe lange ausgeschaltet sind. Außerdem sind damit eben auch mehrere Antriebe immer gleichzeitig zur Wartung fällig. Wenn du Antrieb hast wo die Wartung mehrere Tage oder Wochen dauert, muss man das auch beachten.
 
Zurück
Oben