Schiebetür Steuerung

[Heinz B. (hez)]

hello,

ich will auf einem uC eine kleine Steuerung für eine Schiebetür 
simulieren.

Folgende Features habe ich mir ausgedacht:

1 Motor für auf/zu
1 Schließkantenüberwachung (kürze ich mal SKÜ ab)
2 Lichtschranken (melden, ob sich wer direkt in der Tür befindet)
2 Bewegungssensor (melden, ob sich wer vor der Tür befindet)
1 Drehpoti, der mir die aktuelle Stellung der Tür rückmeldet
2 Endschalter (offen/geschlossen)

Die Tür soll man in 2 Modi betreiben können:

- nur per Steuerung auf/zu
- automatisch auf/zu

Sicherheitsfeatures:

1) Ein Schließbefehl wird nur akzeptiert, wenn:
- SKÜ==0 && (niemand drückt die Tür auf)
- Lichtschranken==0 && (es steht niemand in der Tür)
- Bewegungssensoren==0 && (es steht niemand vor der Tür)
- Endschalter "geschlossen"==0 (nicht geschlossen)

2) Angenommen, es tritt beim Schließvorgang einer der folgenden Fälle 
ein:
- SKÜ==1 ||
- Lichtschranken==1 ||
- Drehpoti meldet, dass sich die Tür öffnet (jemand drückt gegen die 
Tür)
Dann muss die Tür öffnen. Bewegt sich die Tür dann nicht innerhalb von 
1/10 Sekunde wieder auf, wird das ganze System abgeschalten (Motor aus) 
und ein Alarm angezeigt.

3) Angenommen, es tritt beim Schließvorgang folgender Fall ein:
- SKÜ==0 &&
- Lichtschranken==0 &&
- Bewegungssensoren==1
Dann muss die Tür öffnen.

4) Angenommen, der Drehpoti meldet innerhalb von 1/2 Sekunde nicht jene 
Bewegungsrichtung, die die Tür aufgrund eines Öffnen- oder 
Schließen-Befehls haben sollte, wird das als Fehler angezeigt.

Ist das OK? Was würdet ihr sagen?

[Paul Baumann (Gast)]

Ich würde das Potentiometer weglassen. (Wilde Mechanik, um den Weg der
Tür auf 270 Grad Drehwinkel zu bringen, Potentiometer geht beizeiten
mechanisch zum Teufel)

Werte den Motorstrom aus, um zu sehen, wann sie schwer geht, d.h. wenn
jemand dazwischen klemmt.

MfG Paul

[Karl H. (kbuchegg)]

Das was du da hast, klingt wie die Beschreibung in einem Werbeprospekt. 
UM es als Vorlage für die Programmierung nutzen zu können würde ich das 
umformulieren:

In welchem Zustand kann die Tür sein?
Welche Ereignisse können in jedem Zustand auftreten?
Was soll dann als Reaktion auf das Ereignis passieren und geht die
Tür daraufhin möglicherweise in einen anderen Zustand über.

Die Bewegungsüberwachung würde ich aus der Zustandsbeschreibung 
rausnehmen und eine Ebene tiefer legen. Die Zustandsbeschreibung geht 
davon aus, dass wenn die Tür im Zutand 'sich schliessend' ist, die Tür 
dies auch tatsächlich tut. Schlägt die Überwachung an, ist das für den 
Zustandautomaten ein Ereignis, so wie es auch 'Kommando schliessen 
erhalten' ist.

So eine Zustandsbeschreibung hat den Vorteil, dass man sié auch 
wunderbar graphisch symbolisieren kann: Die Zustände sind Kreise, 
Ereignisse sind Pfeile die aus einem Kreis herausführen und bei denen 
der Name des Ereignisses steht und auch welche Aktion dann gemacht wird. 
Der Pfeil führt wieder zu einem Kreis (kann auch derselbe Kreis sein, 
aus dem er heraus gekommen ist)

Btw: Ich denke 0.5 Sekunden sind optimistisch. Eine reale Tür wirst du 
nicht innerhalb dieser Zeit abbremsen und in Gegenrichtung beschleunigen 
können.

[Stephan (Gast)]

Hört sich gut an. Nimm statt des Potis einen Encoder, da ist die 
Auflösung höher.

[Volker S. (volkerschulz)]

Stephan schrieb:
> Hört sich gut an. Nimm statt des Potis einen Encoder, da ist die
> Auflösung höher.

?!? Das musst Du mir mal erklaeren!

Volker

[Heinz B. (hez)]

>> Wilde Mechanik, um den Weg der
>> Tür auf 270 Grad Drehwinkel zu bringen
Ich will eine Schiebetür simulieren.

>> Werte den Motorstrom aus
Nicht schlecht, die Idee. Ist der Strom, der durch den Motor fließt zu 
hoch, geht womöglich die Tür nicht auf oder zu.

>> Zustandsbeschreibung
Ist sicher ein guter Tip für eine Doku.

