Hallo, ich möchte einen Rolloaktor bauen, der über mein eigenes Busprotokoll angesteuert wird und die Position der Rollläden sowie auch den Winkel der Raffstores intern verwalten kann, also nicht auf (unmögliche) exakte Timings der Ansteuerung über einen Bus (ohne Kollisionsverhinderung) und von einem Linux-Controller angewiesen ist. Meines Wissens nach gibt es sowas noch nicht. Das wird aber nur ein privates Projekt, der ganze Zertifizierungskram für CE und WEEE ist mir zu viel. Die grundsätzliche Schaltung mit einem Schließer- und einem dahinter geschalteten Wechsler-Relais ist mir bekannt. Den Rest macht dann die Firmware. Soweit funktioniert das also im Sunshine-Case. Damit wird zumindest verhindert, dass beide Leitungen des Motors gleichzeitig bestromt werden. Daneben möchte ich folgende Fälle aus der Kategorie „Safety“ berücksichtigen: 1. Die minimale Umschaltzeit der Richtungen soll eingehalten werden. Das macht die Firmware. 2. Beim Ausfall des Mikrocontrollers (alle GPIOs sofort auf Low) soll verhindert werden, dass das Wechsel-Relais vor dem Freigabe-Relais ausschaltet, was zu einer Unterschreitung der Umschaltzeit führen würde, und danach gleich wieder zur Abschaltung. Relais haben Toleranzen, das kann also passieren. 3. Beim Ausfall der Versorgungsspannung des Geräts soll das ebenfalls verhindert werden. Zur Abschaltverzögerung findet man regelmäßig Schaltungen mit einem Kondensator, oft vor dem Schalttransistor. Das wäre aber nur für Bedingung 2 ausreichend. Um auch Bedingung 3 zu erfüllen, müsste der Kondensator wohl hinter dem Transistor hängen, also direkt am Relais. Die Verzögerung soll mindestens so lang sein, wie die beiden Relais sich in ihrer Abschaltverzögerung und -dauer unterscheiden (Toleranzen), aber höchstens 100 ms, damit ein zügiger Richtungswechsel ab 200 ms möglich bleibt. Anbei ein Bild meiner bisherigen Testschaltung, ohne diese Safety-Anforderungen. Relais K1 schaltet an oder ab, Relais K2 stellt die Richtung ein und darf nur bei ausgeschaltetem K1 umgeschaltet werden. Relais K2 soll in Hardware sicher ausschaltverzögert werden, ohne Relais K1 zu beeinflussen. Ein Kondensator parallel zu K2 würde aber wohl auch K1 mitversorgen, wäre so also nutzlos. Jetzt stellt sich mir die Frage, wie man das umsetzen müsste. Dioden irgendwo rein? Widerstände? (Spannungsabfall in beiden Fällen?) Aus anderen Threads hier entnehme ich, dass das erstens nicht so einfach ist und es zweitens verschiedene Meinungen (oder Kenntnisstände) darüber gibt. Ich hoffe, da etwas schlauer zu werden. Weitere Eckdaten: Ein Gerät soll 8 Rollos steuern können, in ein REG-Gehäuse mit 6 TE passen und wird mit 12 V betrieben. Ich werde zwei davon verbauen. Später soll alles als OSHW veröffentlicht werden.
Mit 1 nF wirst du nichts spürbares bewirken. Da werden eher einige hundert uF nötig sein. Allerdings wird es den Transistoren wohl nicht gut tun, so viel Ladung kurz zu schließen. Bei deinen Punkten 2 und 3 übertreibst du meiner Meinung nach. Halbwegs vernünftige Antriebe sollten solche seltene und kurze Ereignisse vertragen.
:
Bearbeitet durch User
Nemopuk schrieb: > Mit 1 nF wirst du nichts spürbares bewirken. Der C1 und C2 dient einem anderen Zweck, siehe Kommentar im Schema. Habe ich an anderer Stelle von jemandem gelernt, der sich scheinbar sehr gut mit Transistoransteuerung von Relais auskennt. Dürfte wohl eine Detailoptimierung sein. Aber wenn ich einen Fehler leicht ausschließen kann, dann mache ich das. Die gewünschte Verzögerung ist in dieser Schaltung wie gesagt noch gar nicht enthalten. Dass ich eine Kapazität im Bereich von 10 bis 100 µF brauche, habe ich schon erwartet. Den genauen Wert kann ich ausprobieren. Aber wie muss die da genau eingebaut werden, damit sie wie gewünscht wirkt?
Yves G. schrieb: > Aber wie muss die da genau eingebaut werden, damit sie wie gewünscht > wirkt? Ich würde das gar nicht in Hardware implementieren, weil ein simpler Tiefpass vor dem Transistor alle Schaltvorgänge verzögert. Du willst aber nicht verzögern, sonder zu schnelle Wechsel unterbinden. Das macht man besser in der Software.
Nemopuk schrieb: > Bei deinen Punkten 2 und 3 übertreibst du meiner Meinung nach. Halbwegs > vernünftige Antriebe sollten solche seltene und kurze Ereignisse > vertragen. Das nehme ich auch mal als Antwort, bin jedoch auf weitere Meinungen gespannt. In der Anleitung eines der Motoren steht, dass zumindest die Bestromung beider Leiter „auch im Millisekunden-Bereich“ den Motor zerstören kann. Zu zu schnellen Richtungswechseln habe ich nirgends eine Aussage gefunden. Falls es nur ein mechanisches und kein elektrisches Problem ist, dürfte die kurze Zeit tatsächlich nicht viel ausmachen, da sich da nicht mehr viel Masse in Bewegung setzt. Kann schon sein, dass ich diese Sicherheitsfunktion nicht brauche. Falls sie mit geringem Aufwand umzusetzen wäre, würde ich es mir trotzdem überlegen.
Nemopuk schrieb: > Ich würde das gar nicht in Hardware implementieren, (...). Das macht > man besser in der Software. Ja, Software kümmert sich um die Sunshine-Fälle, in denen die Software die volle Kontrolle behält. Es geht mir um den Fall, dass die Software während einer Motorfahrt abstürzt oder die Versorgungsspannung wegfällt. In diesen Fällen macht man mit Software vermutlich nichts mehr. Deshalb in Hardware.
warum macht man das heutzutage noch wenn es fertige günstige und sichere Lösungen wie Shelly gibt? Eigenes Protokoll? Evtl. mal generell auf MQTT wechseln?
Heinz R. schrieb: > Eigenes Protokoll? Evtl. mal generell auf MQTT wechseln? Und wie bekomme ich den Raffstore damit zuverlässig auf eine bestimmte Höhe gefahren und danach den ursprünglichen Lamellenwinkel wieder exakt eingestellt? Oder allgemein bei mehreren kurzen Fahrten die aktuelle Position noch getrackt? Deshalb soll das der µC in Echtzeit machen und das bietet so niemand an. MQTT läuft über TCP/IP, bei Shelly zudem noch über WLAN. Immer mehr Jitter. Shelly macht auch nur einen Rollo pro Gerät, das wird teuer.
Nemopuk schrieb: > Das macht man besser in der Software. Heinz R. schrieb: > warum macht man das heutzutage noch wenn es fertige günstige und sichere > Lösungen wie Shelly gibt? Er möchte funktionale Sicherheit und keinen smarten Spielekram! Oder, für Euch vereinfacht: Es soll kein Schaden entstehen, wenn sich die Software falsch verhält.
Die klassische Relaisschaltung dazu: Elko parallel zur Relaiswicklung, Diode in die Kollektorleitung.
Yves G. schrieb: > (..) > Ein Kondensator parallel zu K2 würde > aber wohl auch K1 mitversorgen, wäre so also nutzlos. Ein Kondensator parallel zur Relaiswicklung sorgt für eine Anzugs- und Abfallverzögerung. Das Relais schaltet langsam ein und langsam aus, was für schnelleren Kontaktabbrand sorgen kann. Zudem bilden der C und L vom Relais einen Schwingkreis. Das Problem musst du in der Ansteuerung der Relais lösen, also vor dem Transistor.
Werner H. schrieb: > Elko parallel zur Relaiswicklung, Diode in die Kollektorleitung. Elko ist klar. Wo die Diode hinsoll, habe ich nicht verstanden. Meinst du eine Diode zwischen Relais und Transistor? An welchem der 3 Abschnitte?
Jörg R. schrieb: > Ein Kondensator parallel zur Relaiswicklung sorgt für eine Anzugs- und > Abfallverzögerung. Ich hätte erwartet, dass der C (ohne R) unabhängig und schnell auflädt, ohne das Relais aufzuhalten. Beim Abschalten kann er das Relais aber noch einen Moment versorgen. Das ergäbe nur eine Abschalt-, aber keine Einschaltverzögerung. Mit R kann man andere Effekte erzielen. > Das Relais schaltet langsam ein und langsam aus, was > für schnelleren Kontaktabbrand sorgen kann. Hab ich auch schon von gelesen. Dieses Wechselrelais darf sowieso nicht unter Last geschaltet werden, weil das einen zu schnellen Richtungswechsel des Motors zur Folge hätte. Ist hier also unkritisch. > Zudem bilden der C und L vom Relais einen Schwingkreis. Und was sind die unerwünschten Folgen hier? > Das Problem musst du in der Ansteuerung der Relais lösen, also vor dem > Transistor. Damit kann aber der Wegfall der Versorgungsspanung nicht gepuffert werden, weil eine längere Ansteuerung ohne längere Versorgung des Relais keinen Effekt hat. (Oder?)
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.

