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?
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
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.
Hört sich gut an. Nimm statt des Potis einen Encoder, da ist die Auflösung höher.
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
>> 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.
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.
>> 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
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?
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.
Dann versuche ich jetzt mal eine Zusammenfassung in Form eines Pseudocodes (für den Handbetrieb):
1 | Interrupt für OeffnenTimerAlarm: |
2 | if(Motor>1 && !Offen) |
3 | {
|
4 | Motor=0; // Motor abstellen |
5 | AlarmUndNotAus(); |
6 | }
|
7 | ---------------------------------------------
|
8 | Interrupt für OeffnenTimer: |
9 | if(Motor>1 && !Offen) |
10 | {
|
11 | Motor=0; // Motor abstellen |
12 | Fehler(); |
13 | }
|
14 | ---------------------------------------------
|
15 | while(1) |
16 | {
|
17 | switch(Befehl) // Befehle kommen vom Benutzer |
18 | {
|
19 | case 1: |
20 | // SchlieszenBefehl:
|
21 | if(Motor==0) |
22 | if(Motorueberstrom) |
23 | Fehler(); |
24 | else if |
25 | (
|
26 | !Schlieszkantenueberwachung && |
27 | !Lichtschranken && |
28 | !Bewegungssensor && |
29 | !Geschlossen |
30 | )
|
31 | Motor=1; // Schließen |
32 | break; |
33 | case 2: |
34 | // OeffnenBefehl (mit Überstrom-Überwachung):
|
35 | if(Motor<2) |
36 | if(Motorueberstrom) |
37 | Fehler(); |
38 | else if(!Offen) |
39 | Motor=3; // Tür auf jeden Fall öffnen |
40 | break; |
41 | }
|
42 | ---------------------------------------------
|
43 | switch(Motor) |
44 | {
|
45 | case 1: |
46 | // SchlieszenVorgang:
|
47 | if
|
48 | (
|
49 | Schlieszkantenueberwachung || |
50 | Lichtschranken || |
51 | Motorueberstrom
|
52 | )
|
53 | {
|
54 | Motor=2; // Tür auf jeden Fall öffnen |
55 | OeffnenTimerAlarm(); // 5-Sekunden-Timer |
56 | }
|
57 | else if(Bewegungssensor==1) |
58 | {
|
59 | Motor=3; // Tür auf jeden Fall öffnen |
60 | OeffnenTimer(); // 5-Sekunden-Timer |
61 | }
|
62 | else if(Geschlossen) |
63 | Motor=0; // Motor abstellen |
64 | break; |
65 | case 2: |
66 | // Öffnenvorgang ohne Überstrom-Kontrolle:
|
67 | // Sollte jemand absichtlich die Tür beim Schließen und
|
68 | // Öffnen halten, hätte der Motor für 5 s Überstrom.
|
69 | if(Offen) |
70 | Motor=0; // Motor abstellen |
71 | break; |
72 | case 3: |
73 | // Öffnenvorgang mit Überstrom-Kontrolle:
|
74 | // Im Normalfall wird versucht, den Motor zu schon und
|
75 | // auf Überstrom zu kontrollieren.
|
76 | if(Motorueberstrom) |
77 | {
|
78 | Motor=0; // Motor abstellen |
79 | Fehler(); |
80 | }
|
81 | else if(Offen) |
82 | Motor=0; // Motor abstellen |
83 | break; |
84 | }
|
85 | }
|
Das ist jetzt hoffentlich wirklich eine babysichere Tür.
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
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
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.
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
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.