>> Ich denke 0.5 Sekunden sind optimistisch.
Keine Ahnung, wie schnell so etwas wirklich gehen kann. Aber das soll 
hier egal sein. Es soll nur mal ums Prinzip gehen. Könnten dann auch die 
doppelten Zeiten sein.

[Karl H. (kbuchegg)]

Heinz B. schrieb:
>>> Wilde Mechanik, um den Weg der
>>> Tür auf 270 Grad Drehwinkel zu bringen
> Ich will eine Schiebetür simulieren.

Er meint die 270 Grad am Poti
Poti haben oft die unangenehme Eigenschaft, nicht um 360 Grad gedreht 
werden zu können.
Also entweder Spindelpoti benutzen oder aber besser den Motorstrom 
überwachen.

>>> Werte den Motorstrom aus
> Nicht schlecht, die Idee. Ist der Strom, der durch den Motor fließt zu
> hoch, geht womöglich die Tür nicht auf oder zu.

Dafür funktioniert die Sicherung auch dann, wenn das blockierende Objekt 
nicht die Lichtschranke auslöst. zb ein Karton, der am Boden steht oder 
'Gott bewahre' ein blockierendes Getriebe.

[Paul Baumann (Gast)]

>Er meint die 270 Grad am Poti
Ja, meint er. ;-)

MfG Paul

[Heinz B. (hez)]

>> Ja, meint er. ;-)
Da meinte er etwas ganz sinnvolles, was ich noch nicht wusste :)

Sollte ich beim Poti vielleicht auch noch irgendwie Grenzwerte 
definieren?
Z. B.
Wenn <10 => 10
Wenn >240 => 245
Bei möglichen Werten von 0 bis 255

[Karl H. (kbuchegg)]

Heinz B. schrieb:
>>> Ja, meint er. ;-)
> Da meinte er etwas ganz sinnvolles, was ich noch nicht wusste :)
>
> Sollte ich beim Poti vielleicht auch noch irgendwie Grenzwerte
> definieren?
> Z. B.
> Wenn <10 => 10
> Wenn >240 => 245
> Bei möglichen Werten von 0 bis 255

Das ist nicht wirklich sinnvoll.
Vor allen Dingen deshalb nicht, weil der Wert, den dein Programm zu 
Gesicht bekommt, im wesentlichen nicht vom Poti abhängt, sondern davon, 
wie du die Bewegung überträgst, die ADC Werte weiterverarbeitest und 
welche Auflösung deine ADC überhaupt hat.
Ja nachdem, wie die Mechanik aussieht, die die Bewegung aufs Poti 
überträgt, kriegst du andere Messwerte.

An deiner Stelle würde ich mir wirklich überlegen, ob ich das Poti nicht 
weglassen würde. Wenn du schon nicht den Motorstrom überwachen willst, 
was ich ehrlich gesagt überhaupt nicht verstehe, weil es die 
vernünftigste und universellste Überwachung schlechthin ist, könnte man 
auch überlegen ob man nicht sagt: Die Tür braucht zum Schliessen 5 
Sekunden. Wenn daher nach 5 Sekunden der Endschalter nicht anspricht, 
dann ist die Tür blockiert.

Noch was ist mir eingefallen:
Hast du den Fall bedacht, dass jemand die Tür absichtlich 'absperren' 
möchte?

[Heinz B. (hez)]

Da fällt mir noch eine zusätzliche Kontrollmöglichkeit ein:
Bekomme ich nach einem Schließen-Befehl nicht innerhalb von 10 Sekunden 
eine "geschlossen"-Rückmeldung, öffne ich die Tür wieder.
EDIT:
>> Wenn daher nach 5 Sekunden der Endschalter nicht anspricht,
>> dann ist die Tür blockiert.
oops ... da hatten wir die gleiche Idee zur gleichen Zeit :)

>> Wenn du schon nicht den Motorstrom überwachen willst
Doch, doch! Finde ich eine gute Idee!

>> Hast du den Fall bedacht, dass jemand die Tür absichtlich 'absperren'
>> möchte?
Ja, darum die von mir erwähnten 2 Modi.

[Heinz B. (hez)]

Dann versuche ich jetzt mal eine Zusammenfassung in Form eines 
Pseudocodes (für den Handbetrieb):

