PIC-Microcontroller

Das nächste Projekt ist im Entwicklungsstadium. Es handelt sich um die Steuerung eines elektrischen Garagentor-Antriebes (eGA), besonderes Merkmal: die Power kommt aus einem 12-Volt-Autoakku und der hat sie wiederum von einem Solarpanel auf dem Garagendach. Das bislang existierende Fertigprodukt will nicht mehr! Während der Entwicklung eines Neuen wird es immer wieder Detailfragen geben, die ich gerne in diesem Fred unterbringen würde, egal, ob es um Hardware oder Softwareprobs geht, um nicht gleich die unendliche Fred-Vermehrung zu betreiben. Es würde mich freuen, wenn ihr hier zwischendurch immer mal reinschauen würdet.

Erste Frage: Ist für das erwünscht störungsfreie Arbeiten des PICs eine metallische Abschirmung nötig?
Dagegen:
- in der Anlage des Fertigproduktes des eGA gab es keine. Der darin auch werkelnde PIC war einfach in einem Kunststoffgehäuse untergebracht.
- ,,mein" PIC, ein PIC18F14K22  - is klar, was sonst ? - wird mit Handbremse betrieben, also über den internen LFINTOSC-Oszi mit nur 32 Khz.
- das Ganze wird halt in einer Garage montiert, die nicht mal einen 230-V-Anschluss hat. Direkte Störungen würde ich da nicht erwarten.

Dafür:
-jetzt ihr!
Grüße, picass

Also ich würde alle nicht benötigten Eingänge niederohmig, aber kuzschlußfest (330 Ohm?) auf GND legen, die benötigten Input-Pins, wenn möglich, mit R/C-Kombination entstören.
Besser, wenn der geringfügige Mehrverbrauch keine Rolle spielt: freie Pins als OUT deklarieren und unbeschaltet lassen.
Auf jeden Fall, um "Hängen" des PIC zu vermeiden: Watchdog-Timer nutzen!

Gruß
PICkel

Danke für den Ratschlag "niederohmig", aber vergebene Liebesmühe! Aisler war diesmal zu schnell. Gestern gegen 19 Uhr den Entwurf übermittelt, heute morgen um 6 Uhr kam die Nachricht: bereits in Produktion. Knurr......., hätte gerne noch den Durchmesser einiger Vias vergrößert... nix geht mehr. Ist aber Beides kein Prob und damit zum Stichwort"Stromverbrauch keine Rolle".
Wenn der Leerlaufstrom eines Autoakkus nicht über 25 mA, in Grenze auch 50 mA rüber klettert, kann der Akku das in der Regel ab. Ist unwahrscheinlich, dass ein PIC im Schlummer mit seinen als OUT geschalteten Ausgängen diese Hürden reißt! ;D

Zwecks meiner Frage nach Abschirmung: hat sich wohl auch erledigt. Habe eben beim Wühlen in meinen Regalen ein exakt passendes kleines Alugehäuse gefunden. Das werde ich nehmen. Aber weniger wegen der Abschirmung, als vielmehr deswegen, weil man da so praktisch diverse Buchse anmontieren kann.

"Hängen" vermeiden mit Watch-Dog-Timer? Ähm, hatte ich noch nicht, da brauche ich noch ein Kurzinfo zu.

Wer mal einnen Blick auf die Schaltung werfen möchte, bitte sehr: siehe Bilder.
Grüße, picass

Wie wäre es noch mit einer ISCP Schnittstelle.
Oder nimmst du den Controller immer raus wenn du ihn programmierst ?

Zum Thema Watchdog-Timer:
Durch äußere Einflüsse (Spannungseinbruch, elektrostatische Entladung, ...), oder Bedienfehler, Programmfehler u.ä. kann es passieren, dass der PIC in eine Dauerschleife gerät.
Und wenn der PIC nicht mehr reagiert, geht vielleicht auch die Garage nicht mehr auf???

Deshalb gibt es den Watchdog-Timer: Ein Oszillator (LFINTOSC) mit ca. 31kHz arbeitet auf einen Zähler mit Pre- und Postscaler. Läuft der Zähler über, wird der PIC neu gestartet. Das geschieht je nach Einstellung nach spätestens 2,18 Minuten.
Deshalb wird im Programm an geeigneter Stelle zyklisch der Watchdog-Timer vor Ablauf der eingestellten Zeit mit CLRWDT zurückgesetzt und somit ein Neustart vermieden.
Arbeitet das Programm nicht mehr korrekt, erfolgt das Rücksetzen mit CLRWDT nicht mehr und es gibt den Neustart.

Ich habe z.B. eine Gewächshausbelüftung mit PIC12F683 gebaut, die nur mit Solarzellen und Pufferkondensatoren ohne Batterie arbeitet. Bricht die Spannung ein, könnte der PIC "nervös" werden. Die Brown-Out-Detektion wurde aktiviert, und der WDT bietet zusätzlichen Schutz.

Gruß
PICkel

@Peter :Du hast es erahnt. Bei diesem Entwurf hatte ich - anders als bei meinen letzten Platinen - keine Vorsorge fürs Programmieren des eingebauten µC's getroffen. Und konsequenterweise auch die "große" Bauform gewählt. Sollte ein Umprogrammieren fällig werden, ist die Entnahme des µC's die vielfach einfachere Methode - in diesem Fall. Zudem habe ich bei Versuch, die alte Schaltung wieder zu beleben, es schätzen gelernt, an der DIL-Version fix mal 'ne Messspitze ranhalten zu können. Und Platz spielt da auch keine Rolle.

@PICkel :Danke für die Ausführung. Das Datenblatt ist komischerweise nicht sehr auskunftsfreudig. Da wird jedes Bit der notwendigen Register erläutert, aber wozu das Ganze, das habe ich dem Blatt nicht entnehmen können.
Du bist aber schon irgendwie sorglos! :o Kaum ist ein Begriff geklärt, wirfst du einen anderen in den Ring, alles so Sachen, die ich bislang praktisch nie genutzt hatte.

Die Aisler-Jungs&Mädels nerven mich gerade! Erst haben sie in Rekordzeit mit der Produktion der Platine begonnen und damit verhindert, dass ein (leichte) Nacharbeit möglich war, und nun kommen sie nicht aus dem Quark, nicht mal die übliche Meldung der Fertigstellung und dem Absenden ist bislang gekommen. Da habe ich den Aufpreis - also quasi das Doppelte - bezahlt, um diesmal fix ans Löten zu kommen, und nu' is nichts mit dem Versprechen der wenigen Arbeitstage.

Grüße, picass

Zitat von: picass in 27.03.2022, 10:06:36 CESTSollte ein Umprogrammieren fällig werden, ist die Entnahme des µC's die vielfach einfachere Methode

Ein Tipp dazu:
Die Beine der ICs verbiegen sich gern beim Einstecken oder Herausziehen aus der Fassung:
Stecke während der Testphase den PIC in eine normale IC-Fassung und benutze diese Kombination anstelle des einzelnen PIC. Verbogene/abgebrochene Pins kosten Dich dann nur noch eine neue Fassung und keinen neuen IC.