Interrupt für OeffnenTimerAlarm:
if(Motor>1 && !Offen)
{
   Motor=0; // Motor abstellen
   AlarmUndNotAus();
}
---------------------------------------------
Interrupt für OeffnenTimer:
if(Motor>1 && !Offen)
{
   Motor=0; // Motor abstellen
   Fehler();
}
---------------------------------------------
while(1)
{
   switch(Befehl) // Befehle kommen vom Benutzer
   {
      case 1:
         // SchlieszenBefehl:
         if(Motor==0)
            if(Motorueberstrom)
               Fehler();
            else if
            (
               !Schlieszkantenueberwachung &&
               !Lichtschranken &&
               !Bewegungssensor &&
               !Geschlossen
            )
               Motor=1; // Schließen
         break;
      case 2:
         // OeffnenBefehl (mit Überstrom-Überwachung):
         if(Motor<2)
            if(Motorueberstrom)
               Fehler();
            else if(!Offen)
               Motor=3; // Tür auf jeden Fall öffnen
         break;
   }
   ---------------------------------------------
   switch(Motor)
   {
      case 1:
         // SchlieszenVorgang:
         if
         (  
            Schlieszkantenueberwachung ||
            Lichtschranken ||
            Motorueberstrom
         )
         {  
            Motor=2;             // Tür auf jeden Fall öffnen
            OeffnenTimerAlarm(); // 5-Sekunden-Timer
         }
         else if(Bewegungssensor==1)
         {  
            Motor=3;        // Tür auf jeden Fall öffnen
            OeffnenTimer(); // 5-Sekunden-Timer
         }
         else if(Geschlossen)
            Motor=0; // Motor abstellen
         break;
      case 2:
         // Öffnenvorgang ohne Überstrom-Kontrolle:
         // Sollte jemand absichtlich die Tür beim Schließen und
         // Öffnen halten, hätte der Motor für 5 s Überstrom.
         if(Offen)
            Motor=0; // Motor abstellen
         break;
      case 3:
         // Öffnenvorgang mit Überstrom-Kontrolle:
         // Im Normalfall wird versucht, den Motor zu schon und
         // auf Überstrom zu kontrollieren.
         if(Motorueberstrom)  
         {
            Motor=0; // Motor abstellen
            Fehler();
         }
         else if(Offen)
            Motor=0; // Motor abstellen
         break;
   }
}

Das ist jetzt hoffentlich wirklich eine babysichere Tür.

[Andreas F. (aferber)]

Heinz B. schrieb:
> Das ist jetzt hoffentlich wirklich eine babysichere Tür.

Nein. Was z.B. völlig fehlt ist die Überwachung der 
Sicherheitseinrichtungen auf Funktionsfähigkeit (also z.B. den 
Motorstrom nicht nur auf "zuviel" überwachen, sondern auch auf 
"zuwenig", für den Fall, dass die Messeinrichtung ausfällt). Auch den 
Hardware-Watchdog nicht vergessen, der die Tür stillegt, wenn der 
Controller ausfallen sollte oder komische Sachen macht.

Weitere Dinge sind zu beachten, wenn sich die Tür in einem Fluchtweg 
befinden sollte, z.B. muss sie automatisch öffnen, wenn der 
Bewegungssensor in Fluchtrichtung ausfallen sollte.

Eine Zusammenstellung von Vorschriften dazu findet sich z.B. hier (keine 
Ahnung wie aktuell das ist, ich baue solche Teile nicht ;-):

http://www.baubeschlag-sued.de/home/hauptseite/Service/Vorschriften.pdf

Andreas

[Andreas F. (aferber)]

Ergänzend noch:

- Je nach Konstruktion der Tür kann auch beim Öffnen der Tür eine
  Gefährdung entstehen (Einzugsgefahr zwischen Tür und Rahmen).
  Eine Brachialöffnung wie in deinem State "2" ist da dann eher
  kontraproduktiv.

- 5 Sekunden als Grenze erscheint mir ziemlich hoch gegriffen, es sei
  denn, es handelt sich um eine wirklich grosse Tür. Wenn handels-
  übliche Schiebetüren (z.B. Kaufhaustüren) so lange brauchen würden,
  gäbe es wohl eine Menge gebrochener Nasen ;-)

Andreas

[Stephan (Gast)]

Ein Poti hat 270° zur Verfügung und ein gewisses Spiel, wenn es 
zurückgedreht wird. Einen Encoder (=Drehimpulsgeber) kann man 1x oder 
20x oder 100x um 360° drehen ohne grosses Spiel.

[Volker S. (volkerschulz)]

Stephan schrieb:
> Hört sich gut an. Nimm statt des Potis einen Encoder, da ist die
> Auflösung höher.

Volker Schulz schrieb:
>?!? Das musst Du mir mal erklaeren!

Stephan schrieb:
> Ein Poti hat 270° zur Verfügung und ein gewisses Spiel, wenn es
> zurückgedreht wird. Einen Encoder (=Drehimpulsgeber) kann man 1x oder
> 20x oder 100x um 360° drehen ohne grosses Spiel.

1.) Es gibt durchaus Potis, die mehr als 270° "zur Verfuegung" haben.

2.) Selbst bei einem 100x-Encoder waere das "Spiel", naemlich der weg 
zwischen zwei Tastungen, 3.6°. Ich kenne kein Poti das so viel Spiel 
hat, und ich habe durchaus schon welche aus dem Segment der einstelligen 
Cent-Betraege benutzt.

3.) Schriebst Du "Aufloesung" und diese ist bei einem analogen Poti 
theoretisch unendlich hoch und praktisch immernoch der eines Encoders 
haushoch ueberlegen und in diesem speziellen Falle nur durch die 
Aufloesung des ADC begrenzt.

4.) Kostet ein Encoder, der hier schlechtere Ergebnisse liefern wuerde, 
ein hundertfaches eines Potis.

Volker