Zum Thema Watchdog:
https://www.youtube.com/watch?v=EdG2QtoUE9w
Bis etwa zur 4.Minute gibt es eine kompakte Übersicht über die Konfiguration.
(Danach geht's mit C weiter, was ich mir als normaler Mitteleuropäer nicht {mehr} antue.)
Wenn Du Dich damit befassen willst, eine Testplatine und einen Oszillographen hast, kann ich Dir mal ein Demoprogramm senden.

Gruß
PICkel

Zitat von: PICkel in 27.03.2022, 14:01:02 CESTWenn Du Dich damit befassen willst, eine Testplatine und einen Oszillographen hast, kann ich Dir mal ein Demoprogramm senden.

Ja..., ja..., ja..., ja....!

Kuck an! Da ist ja noch einer, welcher einen Bogen um das große "C" schlägt!
Aber dennoch müssen wir längst keine gemeinsame Sache machen, also zumindest beim Programmieren. Hoffe, dein Demo-Prog lesen zu können.

Verdammich, bei Aisler klemmt es. Zwei Tage fürs Blitzboard bezahlt, aber nach 5 Arbeitstagen herrscht dort tiefe Ruhe.
Grüße, picass

OK,
derzeit habe ich wegen des guten Wetters mit Brennholz zu tun. Der Heizölpreis lässt grüßen...
Im Laufe der Woche dürfte es dann aber klappen.

Gruß
PICkel

Auch bei mir fordert das schöne Wetter Tribut und deshalb auch jetzt nur ganz kurz und dann auch schon wieder weg:
Die Aisler-Jungs&Mädels haben geliefert und - is klar - innerhalb eines Tages war die Platine auch bestückt, siehe Bild. Das Programmieren hebt dann ab morgen an. Fix wech...
grüße, picass

Hallo picass,

hier ist mal ein kleines Prog. (80 Byte) zum Test des Watchdog- Timers (WDT).
Der WDT wird vom LFINTOSC (ca. 31kHz) abgeleitet und hat einen festen Vorteiler von 1:128.
Das ergibt einen Takt von ca. 4ms, der bis max. 1:32768 (ca. 2min) geteilt werden kann.
Im Demo- Beispiel wird 1:16 geteilt, das sind ca. 64ms.
Getestet wurde mit einem PIC18F24K22, der sehr ähnlich zum 18F14K22 ist.
Voreinstellungen: INTOSC mit CLKOUT, WDT Enabled, WDT Postscaler: 1:16.

An CLKOUT (PortA.4 beim P18F14K22) sollte sich das Taktsignal von ca. 7,5kHz messen lassen.
An PORTB.7 wurde das Oszilloskop angeschlossen.

Ablauf anhand des Oszillogramms WDT_Timing.jpg:
1: PORTB.7 = 0   
2: 5ms gewartet, dann PORTB.7 auf 1 zum Triggern des Oszi
3: 10ms geartet, dann zurück auf PORTB.7=0
4: 10ms gewartet, PORTB.7 = 1, WDT zurückgesetzt, warten auf Ansprechen des WDT
5: nach ca. 67ms "schlägt der WDT zu", der PIC wird resettet -> goto 1:
Das Ganze wird also zyklisch wiederholt.

Zur Konfiguration:
Die entsprechenden Config-words habe ich im Compiler voreingestellt:
- INTOSC mit CLKOUT
- WDT ein, Postscaler 1:16
Ich nehme an, Deine Programmierumgebung bietet ebenfalls diese Optionen.

Im ZIP-File findest Du: Programm, Assemblercode und ein HEX-File zum direkten Brennen.

Gruß
PICkel

WDT_Timing.jpg Konfig1.jpg Konfig2.jpg WDT.zip   

Hallo PICkel!
Sehr herzlichen Dank für deine Arbeit und die Entwürfe! Habe alles gesichert und werde es abarbeiten. Erschrecke bitte nicht, wenn dies nicht sofort erfolgt. Bin ja gerade angefangen, das Prog für meine Garagentorsteuerung zu schreiben. Das Grundgerüst dafür muss erst stehen. Wenn das soweit gelaufen ist, dann kommen die "Features" dran. Bis dahin bitte ich um Geduld.
Aber wirklich sehr schöne Arbeit, sieht echt toll aus!
Grüße, picass

Das Grundgerüst für mein Programm "Garagentor-Steuerung".........!!! Soll ich jetzt fluchen..? Oder viel fluchen? Oder inflationär fluchen? Oder was? >:(
Mehr als 2 Tage habe ich mit den vermaledeiten Interrupts gekämpft. Hatte ich vormals schon und nun wieder: in der Regel wollte der PIC einfach nicht aus dem Sleep-Modus via IRQ aufwachen. Das Perverse dabei, dass es im Simulator wunderbar klappte!! Nur "in echt" boshafter Weise nicht! :(

Gerade eben gelang es zum ersten Male, dem PIC im "PICkit Low Demo Board" ein Verhalten anzugewöhnen, das man - guter Wille vorausgesetzt - als in etwa berechenbar bezeichen könnte.
Das war voll der Horror und so recht traue ich diesem  komischen Braten nicht. Das Datenblatt ist mit teils nicht dokumentierten, rsp. "ungenauer" Schreibweise nicht immer eine Hilfe, gerne werden dort auch falsche Spuren gelegt.
Welche Flanke wann die PIC18 Interrupt Logic beeinflusst, rsp. bewirkt, ist auch ein wenig bebildertes Rätsel. Nach der Listung für "INTCON2" war ich der Auffassung, dass der IRQ bei fallender Flanke ausgelöst wird. Ja Schiete! Mal so, mal anders, im Moment aber doch wieder bei fallender Flanke.
Mist, das hat mich gaaaaaaanz viel Zeit und Nerven gekostet, und ob das nun wirklich zuverlässig so arbeitet, muss noch veritabel getestet werden.
Grüße, picass

Es ist kalt geworden, dieser Tage. Nebst Schnee kann sich auch Eis ausbilden. Auf solchem bin ich gerade ausgeschleudert: nix is mit der herrlichen, heilen IRQ-Welt!
Das Prog schien den IRQ abzuarbeiten, der Simulator zeigte jedoch ein Fehlverhalten. Dem bin ich nachgegangen, zum 687. Male das Datenblatt strapaziert und glaubte dann, ein Kenner geworden zu sein. Im INTCON Register gibt es das RABIF-Flag, welches einen pin-change - zum Beispiel nach Tastendruck - vermeldet. Das Flag muss in der IRQ-Routine fix gelöscht werden, sonst rotiert so'n armer PIC ggf. immer wieder in diese IRQ-R rein. Und dieses verdammte Flag wollte sich einfach nicht löschen lassen.
Und da gabs im Kleingedruckten den Tip, diesen mismatch zu beseitigen, indem einfach mal unverdächtig PORTA ausgelesen würde, nur so, ohne das weiter zu verwerten. Tatsächlich ließ sich nach diesem Lesen endlich der Löschbefehl ausführen.
Der Simulator wies daraufhin einen völlig ungestörten und vor allem geplanten Ablauf des Progs auf. Ihr ahnt es: nur "in echt" wieder nicht. Nun will der PIC wieder nicht aus dem Schlummer raus. Darf man hier im Forum k...., also sich erbrechen, es wäre mir danach. Bin quasi keinen Millimeter weiter gekommen.
Grüße, picass

Hallo picass,

Der PIC zieht mit INTOSC @31kHz bei 25°C und 5V max.:
60uA im Betrieb, 48uA im Sleep.
Überlege mal, welche Selbstentladung Dein Auto-Akku hat und welchen Mindeststrom der Spannungsregler 12V->5V für den PIC ohnehin schon benötigt.
Da kannst Du doch getrost auf den Krampf mit SLEEP verzichten!? Das ist doch nur sinnvoll bei Sparbetrieb mit Knopfzellen.
Sieh lieber zu, dass die Peripherie im Ruhezustand wenig Strom verbraucht.

Und:
Stark vereinfachtes Rechenbeispiel für Garagentüröffner:
4A*1min = 0,06667Ah = 66667uAh entspricht >1000h PIC-Betriebszeit @60uA.
Da lohnt doch der Aufwand mit SLEEP nicht?

Gruß
PICkel

 

Derart nüchtern hatte ich das bislang nicht betrachtet. Nutzt aber nichts... :-[ !
Meine technische Neugierde treibt mich an, ein erkanntes Problem zu lösen, wenn es sein muss auch durch Niederknüppeln.
Mein Hauptprob ist die viel zu geringe Übung im Programmieren, das ist quasi nur ein seltener Gelegenheitsjob. Und danach werden Basics leider wieder vergessen. Dann kommt bei mir persönlich dazu, dass ich Datenblätter zwar lesen kann, aber die vermitteln mir nur extremes Detailwissen und lassen den Zusammenhang und vor allem den Grund "warum" vermissen.
In der Pädagogik gibts den berühmten Satz: "Ein Bild sagt mehr als tausend Worte". Analog dazu geht es mir so, dass ich mit einem kurzen und grundsätzlichen Beispiel-Programm weitaus schneller Verständnis für die Notwendigkeiten erkennen kann als durch stundenlanges Blättern im Datenblatt-Dschungel. Und so'n Beispiel hatte ich zuletzt ausgebuddelt. Das stammt übrigens von Microchip himself und war eine Beigabe zum Musterboard mit dem ewig langen Namen "PICkit Low Pin Count Demo Board".
Dann stand ich mir auch noch selbst auf dem Fuß, indem es mir beim Hantieren mit den zahlreichen Strippen der Experimentierschaltung gelang, zwei Port-Pinne mit zu hoher Spannung zu versorgen. Das hatte der PIC wohl übel genommen und zeitweilig für Verwirrung gesorgt.
Ist jetzt aber alles Geschichte, seit gestern Nachmittag funktioniert die IRQ-Routine so, wie erwartet, übrigens auch bei dem mit Spannung teil-überversorgten PIC. Es kann nun also weiter gehen.

Auch wenn das IRQ-Prob nun gelöst ist, sehe ich allerdings dennoch Bedarf, rsp. Interesse an einer weitergehenden Betrachtung der IRQ-Thematik. Da gibt es noch Fragen, zurückhaltend formuliert. Z.B. die unterschiedliche Behandlung eines "high-priority"- IRQs gegenüber dem "low-priority". Dann noch, ob man nicht doch auf die ganze IRQ-Klamotte verzichten und lediglich einen Port-Pin-Wechsel auswerten kann, rsp., ob es für diesen Wechsel eine Einfach-IRQ-Variante gibt. Dann scheint der PortA3 Pin eine Sonderrolle zu spielen. Der ist bei diesem PIC-Typ ja als reiner Digital-Input-Pin zu nutzen. Und der scheint einfacher ansprechbar zu sein, z.B. auch bei beiden Flanken (pos. u. neg.).

Na ja, das war nun wieder ein Blut-Schweiß-und Tränen-Wiedereinstieg ins Programmieren. Hab' mich gestern mit einem guten Schluck Rotweines getröstet.
Grüße, picass

Nein, kein Problem, aber die Abwägung einer elektrotechnischen Frage nach dem Aufwand für das Steuern des elektr. Garagentor-Motors.
In der alten, leider unzuverlässigen Schaltung existierten zwei Relais. Je nachdem, welches angezogen war, wurde der Motor ,,be-polt":  entsprechend stellte sich beim Gleichstrommotor die Drehrichtung ein. Zusätzlich war noch ein MOSfet vorhanden und der war ja wohl irgendwie  wichtig. Jedenfalls nutzte das Relais-Schalten nichts, auch der Fet musste angesteuert werden, denn nur der schaltete den Motorstrom auf GND, erst dann konnte was laufen.

Dieses Konzept hatte ich stumpf übernommen, nur gibt es in meiner Schaltung ein zusätzliches Relais, welches einen DC-DC-Wandler einschaltet, der von den 12 Volt des Auto-Akkus auf den benötigten Pegel von 24 Volt für den Motor liftet.
Also könnte, rsp. müsste in meiner Steuerung zum Einschalten des Motors dieses passieren:
1. Relais fürs Hochfahren einschalten, dann
2. Relais für das Einschalten des DC-Wandlers einschalten, dann
3. dem MOSfet ein paar Elektronen zukommen lassen, damit der endgültig den Weg frei macht.

Und – is klar – beim Ausschalten die ganze Reihenfolge wieder anders rum. Nicht, dass dieser Vorgang halt ein Problem darstellt, aber die Frage nach dem Sinn des Gefummels würde ich schon gerne los werden. Selbst vermute ich, dass die Relaiskontakte geschont werden sollen, indem die Relais nur im unbestromten Zustand geschaltet werden und danach erst der Saft kommt.
Oder seht ihr einen anderen Grund für die Existenz von zwei Schaltern für einen Stromfluss? Gäbe es einen, müsste, könnte, sollte ggf. die Reihenfolge der Dreifach-Ein-u.-Aus-Schaltungen geändert werden.
Grüße, picass

Na, das ist wohl die klassische 2-Relais-Polwendeschaltung für Gleichstrommotoren.
Der MOSFET hat 2 Vorteile:
1. Lebensdauer: Die Relais müssen nicht im Umschaltmoment (Kontaktprellen) den mehrfach  höheren Anlaufstrom ggü. Normalbetrieb bewältigen.
2. Sicherheit: Wenn der MOSFET "die Hufe hebt" und durchlegiert, bleibt der Motor trotzdem bei nicht angesteuerten oder bei gleichzeitig angesteuerten Relais stromlos. Gleiches gilt bei Fehlfunktion des Controllers: Es müssen immer genau 2 Ausgänge aktiv sein, sonst läuft der Motor nicht.

Gruß
PICkel

Ähm...PICkel, ist das jetzt ein besonders raffiniertes Bilderrätsel oder hast du aus Versehen dasselbe Bild zweimal eingestellt?!
Also, es geht - wie vermutet - um die Sicherheit beim Schalten und überhaupt. Na gut, dann werde ich das Konzept so belassen.

Gettz bekommt ihr was aufs Auge! :P
Nämlich die Bilder von meiner schönen, neuen Testanlage. Um es gleich anzugehen: die ist diskussionsfähig, rsp. -bedürftig. Weil....man braucht sie nicht wirklich, die im letzten Bild unauffällig am Rande liegenden zwei kleinen Platinchen mit je zwei Schaltern, rsp. Tastern täten es auch. Aber.... aber bei der nun ausrangierten orig Steuerplatine hatte ich mich geärgert, dass es nicht gelang, die Einbausituation in der Garage in meinem Arbeitsraum nachzustellen. Irgendwie merkte der darin verbaute PIC immer, dass es nicht real war. Der konnte auch auf ein externes EEprom zugreifen und wer weiß, was der da so alles gespeichert hatte. Für meine Arbeiten - sowohl im Realen als auch dem Hantieren mit der MPLAB-IDE - ist das Simulieren aber nicht nur hilfreich, sondern häufig auch notwendig, und deshalb griff ich zu diesem Hilfskonstrukt. Und geholfen hat es tatsächlich schon, erinnert die Hilfe doch unversehens auch an die identischen Probleme des Kettenzuges in der Garage.
Zudem konnte ich mal wieder etwas schon seit Ewigkeiten tief hinten in den Elektronikregalen Verbuddeltes endlich einer Nutzung zuführen: den Neigeschaltern mit Quecksilberfüllung! Und man lernt auch was dabei, z.B., dass selbst die totsichere Schaltung in Gestalt der zwei voll von Quecksilber umtosten dicken Drähten nicht perfekt sein muss. Kaum zu glauben, aber bei einem Röhrchen müssen die Drähte innen drin korridiert sein, denn das schaltet unzuverlässig!

Naja, das Konstrukt ist halt hübsch anzusehen und nach den Schindereien zwecks der IRQ-Problematik brauchte ich mal Ablenkung und dringend einen positiven Aspekt bei diesem Projekt. Der nächste Programmpunkt ist auch geschafft, es geht um die Aktionen bei der Inbetriebnahme. Dabei weiß der µC ja nicht, in welcher Position sich der Kettenantrieb gerade befindet. Dafür habe ich eine Lösung entwickelt und ins Prog übernommen... und die wunderschöne Testanlage hat nach den üblichen Mucken dieser Form der Lösung auch zugestimmt.
Grüße, picass 

Zitat von: picass in 06.04.2022, 10:10:14 CESTÄhm...PICkel, ist das jetzt ein besonders raffiniertes Bilderrätsel oder hast du aus Versehen dasselbe Bild zweimal eingestellt?!

Ist natürlich 2x das selbe Bild. 1x hätte also gereicht, aber ich fand es sooo schön, dass ich es gleich nochmal hochgeladen habe.  ;D

Gruß
PICkel

Hängen im Schacht! Wie man hier im Pott zu sagen pflegte. Kaum zu glauben bei einem auf den allerersten Blick einfachen und überschaubaren Programm. Da soll ja "nur" was von rechts nach links und umgekehrt, rsp. von oben nach unten, etc. laufen. Aber dauernd werden reichlich Schalter auf ihre Schaltstellungen und der Laufwagen auf seine Position abgefragt, und allein dieses Abfragen machen das Arbeiten mit dem Simulator in der MPLAB-X-IDE zu holprigem "Vergnügen".
Im Moment ärgere ich mit Unzuverlässigkeiten rum, vor allem dem Beeinflussen von Bits. An diversen Stellen im Sim gibts z.B. zwei aufeinander folgende Anweisungen wie bsf PORTA,3 und bsf PORTA,4. Na prima, aber nicht nur gelegentlich wird das großzügig übersehen und die Voreinstellungen nicht geändert. Oder: das Prog springt nach ersten, erfolgreichen Läufen in eine Unterroutine, in die es theoretisch gar nicht gelangen dürfte. Schwitz....! Das Einzige, was zuverlässig klappt ist "wast the time".
PortA,3 hat ja 'ne Sonderrolle, das wäre ein Hinweis, aber warum wird dann bei den Umkehrungen, also beide genannten bits mit bcf das Bit 4 nicht zurück gesetzt?
Vor einigen Tagen beobachtet: beide bits sollten nacheinander gesetzt werden, das erste wurde gesetzt, das zweite auch, aber gleichzeitig das erste bit wieder zurück auf null gesetzt. Voll der Horror. Muss gestehen, es fehlt mir im Moment der zündende Gedanke, mit welcher Systematik oder auch welchen Mitteln oder auch welcher zusätzlicher Hardware - z.B. Hardware-Debugger - der gordische Knoten zu zerschlagen wäre. Für den Simulator reicht die Konzentrationszeit zwei bis drei Stunden, wenn dann immer neue, andere Fehler auftauchen, wirds trüb, dann geht es erstmal nicht weiter.
Grüße, picass

Read-Modify-Write Effekt?

Wenn du einen PIC mit lesbaren LAT Registern hast,
solltest du niemals Bits im PORT modifizieren!

Auch wenn nur ein Bit geändert wird, dann muss
trotzdem der ganze Port eingelesen werden. Beim
lesen von PORT sind je nach Konfiguration manche Bits
immer 0, auch wenn im LATCH eine 1 steht.

Die werden dann "falsch" wieder zurück geschrieben!

Das betrifft dann eben immer die anderen Bits,
nicht das, welches verändert werden soll!

Bei PICs bei denen das LATCH nicht lesbar ist,
muss man ggf. selber ein schattenregister anlegen.

Das mit dem Lesen-Ändern-Schreiben-Effekt muss ich erst mal verarbeiten. Werde mich aber drum kümmern, also versuchen.... ::) Es hatten sich - das sage ich jetzt ungern - aber auch wieder gänzlich banale Fehler eingeschlichen: an einigen Positionen hatte ich dem PIC aufgegeben, auf einen PORT zu schreiben, schwitz. Da herrscht nun aber Ordnung.
 
Inzwischen läuft es rund...! Allerdings noch nicht ganz zuverlässig. Nach mehreren gelungenen Runden (hoch-, bzw runterziehen), ist ein Sprung in eine - gewollte - Fehlerroutine möglich. Und beim zwischenzeitlichen Aufstoppen, wenn also das noch virtuelle Garagentor auf halbem Wege gestoppt werden soll, dann stoppt es zwar, aber beim nächsten Startbefehl will es manchmal die Hufe nicht heben.
Habe das Gefühl, dass die Entprell-Routinen für die Taster da eine noch ungute Rolle spielen. Zudem sind die beiden Quecksilber-Schalter evtl. nicht zuverlässig, einen  musste ich ja schon aussondern. Werde mal nach anderen Neigungsschaltern suchen und bis dahin auf das Einfach-Brettboard mit den zwei mechanischen Schiebeschaltern zurück greifen.
Bin inzwischen wieder guten Mutes, das es noch was wird.
Grüße, picass

Zitat von: vloki in 10.04.2022, 10:18:49 CESTWenn du einen PIC mit lesbaren LAT Registern hast,
solltest du niemals Bits im PORT modifizieren!

Hab' gerade mal geschaut, genauer, gleich zwei mal. Zum einen führte die Guckst-du-Suche zu einer Seite mit guter Darstellung des read-memory-write-Effektes: https://download.mikroe.com/documents/compilers/mikroc/pic/help/rmw.htm
Zum anderen ist beim PIC18F14K22 laut Datenblatt das Latch lesbar. Werde die entsprechenden Routinen in meinem Prog einer gestrengen Prüfung unterziehen und ggf. pädagogische Maßnahmen einleiten. Hätte nicht gedacht, dass es selbst schon bei µC's eine Schraibschwäche geben kann! ;)
Grüße, picass

Dreh' gerade wieder am Rad. Habe meiner Schaltung 3 "Verbesserungen" zukommen lassen, und nun geht wieder nichts mehr. Erste VB: die Neigungsschalter mit Quecksilberfüllung wurden ersetzt durch solche Schalter, die auch in der Garage verbaut sind, ein auf der Laufkette installierter Magnet und an den Endpositionen Schalter mit Reedkontakten. Das klappt nun wirklich zuverlässig. VB2: Die Ports werden nur mehr zum lesen benutzt, geschrieben wird nur noch auf LATs. VB3: die Folgen im Prog, an welchem mehrere Bitset-Funktionen aufeinander folgten, wurden komplett ersetzt durch das Setzen per MOV-Befehle auf die LAT-Register. Damit müssten die Read-write-Probs aus der Welt sein.

Leider ist der PIC in seinem Lauf auch aus der Welt. Zum Hardware-Debuggen hat es noch nicht gereicht - dazu später - , aber per LED-Kette an bislang nicht benutzten PORTs und entsprechenden Setzungen im Prog lässt sich nun per nacheinander Einschalten der LEDs verfolgen, ob die Kette auch abgearbeitet wird. Und das lässt nun - leider - ein ungutes Ereignis erkennen:
Wie schon vorher mal erwähnt springt der PIC unvermittelt in eine Programm-Routine, in die er "eigentlich" nur geraten könnte, wenn zwei Bedingungen erfüllt sind: Der PIC, rsp. die gesamte Schaltung wurde zum ersten Male mit Strom versorgt und zweitens: aufgrund der Endschalterstellungen wird erkannt, dass das G-Tor nicht wie beabsichtigt für den Erstlauf (der Motor könnte in die falsche Richtung loslaufen) in der Mitte des Laufweges steht.

Kurz gesagt: Der PIC beginnt das Programm prima, lässt wie vorgesehen den Motor so laufen, dass ein G-Tor hochgezogen würde in die Endposition und dann dort natürlich stoppt. Das klappt prima, nur sollte der PIC dann in eine spätere Sleep-Routine rein, die im Moment noch aus einer reinen Schleife besteht, in welcher der PIC solange rum läuft, bis durch einen Schaltbefehl via Handschalter oder per Funkfernbedienung das G-Tor wieder loslaufen soll.
In diese Sleep-/Schleifen-Routine kommt er aber gar nicht, sondern landet wieder in der Fehlerroutine, die via Aufruf nur ganz am Anfang des Progs angesteuert werden kann, nirgends sonst im weiteren Prog-Verlauf gibt es einen Aufruf für diese Fehler-Routine.
Einzige Erklärung: der PIC wird nach vollbrachtem ersten Hochziehen komplett aus seinem Programm geworfen und startet wieder von vorne!
Per Oszi habe ich die Versorgungsspannung geprüft, da kann ich aber keinen Überschwinger oder einen heftigen Spannungseinbruch feststellen - es zuckt mal kurz was, aber - soweit erkennbar - nur was im Bereich von ca. 100 mV. Der MCLR-Pin ist per Initialsierung still gelegt und als reiner I/O-Pin genutzt. Und der liegt knallhart über einen Schalter und Vorwiderstand auf +5 Volt, da kann sich auf keinen Fall was rühren.

Der Aussprung erfolgt direkt, nachdem die zwei benötigten Relais ausgeschaltet wurden. Das sind zwei recht gute ZETTLER-Relais, die extra auf sehr geringen Strombedarf ausgesucht wurden. Die Spulen haben 720 Ohm und "verbrauchen" nur 20 mA. Sie werden nicht von der 5 V-Versorgung des PICs aus bedient, sondern ziehen ihren Saft vorher über eine Entkopplungs-Diode direkt von den 12 Volt des (späteren) Akkus. Natürlich ist an jede Spule eine gegen Plus gerichtete Entkopplungsdiode angebracht.
Zufall oder nicht.... im Programm gibt es an dieser Stelle nichts Geeignetes für einen Aussprung, da ist nur noch der call-Aufruf einer Entprell-Schleife mit 0,1 sec Länge. Die liegt aber auch im Block Null, ein Fehlsprung müsste ausgeschlossen sein. Und - ach ja - im Simulator läuft zum zwanzigsten Male in Folge alles prima.

Zum Hardwaredebuggen bin ich noch nicht gekommen, wofür es Gründe gibt. Soviel bislang ersichtlich müssen dafür diejenigen PORTA-Pins, welche auch zum Incircuit-Programmieren benötigt werden, frei sein. Sind sie aber nicht, die fraglichen 3 sind alle für Schalter genutzt. Also müsste das Alles erst sowohl im Programm als auch an der Platine - schon wieder mit Kratzen und Fädeldraht - geändert werden. Und auf Änderungen radikaler Art stehe ich im Moment nicht, nachdem vor wenigen Tagen alles zu laufen schien und die drei "Verbesserungen" nun alles zum Stillstand brachten.

Ich bitte um Anregungen, wie aus dem Schlamassel heraus-zu-picken wäre.
Grüße, picass

Brown-out-Reset und Watchdog in den Config Bits abgeschaltet?

Zitat von: vloki in 12.04.2022, 13:27:44 CESTBrown-out-Reset und Watchdog in den Config Bits abgeschaltet?

Ob BOR oder WDT angesprochen haben, kann man beim 18F14K22 im RCON- Register feststellen.
Z.B.: RCON.3 (das TO-Bit) = 1 nach Neustart oder CLRWDT, es wird gelöscht, wenn der WDT aktiv wurde und den PIC resettet hat. Auch für Brown-Out gibt es im RCON entsprechende Bits.

Gruß
PICkel

Ja, war alles abgeschaltet.
Hatte gerade einen Bericht erstellt mit all den vielen weiteren Maßnahmen, dem Übel auf die Spur zu kommen, und las den B. vor dem Einstellen Korrektur, um die Schraibfehler möglichst zu entdecken, und blieb beim allerletzten Satz hängen, in welchem ich beschrieb, dass auch die Pegel der Schalterabfragen sauberst bis zu den zutreffenden Ports zugestellt würden. Und schon wieder Zweifel!
Also die Pikse des heiß gelaufenen Multimeters an die beiden Portpinne, die Signale kamen in der Tat sauberst mit den zu erwartenden Pegeln je nach Endschalter-Lage an, aber am falschen Port. Beim Umtauschen der Quecksilber-Röhrchen gegen die Magnetschalter waren im Gestrüpp der überall grünen Käbelchen die Ports vertauscht. Und so gesehen lief alles nicht etwa gestört, sondern perfekt ab: der PIC merkte beim Einschalten, dass die Grundfiguration der Schalter so nicht sein sollte, und vermeldete das in seiner Fehlerroutine. Für die gab es - das ist jetzt neu - doch noch einen zweiten, bislang sehr unbeobachteten Einsprung über eine "eigentlich" überflüssige 4-zeilige Routine, die nur zur Sicherheit der Sicherheit eingefügt war. Und die war diejenige, welche ich nicht mehr beachtet hatte, und genau die war es, welche den Fehler bemerkte.
Ach....., wenn so'n MicroController für was wirklich Spitze ist, dann dafür, jede winzigste Kleinigkeit der Fehlstellung eines einzigen Bits zu bemerken und dann verschnupft zu reagieren. Is klar, aus dieser Nummer konnte ich nur mit einer weiteren Blessur rauskommen, ein Ruhmesblatt ist in weiter Ferne, also quasi hinter dem Horizont.
Aber nu' läuft alles so, wie es soll. Also fast ! Die Kette wird zuverlässig komplett abwechselnd zu den Endpositionen gefahren, und auch das zwischen zeitliche Stoppen und Retournieren klappt. Da gibt es bei jedem ca. sechsten Male einen Holperer, der aber nicht wirklich die Funktion beeinträchtigt. Da ist vermutlich noch eine Entprell-Routine zu kurz. Oder so....
Danke für eure freundlich zugedachten Hilfen, sowas trägt immer weiter!
Heute Abend müsste ich mich erst mal bes....., also einen guten Schluck des viel geliebten Rotweins zu Gemüte führen. Aber ach, auch da will was nicht klappen: habe mich gerade vor ein paar Tagen trocken gelegt, muss mal wieder sein.
Deswegen nun trockene, aber dem Horror entronnene Grüße, picass

Zitat von: PICkel in 12.04.2022, 14:38:52 CESTOb BOR oder WDT angesprochen haben, kann man beim 18F14K22 im RCON- Register feststellen.

Im Debug-Mode schon ;-)

-> Nie eine Platine designen ohne entsprechenden Anschluss!

Stichwort Debuggen!
Warum hat - wie berichtet - in den letzten Tagen das Debuggen im MPLAB X IDE-Simulator geklappt, aber der reale PIC hatte immer andere Vorstellungen? Wir wissen ja jetzt, dass mir die beiden grünen Käbelchen an zwei Ports verrutscht waren. Im Sim hatte ich die vielen Schalterabfragen ja künstlich erzeugen müssen durch Toggeln. Und da hatte ich eine an den Monitor-Unterrand geklebte Skizze mit der "richtigen" Portbelegung vor Augen und natürlich das eingeben.

In der Zwischenzeit, rsp. der zeitweiligen Verzweiflung kam wieder der Wunsch nach einem Hardware-Debugger auf, welcher Einzelschrittmodus kann. Das wäre dann das ausgelaufene Modell "Real ICE", das es neu nicht mehr zu kaufen gibt oder das aktuelle Modell "ICE4". Hab' heute mal geschaut und für einen Schock gesorgt:
Eintausenneunhundert Euro, ach ja, ohne Porto!
Grüße, picass

Das Projekt ist weiter, aber nicht fertig. Mittlerweile ist die Schaltung in das Gehäuse eines ausrangierten PC-Netzteils eingebaut und in der Garage plaziert worden. Das Garagentor wurde auch mehrfach schon bewegt, aber es gab und gibt weiterhin Anpassungs-Probs zu überwinden, auch mechanische: die Kette hat sich gelängt und schleift ungut, weswegen sich der Kopplungs-Mechanismus zwischen Kette und Tor gelegentlich aushängt.
In den letzten Tagen trieb mich die Funkfernsteuerung zur gelinden Verzweiflung. Diejenige der alten Anlage war eh' schon lange außer Betrieb, sie wurde immer unempfindlicher bis zur Unnützbarkeit. Also ein neues, preiswertes Fernsteuermodul gekauft. Damit funkte es wieder, aber an meiner neuen Schaltung in der Garage nicht. In meinem Arbeitsraum an der - s.o. - Simulations-Steuerung wohl, aber nicht in der G..
Sobald die Funkkiste an die Steuerung angeschlossen wurde, klappte nichts mehr, auch die sonst funktionierende Handsteuerung revoltierte. Der Verdacht fiel auf irgendwelche unpassende Ankopplung der jeweiligen Eingänge am PIC, aber das wars nicht: schließlich wurde beobachtet, dass allein der Anschluss der Funke an den PIC ganz ohne Steuerausgang schon den Betrieb störte. Is klar, dann den Oszi ran und der entlarvte Übles.
Die 12-Volt-Versorgung der Funke versprühte einen grafisch hübschen Teppich aus vielen, vielen Einzelpunkten im Spannungsbereich von ca. 6 Volt bis zu 12 V hin, Foto leider nicht verfügbar. Ein angebauter Tantal stellte das Sprühmuster ab, aber es blieben in der Schaltung weitere Schwingungen: die 12 V gelangen über eine Diode auf einen Vorwiderstand von 220 Ohm und dann auf einen 5V-Regler, dazwischen zweigte was ab für ein längst abgebautes Relais. In diesem Bereich schwingt es immer noch übel, siehe Bild 2. Eine Erklärung für diese Schwinger habe ich nicht, immerhin eine irre Amplitunde. Im 5 Volt-Bereich ist davon freundlicherweise  nichts mehr zu sehen, und auch die in das Gehäuse mit dem PIC führende 12-Volt-Versorgungsleitung ist nur noch in hoffentlich tragbaren Maßen belastet, laut Bild 3 sind da ca. 130 mV überlagert auf den 12 Volt.
Gibt es Vorschläge, wie man die Schwinger in der Funkschaltung beseitigen könnte? Oder wären z.B. Ferrit-Perlen in der 12 V-Leitung oder sonstwo sinnvoll?
Grüße, picass

Was hängt denn da für eine Stromversorgung dran ?
Wenn keine Batterie dran hängt dann mal mit einer versuchen.
Schaltnetzteile und andere Spannungsversorgungen sind bei Funk sehr
schlecht. Ist nur mit großen Aufwand zu entstören.

Zitat von: Peter in 27.04.2022, 21:29:29 CESTWas hängt denn da für eine Stromversorgung dran ?

Lässt sich in einem Satz nicht beantworten:
- in der Einsatzversion wird letztlich ein Auto-Akku mit seinem extremst niedrigen Innenwiderstand die Elektronenquelle sein, aber ...... aber vorgesehen ist die Unterbringung der kleinen Empfangsplatine einige Meter davon entfernt, also möglichst dicht am Garagentor, in der stillen Hoffnung, dass der Empfang dort besser ist, als wenn die E-Platine hinten in der Garage an der sonstigen Elektronik und dem Akku verbaut ist.
- die hier demonstrierten wilden Schwinger wurden aber über mein Universal-Netzgerät mit Saft versorgt. Dieses U-NG ist ein stonealtes und besteht quasi fast nur aus einem LM317 mit 1,5 Meter langen Versorgungsstrippen.

Aber gemach, Freunde, auch dieser Kampf scheint inzwischen gewonnen: der Einbau von gesamt 4 zusätzlichen Kondensatoren in diese E-Platine brachte alle Schwinger zum Ausschwingen, rsp. zum Schweigen. Das Prob wäre erledigt - is klar - nun geht es an die anderen Fronten, hier der Software, zu besichtigen demnächst.
Grüße, picass

Ich denke eine Abschirmung ist nicht notwendig. Du hast außerdem eine sehr niedrige Taktfrequenz und bist durch die Batterie weg vom Netz. Wichtig ist, das du keine fliegende Verdrahtung hast. Ich hatte noch nie ein Metallgehäuse benutzt, meine eine Schaltung werkelt schon über 10 Jahre.

Mit meinem Projekt ging es nicht so recht weiter. Die Hardware ist zwar komplett in der Garage eingebaut, aber die Software darauf hatte ich nur testweise in Betrieb genommen. Zum Einen traute ich dem Frieden noch nicht so recht, zum Anderen wollte ich erst noch warten, bis auch die Interrupt-Routinen eingearbeitet waren und das wiederum sollte die Betriebssicherheit erhöhen, rsp. herstellen. Dann ist da noch das ungelöste Prob, dass der Antriebsschlitten, mit dem das Tor an den Kettenantrieb gekoppelt ist, sich zu häufig aushakt und - ach ja - die Kette ist immer noch zu lang. Und dann kam der Krieg! :o
Das wurde mein persönlicher Krieg, mein Kampf mit den Tücken der Interrupt-Technik. Im Programm ist ein Sleep-Funktion vorgesehen, und da wollte der µC manchmal nicht rein, oder manchmal nicht mehr raus, manchmal übersprang er die elegant. Das hat mich graue Haare gekostet und das bei Glatze!

Seit 15 min bin ich durch das Toggeln einer LED überzeugt, dass der Endsieg...., ähm....., dass diese Runde nun an mich gegangen ist. Zumindest in meiner Simultan-Anlage in meinem Kellerlabor funktioniert das. Morgen der ultimative Test in der Garage.
Grüße, picass

Magst Du mal das Programm hochladen, dann würde ich mal darüber schauen. Mit der Betriebssicherheit ist es so eine Sache. Ich suche schon fast 10 Jahre einen Fehler in meiner Soft - bzw. Hardware. Mein Internetzugang mit dem ENC28J60 ist nach gewisser Zeit nicht mehr erreichbar. Ich habe es so gelöst, das ich alle 10 Minuten den Baustein resette was natürlich nicht die schöne Art ist. Jetzt habe ich mal testweise den Takt von der SPI Schnittstelle auf 1/16 gesetzt. Dies bringt aber offenbar auch keine Besserung.

Komme gerade aus der Garage, und weil ich nicht möchte, dass der Staatsschutz hier unnötig rum schnüffelt, vermeide ich ein Wort der Steigerung für den Sieg über die Technik, sondern sage stattdessen: es ist geschafft: die Torsteuerung funktioniert. Rauf- u. Runterziehen und zuverlässiges "Einparken" an den Endpositionen und auch zwischendurch Aufstoppen, Kehrtwende, etc.... alles klappt. Zwischendurch pennt der PIC immer ein, das soll so sein.
Na gut, niemals ist so'n Programm ganz fertig. Im Moment braucht es manchmal zwei Tastendrücke, um eine Funktion auszulösen. Komischerweise aber nur in der realen Welt, in der Garage. Ein PIC mit demselben Programm in meiner Simulationsanlage macht das nicht. Grübel...., motz und nix verstehen. >:(
Aber lass ma, das wird schon auch noch.

Das Ziel ist erreicht, auch die Elektronenquelle - das Solarmodul - lädt den Auto-Akku gerade wieder auf: pünktlich zum Zieleinlauf scheint die Sonne. Sowieso, als auch auf mein Projekt. Da gibts demnächst sicher noch was zu sagen, aber erst mal isses gut.

@pic18 :Danke für das Angebot der Begutachtung des Programms. Wenn alles fertig scheint, stelle ich das wahrscheinlich hier ein. Falls du vorher schon neugierig sein solltest, vermelde das.
Grüße, picass

 :(  :(  :(

Meine schöne, neue Garagentorsteuerung erweist sich als unschön: das Öffnen u Schließen funktioniert, aber die Elektronik ist da irgendwie übereifrig. Es klickert bei den Relais, tut sich aber nichts, oder aber nach dem dritten Klicken gehts erst los und das dann häufig in der falschen Richtung. Meist will das Tor dann auch noch nur nach oben, also zum Öffnen, zum Schließen hat es meist keine Lust.

Das für mich Verwirrende: der in meinem Keller-Labor programmierte PIC wird natürlich erst in der Simultan-Anlage getestet und regelmäßig für gut befunden. In der Garage pfeift der mir was. Transferiere ich ein- u. denselben P dann zurück in den Keller, schaut er unschuldig drein und fragt, wozu dieser unnötige Rücksturz gut sein soll. Is klar, das Simulieren per MPLAB brauche ich gar nicht erst zu versuchen. Weil die Schalterbetätigungen dort im Sim ja auch simuliert werden müssen, also getoggelt wird, klappt das da bestens.

Die ,,Strom-Versorgung" in der G kann es nicht sein. Da liefert ein fetter Auto-Akku, der bestens geladen und mit einem tierisch niedrigen Innenwiderstand gesegnet ist, Elektronen ohne Ende. Die Hardware im Keller und in der G ist identisch, da läuft jeweils ein bewusst zum schnellen Wechsel in einer DIL-Version geformter PIC auf demselben Platinen-Typ.

Die Tasten-Abfragen für Funk- u. Handschalter sind im Prog so gestaltet, dass zunächst auf den ,,Druck-Level" – hier auf eine ,,0" – reagiert wird, dann gibts eine 20mS-Zeitverzögerung (20ZV), dann wird auf das Loslassen der Taste gewartet – also auf die ,,1" - , dann wieder eine 20ZV und dann wird entsprechend nach Wahl im Prog weiter gesprungen. In der Keller-SIM-Anlage klappt das so wunderschön: drückt man eine Taste, dann passiert gar nichts, lässt man die los, kommt es zum Passieren und auch genau zu dem Erwarteten.

Is klar, wenn man nicht weiß, wo, dann muss ganz am Anfang der Faden aufgenommen werden. Wo ist der Anfang? Vermutet ihr den Fehler im Programm oder bei der Hardware?
Grüße, picass

Elektronik und - is klar - auch das PIC'en kann/können solch ein faszinierendes Hobby sein! :)
Ganz besonders dann, wenn ein und derselbe PIC in zwei absolut identischen Platinen bei absolut identischer Außenbeschaltung zwei gänzlich verschiedene Verhaltensmuster darbietet. >:(
Habe die Belegung der nur vier fraglichen Pinne optisch, physisch und elektrisch überprüft: bei den zwei Pinnen für die Eingangssignale je eines Handschalters und der Funkfernbedienung liegt die gleiche Schaltung vor - die Pinne liegen über 82 kO an Plus und werden bei Betätigung auf GND gezogen, wie auch Gleichheit bei der Abfrage der beiden Endpositions-Schalter gegeben ist, auch sie sind via 82 kO- R's an Plus gelegt und werden nach GND gezogen.
Aber wenn derselbe PIC-Baustein in der Garagen-Anlage sitzt, dann wird er eigensinnig. Das komplette Hoch- bzw. Runterziehen klappt bestens, aber wehe, man unterbricht zwischendurch. Dann will er anschließend nur noch nach oben, das G-Tor schließen - nix, dazu hat er keinerlei Lust mehr.
Wird der PIC raus gerupft und in den Sockel der Keller-Anlage gestopft, ist er brav' wie ein Musterschüler, lässt sich stoppen, fährt anschließend in die andere, die Gegenrichtung, usw., usw..Da ist er voll der Retournierer!
Ein Wunder! :o
Was gettz?
Grüße, picass

Na, dann kann das Problem doch wohl nur im Umfeld liegen!?

Was ist anders als im Keller:

- stärkerer Motor, damit auch höherer Störpegel durch höheren Strom
- benutzt Du den früher erwähnten DC/DC-wandler? -> evtl. hochfrequente Störungen
- Geht der Motorstrom über die Platine und könnte wegen der Leitungsführung den PIC beeinflussen?
- Lange Leitungswege zwischen den Endschaltern/Sensoren und der Steuerung
- Hat das Garagentor einen Einklemmschutz, der bei erhöhter Stromaufnahme anspricht? (Anlaufstrom)
 
Du nimmst 82k Pull-Up-Widerstände. Das ist ein recht hoher Wert, die internen Pull-UPs (WPU) an PORTB betragen beim 18F14K22 typisch 20k.

Sind die Steuereingänge mit Abblockkondensatoren gegen Störeinstrahlung versehen?

Der Garagentormotor zieht im Anlaufmoment ein Vielfaches seines Nennstromes und der 12V/24V-Wandler nimmt eingangsseitig mehr als das Doppelte auf.

Liegt's vielleicht am Programm? In den Endlagen dauert es eine kurze Zeit, bis der Schalter/Sensor öffnet. Bis dahin ist der Anlauf-Motorstrom gefallen. Diese Zeitspanne fehlt beim Anlauf aus einer Zwischenposition, was zu Störungen führen kann.
Wenn Dein Prog. erst wieder auf Steuerkommandos reagiert, wenn die Schalter freigegeben sind, wäre das ein Ansatz. 
 
Gruß
PICkel

Hallo, PICkel, du des Wahnsinns fette Beute! (Zitat, frei nach einem Englisch-Pauker an meinem Gymi)
Du wagst es tatsächlich, an ein Ferndiagnose zu gehen? Voll das Risiko... und leider ging da auch was schief. Schief ging deine Analyse hinsichtlich der anderen Einsatzbedingungen in der Garage. Weiß nicht, ob ich das nicht deutlich beschrieb, aber das Stadium ist mittlerweile weit hinten.
Mein gestriges Statement bezog sich auf die Situation, dass die Steuerungsplatine in der Garage ausgebaut, in mein Keller-Labor verfrachtet wurde und sich nun in direktem Vergleich mit der dortigen ,,Keller-Platine" befindet. Will sagen, Stromversorgung, Motor, und auch ein Teil der Sensoren sind ,,keller-identisch" und damit gleich. Die G-Platine treibt nun also auch den Motor der Simul-Anlage an.
Und da treibt der es immer bunter! Habe gestern Abend das Prog überarbeitet, dabei u.a. nach meiner Einschätzung Überflüssiges raus gekegelt, auch z.B. die Abfrage, ob die Endschalter tatsächlich verlassen sind und die Sicherheitsabfrage, ob die Schalter (Funk u Handsteuer) tatsächlich los gelassen sind.

Dabei kam rum, dass in der Simul-Anlage alles wie vorgesehen läuft: komplettes Hoch- bzw. Runterziehen, Stoppen an beliebiger Stelle, danach Retournieren, also beim nächsten Knopfdruck gehts in die  andere Richtung, einfach prächtig. Aber dann der treibende PIC, was derselbe ist, der 30 Sekunden vorher in der Simul-Platine brav'st werkelte: verpflanzt in die G-Platine treibt der's bunt. Er zieht zwar komplett hin-und her, nun will er aber gar nicht mehr anhalten, nirgendwo. Er ist dauernd am Laufen – obwohl er das natürlich nicht soll und die Verlaufsform im Deutschen auch nicht wohl angesehen ist! Er kann zwar inzwischen beim vermeintlichen Zwischenstopp, also irgendwo zwischen den beiden Endpunkten retournieren, also die Richtung perfekt wechseln, was er vorher nicht konnte, aber er hält nicht mehr an!

Da sitzt ein prächtiger Wurm in der G-Platine drin, ich sehe ihn nur nicht.
Grüße, picass

Ich hab' ne Krise! Und eine Deprise zudem! :(
Hatte mit Kontroll-Messungen an den fraglichen 4 Portpinnen begonnen und dabei festgestellt, dass der PIC empfindlich auf die Berührungen mit der Messspitze meines Multimeters reagiert. Besonders die Portpinne A3 und A4 (Funk- u. Hand-Taste) fallen auf. Wenn der Motor gerade ruht und dann die Pikse z.B. auf A3 gesetzt wird, dann startet das den Motor.
Es hat auch nichts, rsp. nicht viel genutzt, die Widerstände - wie angeregt - von 82 kO zu verringern. Gerade an diesen beiden Ports liegen nun je ein 3,3 kO R an Plus: hat die Berührungsempfindlichkeit nicht erkennbar geändert.
Dann der Oszi. Auf der 5 V Speisespannung sind beim Schalten der Relais - es sind in der Regel zwei gleichzeitig - "Striche" auf dem Bildschirm sichtbar, welche andeuten könnten, dass die Spannung kürzestfristig auf ca. 3 Volt einbricht, rsp. so'n Spike runter hat. Ist aber leider ein Digitaler. Dessen Kürzest-Anzeigen misstraue ich.
Da ist zunächst auf Höhe der 5 V -Anzeige ein weitestgehend guter, dicker, gerader Strich mit nur unbedeutenden "Kräuselungen" zu sehen. Dann beim Relais-Schalten für eine knappe halbe Sekunde auf ca. 3 V Höhe ein zusätzlicher, ganz dünner, aber quer über den ganzen Bildschirm!
Ein echter Spike würde eine sichtbare Unterbrechung des Hauptsignals zeigen und dann entweder nach oben oder unten halt irgend einen Schwinger. Das zeigt der Digi-Oszi nicht, sondern nur eine zusätzliche dünne Linie. Das Drehen an der Zeitachse bringt leider keine Änderung. Kann sein, dass dieser "dünne" Strich nicht wirklich ein echtes Signal darstellt, sondern irgend'ne Eigenheit der Technik des Digitalen.
Mist, flixter, mein guter, stonealter analoger Hameg 1005 will leider nicht so recht. Bei dem hatte jede Signaländerung einen eindeutig zuordnungsbaren Grund, es war eine klare Signaländerung halt.

Die beiden Relais benötigen je nur 20 mA zum Schalten, "eigentlich" dürfte das die Stromversorgung nicht beeindrucken. Alle ICs haben unmittelbar zwischen ihren Versorgungs-Pinnen je einen 0,1 µF Kondensator und der 5 V-LDO hat "rechts" und "links" je einen 1.000 µF Elko.

Im Moment drehe ich am Rad. Und wie! Heute gehts nichts mehr, bin Matsche. :(
Grüße, picass

Mal ganz kurz:

- Oszi-Tastkopf auf 1:10 gestellt, um Eingangskapazität zu verringern?
- mal testweise ca. 10nF an RA3 und RA4 gegen Masse hängen zum Entprellen
- der OPA und der LM311 dienen wohl dem Einklemmschutz durch Stromüberwachung? -> evtl. mal im PIC die Abfrage von RA5 abschalten. 

Gruß
PICkel

Was mir noch auffällt, hat aber erstmal nichts mit dem Programm zu tun:

Du verwendest den IRF540, der ist lt. Datenblatt erst ab 4,5V Ugs spezifiziert, und da auch nur bis ca. 6A Id, bei 5V Ugs bis 10A Id (bei 25°C und 24V Uds). Du hast max. 5V Steuerspannung aus dem PIC als Ugs zur Verfügung, davon geht noch der Sapnnungsabfall am Strommesswiderstand R1 ab. Da kommt, je nach Stromaufnahme des Motors und Spannungsabfall an R1, der IRF540 evtl. in einen undefinierten Betriebszustand.

Da wäre wohl ein LL-MOSFET besser geeignet, z.B.: IRL3803 (max. 30V, 140A) mit 18A Ids bei 3V Ugs

MfG
PICkel

Zitat von: PICkel in 24.06.2022, 20:29:37 CEST- mal testweise ca. 10nF an RA3 und RA4 gegen Masse hängen zum Entprellen

Es spricht der Entstörschutz östliches Westfalen, südlicher Lippebereich, Unterabteilung Emscher: die heute erbrachten Eingriffe in die Substanz der Hardware ergaben eine Wirkung.

Zunächst konnte der stonealte, analoge Oszi Hameg 1005 reaktiviert werden. Was'n Segen. WAS'N SEGEN!
Wenn der irgendein Signal zeigt, dann ist das eindeutig identifizierbar und vor allem zuordnungsbar! Schwinger kleinster und größter Art lassen sich greifen. Au man - wie war das noch mal?: es geht doch nichts über gutes Handwerkszeug! Lob, lob, usw...

Das Ding entlarvte Alles. Zunächst hatte ich einen Störgenerator eingebaut! :o Hatte ich in vielen Schaltungen gesehen: in die Zuführung zum Netzteil ist eine Doppel-Spule integriert, welche Schwinger von außen abhalten soll. Was tut man nicht alles, damit es gut wird?! So tut man auch Dinge, die man besser nicht tun sollte. Da war nichts berechnet, das war mit Pi mal Daumen da rein gesetzt. Tatsächlich bewirkte die D-Spule das Gegenteil, es traten kleine Schwinger auf, die nach dem Kurzschluss der beiden Spulen weg waren. War jetzt keine dramatische Wirkung, aber immerhinque.

Dann die Schwinger an den Ports für Endschalter und Funk/Handtaste argwöhnisch beobachtet. Dann an die Ports A0 u A1 für die Endschalter je einen 0,1 µF ran, war ja nett, schien auch optisch was zu bringen, aber.....Es verblieben A3 und A4, letzterer war im Moment bis auf den 82 kO-R nach Plus unbenutzt, es fehlte also die Funkfernsterungsplatine.

Dann wild entschlossen an den Port A3 für den Handschalter, also die Handsteuerung der Garagenanlage gleich einen Tantal mit 1 µF gelötet und irgendwie nahm ich das Hin- u . Her der Simul-Anlage danach gar nicht so recht bewusst war: schlagartig lief das, wie es sollte, genauso wie in der Simul-Anlage: Hochziehen und Halten am Endpunkt, das Ganze umgekehrt, Aufstoppen an beliebiger Stelle und vor Allem: dort auch Stehenbleiben - was gestern und heute Vormittag überhaupt nicht möglich war, auch das Wiederanlaufen klappte und das Schönste dabei: auch die Richtung stimmte, endlich wurde auch nach dem Halt in der Gegenrichtung gelaufen.

Ich dreh' jetzt noch runde Augen, und traue mich gar nicht, vor dem Kaffeetrinken zu versuchen, das nochmal zu testen, könnte ja sein, dass ich vor dem KTr nur noch halb brauchbar geguckt haben könnte. Ein einziger 1 µF C an A3 für den Eingang der Handtaste! Wer mir gleich in die Arme läuft, wird geknutscht, gut, Jungs, dass ihr soweit weg seid. Ob es das wirklich war?
Ab zum Kaffee, picass

Hallo!

Schön zu lesen, dass das Problem wohl gelöst ist!
Nach der freudigen Aufregung wäre wohl statt des Kaffees ein beruhigendes Bierchen angebrachter gewesen? ;D

Wollen wir hoffen, dass das Ganze auch im Einsatz in der Garage funktioniert!

Ein schönes WE wünscht
PICkel

Aus dem schönen Bier zum Feierabend wurden schöne Gläser des von mir geschätzten Rotweins. Ist aber ein gutes Stichwort. Es ist müßig, zu spekulieren, ob das Prob auch ohne deine zahlreichen Hinweise gelöst worden wäre. Klar ist, dass du der Erste warst, welcher den Finger auf die Anforderung eines Entstörtrupps gelegt hattest. Und deshalb muss ich nun deine postalische Adresse haben, bitte per PN übermitteln. Nein, ich komme nicht vorbei, aber.......

Die Sache ist noch nicht ausgestanden. Ich bin neugierig genug, um wissen zu wollen, was da genau passiert ist. So richtig einsichtig ist mir das nicht. Is wohl klar, dass die Relais die Ursache für Störimpulse sind. Vollziehe ich aber dennoch noch nicht ganz nach. Da hatte ich geglaubt, das Ausschaltprellen unterlaufen zu können, indem ich zum Motorausschalten den gesamten Port C, welcher ausschließlich für die Relais und den LeistungsFet zuständig ist, auf ,,0" setze, womit gleichzeitig die je beiden Relais und eben auch der stromführende MosFet abschalten. Dabei nahm ich an, dass der MFet so schnell schaltet,  dass die müden, mechanischen Relais noch mit dem Überlegen beschäftigt sind, ob sie denn nun... Und dieser Art sollten sie quasi stromlos abschalten und entsprechend keine Störimpulse mehr aussenden können.

Nach jedem Abschaltvorgang sollte es ja ,,eigentlich" zum Sleepen gehen, was aber offenkundig nicht passierte. Da suche ich jetzt nach einer Methode, zu ermitteln, was im Prog genau ablief. Es ist ja wohl durch einen Störimpuls ein neuer Interrupt aufgetreten, bevor die Sleep-Routine erreicht werden konnte. Jetzt muss ich mal stille weg drüber grübeln, wie ich das vorige Dauerlaufen und Nicht-Retournieren im Prog nachvollziehen und ggf. nachweisen kann. Da treibt mich die Neugierde.

Noch was treibt mich um: wenn die Relais solche Störenfriede sind, dann liegt der Gedanke nahe, ohne solche Dinger auszukommen. Da käme eine Brückenschaltung von und mit Halbleitern in den Blickpunkt. Und da bin ich gestern auf ein möglicherweise sehr feines IC von Infineon gestoßen, ein TLE8209-2SA. Das beinhaltet alles, was man benötigen könnte, in einem IC. Es hat zwei Leistungsausgänge, zwischen die ein Gleichstrommotor angeschlossen wird. Steuern lässt es sich – wenn ich das richtig verstanden habe – sowohl über nur drei Pinne quasi händisch und damit auch einfach via PIC, als auch aufwendiger über serielle Kommunikation, SPI oder so was. Das IC kann bis 28 Volt und 3 Ampere, was für den Fall meines Garagentormotors ausreichen würde. Kostet knapp 'nen Zehner, und – is klar – ist so gut wie nicht lieferbar, es sei denn aus Übersee – angeblich. Die Mouser-Jungs drücken sich da nicht so ganz verständlich aus, ob die nun haben oder nicht, da frage ich morgen mal nach. Wenn das zu beschaffen ist, wird es sofort bestellt..... und das Experimentieren ginge dann weiter.

Nicht die PN vergessen, PICkel, und – ach ja - : danke für deine helfenden Hinweise.
Grüße, picass

Zitat von: picass in 26.06.2022, 09:38:33 CESTAus dem schönen Bier zum Feierabend wurden schöne Gläser des von mir geschätzten Rotweins

Na dann: Nachträglich "Zum Wohl!"
(Die Geschmäcker sind halt verschieden  prost) 

Schön, dass es jetzt funktioniert.
Zum Thema Entstörung noch ein paar Tips:
- Ist der Motor entstört?
- Wofür ist D3? Wenn die Relais gleichzeitig ausgeschaltet werden, hängen alle Rel.-Spulen kollektorseitig "in der Luft". D4...D6 schließen zwar die Induktionsspannung kurz, eine Brücke statt D3 sorgt aber für einen definierten Pegel.
- Ich würde erst den MOSFET abschalten und nach kurzer Zeit (0,5...1sec?) die Relais. Immerhin hat der Motor eine trägheitsbedingte Nachlaufzeit und die Polwende-Relais schließen im Ruhezustand den Motor kurz -> Stromspitze!

Gruß
PICkel

(PN kommt am Montag)

Hallo picass,

hast email von mir auf b.......(at)web.de. Adresse stimmt hoffentlich noch?

Gruß
PICkel

Hallo picass,

auch wenn Du dieses Projekt erstmal nach hinten geschoben hast:
Noch während Deines Urlaubs habe ich mich mal hingesetzt und anhand des Schaltplanes "Garage_Plan.png" vom 23.3.22 ein Programm geschrieben. Das Prog. ist in mikroBASIC geschrieben und ist gerade mal 146 Zeilen lang incl. Leerzeilen + Kommentare bzw. 524 Byte Maschinencode.
Es werden m.E. alle Eventualitäten berücksichtigt incl. Tastenprellen, langer Tastendruck und Überstrom (Einklemmschutz).
Dabei bekommt der 12/24V-Stepup 300ms Zeit zum Hochfahren, was gleichzeitig dem Entprellen dient.
Bei PORTA.5 bin ich davon ausgegangen, dass bei Überstrom ein LOW- Signal anliegt.

Das Prog. sowie Asm- und Hex- Dateien findest Du im zip- Ordner.

Leider kann ich den Quellcode nicht einfügen, da die Zeichenanzahl auf 5000 begrenzt ist.

Garage.zip

PICkel... ! Was soll man da sagen? :( Bin erst mal 'ne Runde sprachlos, jedenfalls entfernt davon, die passenden Worte zu finden.
Vielleicht wäre es geschickter, so zu tun, als hätte man deinen Beitrag noch gar nicht entdeckt, und würde dementsprechend nicht Nachfolgendes sagen müssen/wollen: Deine Arbeit werde ich nicht sogleich würden können, sondern erst später. Im Moment sitzt mir das Finanzamt im Nacken, heute Abgabetermin, dann Steuerberater... Dann gibts diverse private Dinge, die ich ungerne in der Öffentlichkeit ausbreiten möchte.
Dein Engagement zu loben, damit irgendwie auch zu bewerten, fällt mir jetzt schwer. Ich möchte es, bin auch völlig aus dem berühmten "Häuschen"..... Die eigentliche Reaktion kommt wohl erst später, wenn es wieder läuft. Schade, dass man sich bei dieser Art der Kommunikation nicht in die Augen sehen kann, dann wüsste du, wie ich was meine.
Grüße, picass

Naja, das war gerade mal ein Nachmittag proggen und testen auf meinem Testboard. Als Übung und neue kleine Herausfordrung ideal.
(Bei der Hitze hier war der Aufenthalt im Freien sowieso nicht angenehm.)
Getestet habe ich es mit einem PIC18F24K22 und danach den Compiler umgestellt auf PIC18F14K22 incl. Anpassung auf entsprechende ANSEL-Register u.a. . In Ermangelung eines passenden PICs konnte ich keinen Test durchführen, der Compiler hat aber nicht gemeckert!

Also: Wenn Zeit ist, einfach mal testen und Probleme melden!

Gruß
PICkel

Zitat von: PICkel in 01.08.2022, 21:10:31 CESTWenn Zeit ist, einfach mal testen und Probleme melden!

Ist klar! Also fast.... :o
Was ist, wenn der Test keine Probleme gebiert? Dann keine Meldung?
 ;)
Grüße, picass

Laaaaaang war die "Pause"! :(
Aber 'nu ist wieder Bewegung in das Projekt gekommen. Nachdem ich mich endlich nicht mehr mit vermeindlichen und echten Rechenfehlern beim Subtrahieren und obscurem Verhalten von Flags abquälen muss - diese Probs sind gelöst! :) - habe ich heute das Garagen-Projekt wieder angepackt.
Ad eins wurde die Erstellung einer Notfall-Entriegelung (NfE) gelöst. Dessen Nicht-Lösung war einer der Gründe für die laaaaaange Pause. Die Grundangst, dass die geballte µC-Technik im Verbund mit der Elektrik - dort auch des Auto-Akkus - versagen könnte und ich mit einer Flex das sich der Öffnung versperrende Garagentor wie eine  Sardinendose würde öffnen müssen, hat mich von Experimenten abgehalten. Aber heute ist die NfE eingestielt worden, die Angst ist weg und die µC-Schaltung sitzt - nach einem letzten Test in der Simultan-Anlage in meinem Arbeitskeller - an ihrem Platz.
UND ES LÄUFT!
Rauf und runter, mit Stops und ohne solche. Alles klar! :D
Also fast! :(
Es gibt noch das alte Prob, dass der Transport-Schlitten, an welchem das G-Tor mitgezogen wird, sich an einer Position manchmal aushängt. Das ist aber ein rein mechanisches Problem und hat mit der µC-Technik schlicht nichts zu tun. Auch ist das kein dramatischer Fehler, denn das Tor ist dann schon weitest gehend offen, und mit etwas freundlichem Nachschieben per Hand kann nach gesteuert werden.. Nun also noch die Mechanik bekämpfen, aber die Elektronik steht!!!
Einen Prost auf diesen Endsieg hatte ich schon, heute Abend geht es in diesem Sinne - dem Prosten - weiter.
Au man, war das ein Kampf! :-\
Die Anlage steht natürlich unter Beobachtung. Kann schon sein, dass da noch irgend 'ne Überraschung nach tröpfelt, aber erst mal.... 8)
Grüße, picass

Eine Rückmeldung über den Betrieb in der hatten Praxis scheint mir angebracht: Es funktioniert immer noch! :)  Sogar das mechanische Ausklinken findet nicht mehr statt: da musste nur mal ganz besonders energisch die Klemmverbindung eingedrückt werden. Aber sowohl das Öffnen, Stoppen und Schließen des Tores wie auch die Funkverbindung sind alltagstauglich. Der ganze Aufwand hat sich gelohnt. Jetzt müsste nur noch mal die mittlerweile gelängte Kette besser in der Schiene unter der Decke geführt werden.

Bei der Gelegenheit muss ich mein schlechtes Gewissen offenbaren: Die ganze Mühe, welche sich @PICkel mit dem Schreiben eines Progs in Basic gemacht hatte, habe ich noch nicht ausreichend gewürdigt. Das habe ich aber nicht vergessen und wenn ich mit dem aktuellen Maulwurf-Projekt nicht mehr so eingedeckt sein werde, hole ich das Garagen-Projekt noch mal hoch und sage was dazu.
Grüße, picass

Zwei-einhalb Monate lief die Garagentor-Öffnungs-Anlage ohne irdendein Prob oder auch nur den Anschein davon. Gestern Vormittag sah ich aus Distanz rein zufällig, dass sich das Tor der Garage, die sich 50 Meter von unserem Haus entfernt auf einem Garagenhof befindet, selbständig in Bewegung gesetzt hatte. Erst vermutete ich, ein Handwerker mit seinem vor der G geparkten Lieferwagen hätte mit seiner Funke dazwischen gefunkt. War aber nicht. Nach dessen Aussagen war das Tor schon seit mehreren Minuten in Betrieb und öffnete und schloss nach Lust und Laune!
Natürlich hatte ich den Funkempfänger in Verdacht, der hatte sich ja - siehe oben - von Anfang an mit wilden Eigenschwingungen ungut eingebracht. Aber auch nach dem Abziehen der Funk-Zuleitung wollte die Anlage nicht von ihrem Eigenleben lassen. Watt'n Mist! Nun hebt das alles wieder an und ich kann nicht mal eingreifen, weil ich unmittelbar vor dem Antritt eines Urlaubes stehe. Also hab' die Anlage still gelegt und bewege das Tor per Hand.

Über den Anlass für das Eigenleben zu spekulieren, fällt mir schwer. Sicher ist nur, dass die Schaltung mit dem PIC nicht in einem geschlossenen Metall-Gehäuse steckt. Aber das war weder bei der Originalanlage der Fall, welche beim Kauf der kompletten Steuerung dazu gehörte - die steckte in einem einfachen Kunststoffgehäuse - noch hatte das in den 2,5 letzten Monaten zu irgendeiner Auffälligkeit geführt. Blöd ist auch, dass nach wie vor kein 230-Volt-Anschluss in der G liegt, sodass ich nicht mal eben mit dem Oszi der Sache auf den Zahn fühlen kann. Schwitz....., das könnte noch was Übles werden.
Grüße, picass

Hallo picass,

zuerst würde ich mal die Stromaufnahme beim Runterfahren prüfen. Vielleicht spricht der Einklemmschutz (Überstrom) an.
Das sollte zwar nur ein Hochfahren des Tores bewirken, wäre aber mein erster Gedanke.

Bis dahin: Schönen Urlaub!
Gruß
PICkel

Da es bei uns zumindest sehr kalt ist, werfe ich mal in den Raum das sich Kondenswasser irgendwo sammelt wo es das nicht tun sollte...

P. S. Ich habe mir ein Handheld gekauft. Damit kann ich zwar nur 50mhz aber für meine Zwecke bis jetzt immer ausreichent. Der geht auch ohne 230v ;) 

@^Cobra:

Ich habe schon an picass eine e-mail geschrieben u.a. mit diesem Hinweis:
Witterungsabhängig (Kälte) könnte das Tor schwerer gehen.
Ich habe das auch schon erlebt mit einem Sektionaltor an einem Hörmann- Antrieb, allerdings im Sommer:
Bei hoher Außentemperatur und entsprechender Sonneneinstrahlung auf das Tor wurde es gelegentlich schwergängig, weil die seitlichen Dichtgummis trocken wurden. Verschmutzung durch Staub spielte sicherlich auch eine Rolle.
Abhilfe brachten das Säubern der Gummis und die Behandlung mit Glyzerin-Gummipflege.
Seitdem warte ich vor dem Wegfahren immer die paar Sekunden, bis das Tor ganz geschlossen ist.

@picass:
Eine überarbeitete Programmversion ist bei der Nachricht mit dabei.

Gruß
PICkel

Zitat von: PICkel in 26.02.2023, 19:15:14 CETBis dahin: Schönen Urlaub!
Gruß
PICkel

Urlaub=Teneriffa, ein typischer Tagesverlauf:
Morgens Start am Hotel auf 20 m üM, von der Küsten-AB ab und auf Serpentinenstraße hoch. Sehr hoch..... bis in die Wolken, im dichten Nebel weiter hoch kurven, nach oben raus und deutlich oberhalb der Wolkendecke im strahlenden  Sonnenschein und mit T-Shirt bekleidet per Pedes ab in den Wald. Dort hoch bis zur Baumgrenze, diese Höhendistanz nochmal drauf, bis die Wolkendecke nur noch surreal weit unten liegt. Dann weiter hoch bis zum ersten Schneebrett, dort kurz den Schnee befummeln – nur anrühren, ist Naturschutzgebiet ! - , dann noch kurz riesige Höhlen und Tunnel im schwarzen  Lavafeld bewundern und das Ganze wieder retour und runter. Nachmittags im Hotel Hemingway huldigen, will sagen: Mojito verköstigen, kurz drauf im 28° C angewärmten Pool plantschen und Nachrichten von ,,zu Hause" über leichten Schneefall hören..... das bringts! :P
Ab morgen startet die "normale" µC-Arbeit wieder. :(
Grüße, picass

Das nass-kalte Wetter motiviert mich nicht, mit dem Oszi in die Garage zu ziehen und vorher noch 4 verschiedene 230-Volt-Kabelstränge aneinander zu stöpseln und die Übergänge wasserdicht zu verpacken. Danke für eure Last-Second-Anregungen. Ich möchte freundlich darauf hinweisen, dass nicht der Betrieb des Tores zu Probs führt, sondern schlicht das Gegenteil: der Nich-Betrieb. Das Prog ist so angelegt, dass immer dann, wenn ein Endlage-Schalter oder der Handschalter (direkt an der Schaltung) oder der Schlüsselschalter (in der G-Tür) oder der Funksender einen Impuls im laufenden Betrieb=Bewegung des Tores gibt, der Motor gestoppt wird und der PIC sofort in den Schlummermodus verfällt. Und aus dem kam er zuletzt leider unaufgefordert wieder raus.

Alle 4 Schalt-Geräte landen am Port B, welcher auf Wake-on-IRQ bei Wechsel der Logik-Level (LL) eines der 4 fraglichen digitalen Eingänge eingestellt ist. Folglich käme nach meiner Logik nur ein unerwünschter LL als Störenfried in Frage oder theoretisch irgendwas Übles auf der UV - 5V - Leitung. Besondere Feuchtigkeit existiert in der G nicht. Nach einer Regenfahrt steht in der schlecht gelüfteten G wohl einige Tage eine Wasserpfütze. Aber zum Einen bewege ich den Wagen quasi nur einmal pro Woche und zum Anderen würde der Zufall der Wetterbedingung für noch längere Zeiträume der Trockenheit sorgen. An die Schaltung selbst gelangt auf keinen Fall außer Verdunstungs-Feuchte noch Dickeres.
Werde mir heute erst mal das Prog wieder rein ziehen. Das ist nun leider ein ungutes Thema. Da hatte doch unser User PICkel sich zum zweiten Male bemüht, ein Alternativ-Prog auf die Beine zu stellen, rsp. das erste Prog überarbeitet und mir in einer Mail zugestellt. Gestern beim ersten Öffnen meines Mailfaches nach dem Urlaub quoll das extrem über: Über 170 Spams, gut je 40 neue Mails unter ,,Unbekannt" und ,,Freunde". Da musste hart durchgegriffen werden, um wieder Ordnung herzustellen. Die PICkel-Mail hatte ich für den Schluss aufgehoben, um sie besonders würdigen zu können... zumal sie eine angekündigte Anlage haben sollte. Dieser Schluss kam schneller als gewollt, kurz: im Trubel des Sortierens, Löschens, Lesens war sie plötzlich weg. Mist flixter. :(
Grüße, picass

Mist, flixter! Habe die Schaltung in der Garage ausgebaut, in meine Werkstatt verfrachtet, den "Garagen-PIC" ( DIL-Version ) aus der Fassung gerupft und in diejenige meiner Simultan-Anlage gestöpselt. Dort tut er alles, was er tun soll, gleich von Anfang an, ohne Nachhilfe, mit allen Tastern und Kombis probiert: hier alles gut! Da bleibt wohl doch nur die Schmutzkampagne des Verlegens und Verkuppelns von Einzelkabeln, um Saft in die Garage und an den Oszi zu bekommen. :(
Mist ......, aber das sagte ich schon.....
Grüße, picass

Noch'n Nachtrag, u.a. für PICkel: Die Überstrom-Sicherung/ der Klemmschutz des Garagentors sollte nicht das Prob sein. Diese Funktion hatte ich zwar auf der Platine mit allen Bauteilen ausgebildet, die also alle aufgelötet, diese Funktion aber in der Software noch außen vor gelassen. Der entsprechende Port-Pin wurde schlicht ignoriert und nicht z.B. für den IRQ bei Portänderung zugelassen.

Johannes, es sieht nicht gut aus! :(
Habe heute dein neueres File ,,garagentor II" in einen PIC18F14K22 gebrannt: es ziehen zwei Relais an, der Strom-Power-Mosfet wird bemost, auch eine eigentlich unbeteiligte LED leuchtet, aber die Kette verharrt wie angekettet! In dein Basic-File habe ich auch rein geschaut, raffe aber mangels Einübung in Basic ,,nicht wirklich alles". Auch auf Tastendrücke wird nicht reagiert. Noch'n Hinweis: beim – versuchten – Start stand das ,,Tor" - in der Simul-Anlage entsprechend die beiden Magnete auf der Laufkette – in der Mitte, beide Endschalter waren also offen. Vor und nach diesem Test war der "Garagen-orig-PIC" in der IC-Fassung, in beiden Fällen lief es einwandfrei.

Bei der Gelegenheit, rsp. dem Blick in dein Programm, das möchte ich hier mal deutlich und öffentlich sagen: du hast dir eine irre Arbeit geleistet! Nein, genau wohl gleich zweimal, denn es gibt inzwischen ja zwei Versionen. Au man, Johannes! Wie soll ich dir da danken? Ich versuche es mal einfach: Danke für deine zahlreichen Bemühungen. Ich weiß, dass vier Sätze als Dank ein wenig wenig sind! :(
Grüße, picass

Tut mir leid, Bernd!
Es musste alles ziemlich schnell gehen. Ich war mir meiner Sache ziemlich sicher, deshalb habe ich keinen Test auf dem Testboard durchgeführt.

Alles Weitere per PN
Gruß
Johannes

Macht nichts, wenn es hier beschaulich weiter gehen sollte. Das Garagentor wird halt von Hand geöffnet und da ich - wie schon mal gesagt - den dicken Sechszylinder in der Woche fast überhaupt nicht mehr anfasse, sondern stattdessen mit Behagen auf meinen E-Roller klettere, gibts wirklich keinerlei Anlass für Hektik. Ähm... meine Frau sieht das anders, aber die wird unterdrückt! >:D Zumindest in diesem Punkt! ;)
Muss selbst auch noch sämtliche Grundlagen der Hardware und meines Progs neu durcharbeiten, das dauert sowieso.
Grüße, Bernd

Habe in den letzten Tagen die Garagen-Steuerungs-Anlage ausgebaut und in meiner Werkstatt betrachtet. Zudem wurden diverse Tests mit der Simul-Anlage ausgeführt. Heute wurde noch der Funk-Empfänger aus der G geholt und hier gründlich untersucht. Leider alles toll in Ordnung! :)
 >:(

Kein Fehlverhalten zu finden, auch nicht mit dem Oszi im F-Empfänger!
Mist, wie soll man gegen Fehler ankämpfen, die sich verstecken?!

Einzig gefunden: der Port A ist komplett als Eingang geschaltet und der einzige, nicht benutzte Pin A2 war extern unbeschaltet. Allerdings wurde der weder abgefragt und war auch beim wake-up bei Port-Change vom IRQ ausgeschlossen, zudem war für den der interne pull-up-Widerstand frei gegeben, also eingeschaltet.

Kann nichts Verdächtiges finden, der Garagen-Pic läuft in der Simul-Anlage, als hätte er nie was anderes als gute Arbeit abgeleistet.
Grüße, picass

Um irgendwie voran zu kommen, bearbeite ich erst mal Vorhandenes – evtl. Neues muss warten. Zunächst habe ich den Funkempfänger auseinander gerupft. Gleich nach dessen Kauf hatte ich bereits das Relais raus geworfen, nun traf es alle noch verbliebenen und nicht benötigten Bauteile. Um kürzere Verbindungen zu schaffen, wurde auch die eigentliche Empfangsschaltung – die kleine Platine mit Quarz und ,,Antenne" – abgekniffen und wird dann anders wieder verlötet. Alle Elkos fliegen auch raus und werden durch solche mit geringem Innenwiderstand ersetzt. Dann kommt das Ganze in ein Metallgehäuse und dann sehen wir mal weiter.

Was mir auch nicht sehr gefällt, ist die irre Menge an ungeschirmten Leitungen in der Garage. Das fängt an bei dem Sonnenmodul und seiner langen Leitung bis zum Akku hin, das geht dann über Leitungen für Schlüsselschalter bis zur derjenigen für den Funkempfänger – auch dessen ungeschirmte Leitung zieht sich durch die ganze Garagenlänge, und die Leitungen für die Endablageschalter gibt es ja auch noch. Das Alles ist ein ganz schönes Anntennen-Equippment – das sollte eigentlich als Langwellen-Antenne eine gut brauchbare Verdrahtung sein.

Das Fehlen eines 230-V-Anschlusses bedingt so nebenher, dass auch keinerlei Erdung vorhanden ist. Daher überlege ich, ob ich eine solche Erdung nachrüste. Das wäre dann z.B. so ein Metall-Spieß, ca. 50 cm lang, den in den Boden vor der G rammen und hoffen, dass der sich auch weit genug rein rammen lässt und anschließend eine echte Erdung ermöglicht. Danach wären zumindest zwei der langen Leitungen durch Abgeschirmtes ersetzbar und die Metallgehäuse könnte angeschlossen werden. Habt ihr eine Meinung zum Sinn dieser Erdung?

Grüße, picass

von der Erdung halte ich nichts, du bist doch vom Netz getrennt?
Hast Du die Tantal Elkos und den MKT Kontensator eingelötet?
sieht komisch aus.

Hm..., von einer Erdung hälst du nichts? :o  "Eigentlich" gibt man sich doch recht viel Mühe, elektronische Schaltungen in Metallgehäusen unter zu bringen, sowohl, um Störstrahlungen von außen nach innen, als auch - wie in diesem Fall- zudem noch Störungen von innen nach außen abzuschirmen. Man denke an Schaltnetzteile im PC, an PC-Gehäuse überhaupt  oder z.B. die vielen, vielen Steuergeräte, die heutzutage in Kfz's stecken.

Irgendwas muss ja die PIC-Garagentorsteuerung gehörig aus der Bahn geworfen haben, irgendwas hat die Anlage veranlasst, immer wieder aufs Neue ungefragt los zu ziehen. Am Programm lags nicht, denn - wie beschrieben - arbeitet derselbe µC in der Simul-Anlage ohne jedwede Anormalität. Deshalb gehe ich davon aus, dass es externe Einflussgrößen sind. Da kann ich nur eine der eventuell Möglichen nach der anderen versuchen, zu bearbeiten, rsp. auszuschließen.

Alle "ungewöhnlich" aussehenden Kondensatoren hatte ich nachträglich eingelötet. Das "komische" Aussehen wird evtl. verständlicher, wenn man weiß, dass in dem winzigen Gehäuse eigentlich gar kein Platz für andere als Bauteile im 1204-SMD-Bauteile-Format mehr war. Das ging nur unter Quetschen und Rücksicht auf "schöne Optik" war nicht.
Die neuen Kondensatoren sind schon auf dem Wege in meine Werkstatt, und weil die dann modifizierte Platine in ein Metallgehäuse eingebaut werden wird, welches größer als das vorige Plastik-Dings ist, wird es vielleicht sogar "schöner" aussehen. Aber im Ernst: die Optik ist mir wurscht, die Schaltung soll nicht mehr so schwingen, wie sie es im orig-Zustand tat, siehe meinen Beitrag vom 26.04. um 11 Uhr.
Grüße, picass

Habe mir den Schaltplan nochmal angesehen: Du benutzt nur die internen Pull-Up's an PORTA. Dazu schweigt sich das Datenblatt leider aus. Für PORTB werden 50...250...400 uA angegeben, was einem Widerstand von typisch 20kOhm und max. 100kOhm entspricht. So ein hochohmiger Eingang ohne weitere Entstörmaßnahmen kann bei längeren Zuleitungen schon einige Störungen einfangen.
Ich würde zumindest dem Handtaster einen zusätzlichen Pull-Up- Widerstand von 0,5...1kOhm spendieren. Die Endlagenschalter sind unkritischer, da sie nur beim Fahren des Tores abgefragt werden müssen.

Gruß
PICkel
 

Zitat von: PICkel in 20.03.2023, 14:04:39 CETSo ein hochohmiger Eingang ohne weitere Entstörmaßnahmen kann bei längeren Zuleitungen schon einige Störungen einfangen. PICkel

Hallo PICkell!
Der Schaltplan entspricht nicht dem aktuell verbauten Material. Alle bis auf den genannten Port-Pin A2 hatten je einen 82 kO-R nach Plus und - is klar - der A2-er wurde nun nachbestückt. Hm..., hatte für mich bislang so'ne Grobeinteilung: alles unter 1 kO ist niederohming, ab 100 kO isses hochohming und dazwischen halt - überraschend ! - mittelohmig.
Hab's gerade mal mit meinem HP41CV nachgerechnet: du hast recht, bei 5 V und 82k fließt maximal ein sehr micromaler Strom, deutlich weniger als 1 mA. Na gut, ich werde umrüsten.

Anbei ein Auszug aus meinem heutigen Werkeln an der Garagen-Platine, der vorbereitete Text:
Heute spezielle Lötübung: Grund für die Zerspanungsaktion am Funk-Empfänger sind die Bemühungen, die ursprünglich vorhandenen wilden Eigenschwingungen zu verhindern. Dazu heute ein eher kleiner Beitrag, nämlich das Anbringen der üblichen 0,1 µF-Entkoppelkondensatoren ,,rechts" und ,,links" vom Spannungsregler-IC. Diese beiden C's sollen laut sämtlicher Vorschriften so dicht als nur möglich an den Anschuss-Pinnen – in diesem Fall drei – des Sp-Reglers angebracht werden. Nun neige ich mal wieder dazu, das wörtlich zu nehmen. Entsprechend wurden erst zwei C's im 0805-Gehäuse im rechten Winkel verlötet, dann drei ,,Haltestangen" an die besagten Pinne angebracht und die winkligen C's dazwischen gelötet.

Das übliche Flöhehüten eben mal wieder. Zudem sieht man die auch schon wieder huckepack montierte Empfangs-Platine, rsp. den Splitter von Platine mit Quarz und Antenne. Das Gewusel ist noch lange nicht beendet......
Grüße, picass

Noch ein Tipp, um die Pins von PICs im DIL-Gehäuse beim häufigen Ein- und Ausstecken (zum Programmieren) zu schonen:
Man steckt den PIC in eine einzelne Fassung und steckt diese "Einheit" dann zwischen Programmiergerät und Zielplatine um. Verbogene oder abgebrochene Beine des IC gehören damit der Vergangenheit an.

Gruß
PICkel

Bin fertig mit der Funk-Welt und habe mir eine gehörige Deprise eingefangen!
Heute kam die Lieferung mit den hochwertigen Kondensatoren, welche als Letztes noch fehlten. Die also an sorgfältig ausgewählten Plätzen eingelötet, alles kontrolliert, eingeschaltet, aber so recht wollte das nicht schalten. Noch während des kontrollierenden Messens wollte die Schaltung auf einmal 40 mA, vorher nur irgendwas in der Gegend von 2 bis 4.
Dann ging eine zerstörerische Suche los nach dem Verursacher: alles, was in den letzten Tagen sorgsamst zusammen gefügt war, wobei jede Leiterbahn und jedes Bauteil auf Optimierung abgeklopft und das auch häufig umgesetzt wurde, das wurde nun Stück für Stück entweder mit dem Lötkolben oder der Beißzange zerfleddert, rsp. von der Stromversorgung abgetrennt. Zum Schluss war nur noch der Eingangsbereich übrig vom +12 V Eingang bis zum Regler-IC, alles andere war im elektrischen Jehnseits.

Einer der beiden gestern hucke-pack auf dem Regler-IC montierten 0805-SMD-Kondensatoren hatte sich einen ohmschen Widerstand, anfangs von 20 Ohm, dann von 12 Ohm eingefangen!

Die Zerstörung alle dessen, was in den letzten Tagen mit viel Mühe fast liebevoll zusammen gestaltet wurde und das auch gänzlich ohne Rücksicht auf die Zeit, lähmt mich. Ich muss das beiseite legen und ganz was anderes machen.
Grüße, picass

Zitat von: PICkel in 20.03.2023, 17:13:53 CETNoch ein Tipp, um die Pins von PICs......zu schonen:

Herzlichen Dank für deine vorsorglichen Worte! Ist sicher 'ne gute Maßnahme, wenn häufige Wechsel abzusehen sind. Selbst habe ich mich seit Etlichem auf eine Methode eingeschossen, in welcher ich immer denselben Schraubendreher-Typ nutze - einen üblichen Polprüfer - und dessen Prüfspitze wechselseitig zwischen PIC-Gehäuse und Fassung schiebe, dann aber nur ein ganz klein wenig hoch hebele, die Seite wechsel und das mehrmals. Inzwischen berücksichtige ich beim Erstellen von Platinenlayouts bereits diese Hebelmethode und sorge dafür, dass keine höheren Bauteile an den Stirnseiten einer DIL-Fassung liegen.

Johannes, ach und klag.... auch die dritte Version will das Garagentor nicht hochziehen. Ist qasi wie die Vorige: es leuchten diverse für Kontrollzwecke verbaute LEDs, aber nix rührt sich, auch nicht nach Tastendruck. Es leuchten die LEDs für den Power-Mosfet, diejenige für das ganz rechts, d.h. zur Mitte der Platine hin montierte Relais und einer der beiden LEDs, welche reine Kontrollzwecke, aber keine funktionalen haben.
Mist, flixter, du bereitest dir da viel Arbeit. Bald geht es dir so wie mir gestern mit der Funktfernbedienung: Frust bis zum Abwinken.... tut mir leid, das wird auch 'ne hatte Nummer.
Grüße, picass

Zitat von: picass in 21.03.2023, 11:35:57 CETEiner der beiden gestern hucke-pack auf dem Regler-IC montierten 0805-SMD-Kondensatoren hatte sich einen ohmschen Widerstand, anfangs von 20 Ohm, dann von 12 Ohm eingefangen!

Heute einen neuen Anlauf genommen, alle montierten Bauteile runter, die Platine geputzt, die Verbindung zu den "Verbrauchern" wie µC und Funkplatine unterbrochen, sodass nur noch der Spannungsregler übrig blieb. Den mit neuen und klassisch-großen Block-Kondensatoren versehen, zwei der neuen Elkos eingelötet und das war's dann. Ein erneuter Schuss in den Ofen. Es hatte nicht nur - siehe oben - einen der 0805-C's erwischt, den mit 12 Ohm, sondern auch den Regler noch. Der ließ die Eingangsspannung von 11 Volt durch.

Das bedeutete das Ende! Zum einen war das ein Regler mit gänzlich ungewöhnlicher Pin-Belegung - ein gleiches oder nur ähnliches IC konnte ich bei Reichelt nicht entdecken - und damit war ein Ersatz nahezu ausgeschlossen, und zudem weiß nun auch niemand, ob die 11 Volt nicht schon vorher durchgekommen waren und somit den µC zerschossen hatten. Nun also der Wurf in die Tonne. Das war einfach zu billiges Material.

Da ich mit den Experimenten für eine Infrarot-Fernbedienung noch gänzlich am Anfang bin und niemand weiß, wie weit das führt, habe ich nun in den sauren Apfel gebissen und erneut eine Funk-Quetsche bestellt. Diesmal von einem deutschen Händler und das auch nicht zum Dumpingpreis. Das Innenleben wird dennoch wohl Chinaware sein, aber zumindest muss es dafür die übliche Gewährleistung geben.
War 'ne erneut bittere Lektion, immerhin wird das nun die dritte F-Quetsche. Einzig Positives: es wird nicht noch weitere Zeit einem schlechten Produkt hinterher geworfen.
Grüße, picass

EPILOG

zum Funkdrama:

Die rote LED sagt es: es funkt wieder!
Ihr könnt und müsst nun denken, was ihr müsst! Nach dem Abkneifen des Spannungsregler kniff ich auch großzügig noch weitere Bauteile ab, hatte ja eh' keinen Wert mehr.  :(  Und weil das so war und auf der Platine kaum noch was drauf war, hatte ich kurzerhand mit fettem Silberdraht die Spannungsversorgung für den µC wieder hergestellt und auch noch die Funkplatine hucke pack aufgesattelt. Und nu' funkt es wieder, so wie es sollte! Wiederholbar!

Weiß nicht, was ihr jetzt denkt. Weiß auch nicht, was ich jetzt......
Wie auch immer, jedenfalls Funk-Vorhang zu und Grüße, picass

Jetzt gehts der Platine für die Garagentorsteuerung an den Kragen! Alle Eingangsport wurden mit eher niedrigen Widerständen auf Plus gelegt....., es hatte da eine Anregung gegeben, die bislang verbauten wären  zu hochohmig. Gleichzeitig wurde die bisherigen, als Antenne, rsp. Eselsohren über die Platine raus ragenden Kohleschichtwiderstände wie es sich gehört durch SMDs ersetzt, was gut klappte, weil beidseits der Längsseite des PICs je eine Plus-Versorgungs-Leitung verläuft. Dann wurden die 4 Eingangs-Signale – Handschalter, Funkempfänger, 2x Endschalter – an den PIC-Ports getauscht, sodass nun alle 4 auf einen Schmitt-Trigger-Eingang laufen. Dafür muss natürlich an ca. 800 Positionen das Prog entsprechend angepasst, rsp. geändert werden. Also ca. 800.... oder so.... >:D
Die jüngsten Interrupt-Erfahrungen werden auch verarbeitet und der eh schon total gestrippte Funkempfänger – siehe oben -  soll nicht mehr via lange  Leitung angebunden werden, sondern direkt neben dem Gehäuse für den PIC.

Dann mal sehen, ob es wieder zu Eigenleben kommen sollte. Ach ja, und dann hat die Arbeit für eine sophisticated Version begonnen. Die Relais fliegen bis auf eines raus, das Motor-Ein-Aus-Schalten und Umpolen wird dann ein Spezial-IC von Infineon übernehmen. Bestellt ist es schon, bin mal gespannt, ob und wie das funktionieren wird.
Grüße, picass

Tolle Wurst: jetzt hab' an der Überarbeitung meiner Garagentor-Steuerung weiter gearbeitet und wollte nun mehr die bislang nicht aktivierte Funktion des Aufstoppens beim Schließen und dem Treffen auf ein Hindernis, gefolgt von dem Zurückfahren des Tores endlich einschalten: NIX !
Hatte fleißig Parameter des auftreffenden Laststromes und seiner Wirkung auf den nachfolgenden  ,,OPA335" und wiederum den darauf folgenden LM311 erst berechnet und dann in der hatten Praxis geprüft, also auf meinem Werktisch mit Netzgeräten usw. hantiert, und nun just eben hat ein Gang in die Garage alle Bemühungen ad absurdum geführt.

Ausgangspunkt aller Bemühungen war ein Studium meiner angefertigten Unterlagen über die Funktion der orig-Steuerungsanlage aus dem Jahr 2011. Da hatte ich mal ebenso fleißig Parameter gemessen, z.B. die auftretenden Ströme in verschiedenen Bereich beim Tor-Hoch- rsp. Runter-Fahren: ,,normal" bis 2,5 Ampere. Folglich wäre ein Wert von 3 A ein guter Ansatz, um den Überlastpunkt, rsp. denjenigen für das Einklemmen eines Fußes ins Fadenkreuz und als Punkt für die Umkehr zu nutzen. Wie gesagt: voll fleißig nun gerechnet, gemessen, gemacht....

Und gettz der Gang in die G.! Vorbei die guten, alten Zeiten der orig. Anlage, als der ,,Saft" aus einem fetten Transformator quoll! Seit Umstellung auf Solar-Panel-Stromversorgung und Sammlung der Elektronen im Auto-Akku wären zwar bei 12 Volt noch furchtbar viel größere Ströme möglich gewesen, alleine...., der MeanWell DC-DC-Wandler von 12 V auf 24 Volt kann Elektronen im 24-V-Bereich nur bis max. 2,1 A anschubsen....! Das reicht gerade für Normalo-Betrieb, aber ein Fuß in der Tür würde ihm keine müde Elektrone mehr aus seinem Energie-Beutel entlocken. >:(

Das komplette bisherige Konzept der Ermittlung des ,,Fuß-Punktes" ist damit Null und Nichtig! Frust! Und was nun? Mal überlegen, ja, ich glaub', ich hab's: Mehr Frust!
Grüße, picass

Wie wäre es mit einer schaltleiste? 

Du meinst sicher irgend so'n kleines Brett mit Microkontakten, welches unten an dem G-Tor angebracht wird und bei Auftreffen auf ein Hindernis entsprechend Signal gibt. Wäre ansich eine gute Idee, aber da unten ist kein Platz am Tor. Das schlägt zum einen unten in Drehrichtung direkt an einer Kante an, um korrekt zu schließen und zum anderen ist vertikal nach unten auch höchstens 3 Millimeter Luft. Das wird knifflig, aber vorerst werde ich weiter verzichten, war ja in den letzten Wochen des Betriebes auch so.
Nun ein neuer Beitrag von mir:

Ich wittere Verrat! Mindestens!
Das Bemühen um die Überarbeitung der Elektronikplatine für die Garagentor-Steuerung hatte für diejenige, welche tatsächlich in die G soll, gut geklappt. Nun sollten die Umbau-Arbeiten auch der Simultan-Platine zugute kommen. Klappte scheinbar auch prima, nur beim ersten Test – noch ohne PIC in der Fassung – ergaben sich gleich mehrere völlig unsinnige Pegel. So wurden ja diverse Pinne über 11 k Widerstände auf Plus gelegt und einigen noch ein Tantal mit 6 µF spendiert. Die eingestellten Spannungen lagen bei z.B. 1,6 Volt oder 2,5 V oder 3,2 Volt! Gut, die Beschaltung einer Hilfsplatine mit simulierten Endablage-Schaltern und deren Bestückung war aus den Augen geraten..., das ließ sich leicht korrigieren. Aber gerade die Simul-EA-Schalter machten nur Blödsinn. Das waren kleine Reedrelais, verbaut in teils sehr kleinen Kunststoffgehäusen.

Und diese RRs waren beide defekt. Es sind von Natur aus Schließer, nur dass diese nunmehr immer geschlossen waren. Über gut 2 Jahre hatte die Simul-Anlage prima funktioniert, incl. der beiden RRs. Aber nu' klebten bei beiden die Kontaktzungen zusammen, obgleich es keinen erkennbaren Grund dafür gab: zwei auf einen Streich defekt. Nach einer Runde Sich-Wundern wurde ein Ersatztyp ausgeschaut, vorsichtshalber vorher durch gemessen, alles in Ordnung. Der wurde dann zweimal eingebaut und schon wieder so'n blöder Pegel zwischen allen Digital-Welten! Schon wieder kontrolliert und gucke da: einer der gerade noch kontrollierten war auch schon wieder hin und fungierte als Kleber!

Was geht da ab bei diesen Reedrelais?! Sind euch solche Ausfallraten auch bekannt? Und dabei waren die ja keineswegs jahrelang im Dauereinsatz, nix, die ersten beiden hatten vielleicht 50 Schaltvorgänge, die beiden ,,Neuen" nur einen einzigen! Das kann doch nur Sabotage sein! >:(
Oder Sabotage! >:D
Grüße, picass

Kann es sein das ein zu hoher Strom durch die reed Relais geht und diese deswegen verkleben bzw. Schrott gehen? 

Das wäre ein guter Grund für dieses Desaster, alleine.... ich hab' dafür nicht umsonst den Konjunktiv gewählt. Durch diese R-Relais in der Simul-Anlage fließen nur die paar mickrigen Elektronen  des Steuerstromes direkt in einen PIC-Eingang. Da liegt jeweils ein 11 kO R nach Plus 5 Volt, vom dem auf die Relais, dann in den PIC. Das begründet einen "Strom-Stoß" von 0,5 Milliampere. NIX, das kann es nicht gewesen sein.
Aber zu dem Desaster mit den R-Relais gesellt sich in passender Weise mein nachfolgender Beitrag, den ich eben noch vor dem Lesen deines Beitrages erstellt hatte und der nun folgt:

Oben hatte ich u.a. von seltsamen "Digital"-Pegeln gesprochen. Das hat mich nun auch wieder Stunden gekostet. Da lag - wie vor - je ein 11 kO R von PIC-Eingängen nach Plus, was für eindeutige Ruhepegel sorgen sollte, und je ein kleiner Elko von etwa 4,7 µF war beigefügt, was dem Kontaktprellen entgegen wirken sollte. Aber es ergaben sich statt der erwarteten 5,0 Volt horrormäßige 3,6 Volt oder noch niedriger.
Gettz ist das auch geklärt: es waren die Tantal-Elkos - siehe Bild. An denen war nichts Auffälliges, die waren teils gebraucht, teils neu, alle immer richtig gepolt angeschlossen, die meisten vorher extra auf Kapazität getestet und: NIX ! Das war Kern-Schrott. Nach dem Ausbau und vor dem Kloppen in die Tonne nochmal mit dem guten Hameg LC-Meter HM 8018 getest: einwandfreie Anzeige der aufgedruckten Kapazität! Dennoch Kernschrott, die ließen sich nicht auf 5 Volt aufladen. Ach ja, deren Spannungsfestigkeit lag teils bei 35 Volt, das wars auch nicht. Einfach Schrott.
Watt'n Mist, das hält so eklig auf.
Grüße, picass

Hab' ich das richtig verstanden? Du lädtst die Tantals über 11kOhm auf 5V auf und schließt sie dann ohne Strombegrenzungs-R über einen Reed-Kontakt kurz?
Ist zwar immer nur ein kurzer Impuls, könnte aber zum Verschweißen der Kontakte genügen. Oder es wird aus den Kontaktzungen Material heraus"erodiert", das sich dann woanders ablagert. Und die Spitzen dieser Kraterlandschaft könnten dauerhaft Kontakt geben. 
Weiterhin mögen Tantal-Cs solche Stromspitzen nicht und könnten dadurch Schaden genommen haben. Einige 10nF keramisch genügen normalerweise zum Entprellen, wobei ein Schutzwiderstand in Reihe zum Kontakt immer gut ist.

Gruß
PICkel

Zitat von: PICkel in 25.04.2023, 14:07:07 CESTHab' ich das richtig verstanden?

Klares JAIN!
Die Schaltung hattest du richtig verstanden, aber die hat definitiv nicht zum Ausfall der Reedrelais geführt. Bislang waren an der Simul-Anlage nur zwei solcher Tantals vorhanden gewesen und die saßen beide nicht dort, wo ein Reedrelais angeschlossen war. Anders gesagt: zwei der defekten RRs waren bislang gänzlich ohne Kondensatorbeschaltung gewesen und das dritte defekte kam als Neuteil aus dem Vorratsfach. Da muss es also andere Gründe für das Kleben gegeben haben.

Was die zukünftige Handhabung nach der Schaltungsänderung angelangt und zwar den angesprochen Fall, dass Tantals keine abrupten Entladungen mögen......, je nun, habe mal in der Wikipedia geblättert und dort auch diesbezügliche Hinweise gefunden. Sofern ich das richtig verstanden hatte, war da in den arsch knappen Ausführungen zu diesem Thema von einem "Schutzwiderstand" von 0,3 Ohm die Rede. Hm.....
Der praktische Einsatz sieht im Moment ca. 6 Betätigungen des G-Tor-Antriebes pro Woche vor. Ob diese Zahl Anlass zur Sorge geben sollte? Ich schau mal, ob sich in die Schaltung da noch was rein schieben lässt, denke dann an z.B. einen 10 Ohm R.

Eher nebenbei bemerkt: die Simul-Anlage hat ebend den Betrieb wieder aufgenommen. Da war auf der Hardware-Seite recht viel geändert und die Software musste entsprechend angepasst werden. Dat löppt nu wieder! Nun steht der Gang in die G. an zum hatten Praxistest.
Grüße, picass

Zitat von: picass in 25.04.2023, 19:14:03 CESTDat löppt nu wieder!

Also fast! >:D

Der Motor wollte an der Endablage nicht stoppen und zudem lief er ,,falsch" rum. :o  Hm.....
Wie gut, dass es eine Simul-Anlage gibt und man damit statt im kalten Draußen, sprich in der Garage, voll schön im mollig warmen Kellerraum, der meine Werkstatt beinhaltet, werkeln kann. :P

Beim letzten Werkeln waren ja diverse ausgefallene Reed-Relais aufgefallen, dauernd musste da wieder eines ausgebaut und zum Wegwurf gebracht werden. Ad 1: Beim Kreuz- u. Quer der Strippen wurden die Kabel für die beiden Endablageschalter falsch angelötet. Und der falsche Motor? Vollzieht sich mir nicht so recht!

Ad 2:  Entweder war trotz richtigen Eintrags eines Binärwertes im Programm-Listening doch ein falscher in das HexFile rein gerutscht oder die ,,Merker"-Variable hatte sich beim Start des Programms wie auch immer von selbst auf ,,1" gesetzt. Man weiß es nicht,....man weiß es nicht!  Und – verdammich – ich will es auch gar nicht mehr wissen nach all dem Gestrampel. >:(

Jedenfalls sind die Kabel nun sortiert, der untere Endablagenschalter sitzt nunmehr wirklich unten und nicht mehr oben, etc.....,der Motor ist auch wieder ein  ,,Richtiger", und sogar die völlig abgewrackte und durch-gestrippte Funkplatine tut das, was sie soll. Also simul-mäßig alles im Lot!

Bis zum Aufeinandertreffen mit der schon erwähnten hatten Realität! ;)
Grüße, picass

Und die war noch "hatter" als vorstellbar!

Merde!

Da hatte ich mir so viele Mühe und Arbeit gemacht, die Hardware zu bearbeiten, das Prog zu prüfen und zu ändern (u.a. Belegung der Eingänge) einen Grundkurs in Interrupt-Technik absolviert, den Funkempfänger gestrippt und neu aufgebaut, das Alles heute in der Garage sorgfältig eingebaut, und es funktionierte prima.
Aber der Weg 'ne halbe Stunde später erneut in die G eröffnete den Blick in die grausige Wirklichkeit: Nichts, gar nichts war besser geworden. Die Schaltung zeigte dasselbe, vor Wochen entdeckte Eigenleben. Mal war alles ruhig, dann plötzlich lief es los - ein Stück weit, hielt aus auch nicht bekannten Gründen nach dem Stück'chen an, Pause, irgendwann dann.....
Watt'n Schrott, das sitzt ein ganz böser Wurm drin.

Bin leider ab morgen ein paar Tage unterwegs und kann in der Zeit mich nur ärgern über den neuesten Misserfolg, also fast nur ärgern.

Gesucht wird eine Methode, aufzuzeichen, was den Schlummer stört. Das Prog ist ja so ausgelegt, dass nach JEDER Aktion - auch wenn gewollt nur ein Stück'chen Bewegung stattfand - der Sleep-Modus angesteuert wird.
Irgendwie  müsste man erreichen, dass nach außen sichtbar der fatale Wecker angezeigt wird. Den PIC zu fragen, wird kaum möglich sein. In der G selbst sind kaum sinnvolle Kontrollmöglichkeiten aufzubauen, das Meiste scheitert daran, dass kein 230-V-Anschluss da ist, also ist nicht mal mein Oszi einfach einsetzbar. Und wenn ich den dortigen PIC einzeln entnehme oder die ganze Schaltung abbaue, ist ja gleich der Saft weg.

Ich bitte um Anregungen, wie man den Unruhestifter entlarven könnte.
Grüße, picass

Vielleicht kannst Du mal das ganze Programm mal hochladen, sowie den aktuellen Schaltplan. Dann werde ich mal darüber schauen ;)

Danke für das Angebot. Bin 1 Stunde vor Urlaubsabfahrt...., gerne danach. Bis dahin, Grüße, picass

Hallo pic18!

Wie du in meinem anderen Beitrag von heute evtl. schon gelesen hast, kneift mich nach der Rückkehr aus dem Urlaub ein neues und altes µC-Prob. Die Garagen-Sache wird natürlich auch weiter bearbeitet, da ich aber recht sicher bin, dass dessen aktuelles Prob mal wieder die Eigenschwingung des Funkempfängers darstellt, möchte ich erst geplante und im Urlaub ausgeschaute Hardwareänderungen ausführen, bevor ich mich der Software-Seite annähere. Will sagen: im Moment möchte ich die verfügbare Zeit für das Naheliegendere verwenden. Natürlich könnte ich dir das Prog in jetztiger Version rüber schieben. Allerdings würde ich das gerne schon noch etwas lesbarer aufbereiten, es gibt auch keinen vorzeigbaren Verlaufsplan und auch der Schaltplan bedarf etlicher Aktualisierungen. Ich will mich nicht drücken, im Gegenteil, ich freue mich ja über helfende Angebote, nur kneift es eben leider an anderer, aktueller Stelle.
Grüße, picass

Da sind die Früchte meiner jüngsten Bemühungen, der Garagentor-Steuerung die Unarten auszutreiben. Die vermute ich ja – wie vorher schon – bei der Funke, dem Empfänger. Daher wurde in dem ja alles rausgeworfen, was nicht völlig unverzichtbar war. Nunmehr hat der wieder – wie  vor schon – eine eigene 5-Volt Versorgung via einen 12Vauf5V-Regler, nur ist das jetzt ,,mein eigener". Der Regler ist umzingelt  von Kondensatoren, davor ein 1.000µF, dahinter (5V) ein Goldcap mit 0,2F und die beiden Entstörer sitzen so dicht an den Anschlüssen, da passt kein Papier dazwischen.
Große Hoffnung setze ich auf den 6-pol. schwarzen Knubbel auf der Lochraster-P. Der enthält einen Optokoppler und soll die dritte Leitung, die Datenleitung galv. abkoppeln. Von dem geht es auf einen nachtriggerbaren Monoflop mit vorgeschaltetem Schmitt-Trigger. Und so hoffe ich, es für den PIC akzeptabel aufbereitet zu haben. Das Prog wurde auch bearbeitet, den zwei Endablageschaltern wurde die Teilnahme am Interrupt verweigert, und Pausenzeiten der neuen Lage angepasst, rsp. verkürzt.
Wenn das Alles nichts hilft, brauche ich eine Anleitung zum BomXen bauen. Um das Prob mit dieser einen Garage ein für allemal zu klären. Bei die Gelegenheit: im vorletzten Satz bitte das "X" durch "b" in Gedanken ersetzen...., woll'n ja nicht, dass im Forum was hoch geht! >:D Räusper, meinen Dicken – was mein Auto ist – werde ich vorher raus fahren.
Das vierte Bilde zeigt reichlich Fädel-Verdrahtung. Da habe ich eine vorhandene Platine eines Steuer-PICs umfrisiert, um nicht noch 2 Wochen auf eine solche kleine P warten zu müssen.
Grüße, picass

Das neue Gesamt-Kunstwerk ist heute Vormittag eingebaut worden. Und es funktioniert. Also fast! Nach dem ersten kompletten Schließen ließ sich das Tor erst beim dritten Male überreden, hoch zu laufen und oben angekommen, hakte sich zudem mal wieder der Transportschlitten, welcher das G-Tor hinter sich her zieht, aus seiner Zieh-Ketten-Halterung aus. Letzteres ist aber ein nicht mit den Elektronik-Probs in Zusammenhang stehendes Ungemach. Das muss nur "einfach" besser kontaktiert werden. In hatten Fällen donner ich da 'ne Schraube rein, damit Ruhe herrscht.
Das Sich-Zieren beim Öffnen war nur beim ersten Male so, danach nicht mehr. Gerade noch erneut überprüft, im Moment sieht es nach Aufnahme des Normalo-Betriebes aus. Nicht unken.... wegen des Momentes. Ich stehe hier eh' schon hart angespannt bis zum Anschlag, ob und wie.......
Grüße, picass

Bislang ist alles ruhig geblieben. Die vielen argwöhnischen Blicke, ob das Tor wieder ein Eigenleben entwickelt und rum macht, zeigten das Tor in vorbildlich geschlossener Haltung. Und das Öffnen und Schließen "funkt" auch. Mal sehen, da wird noch Zeit benötigt.
Sobald eines der Progs für die Erstellung von Flussdiagrammen bereit für erste Arbeiten ist, wird das Garagentor-Prog dort im Verlauf rein gehackt. Da könnte dann - wenn jemand mag - mal jemand rein schauen. Ist vielleicht einfacher, als sich in ein unbekanntes Assembler-Listening zu verbrüten.
Grüße, picass