Antworten

Der Beitrag verursachte die folgenden Fehler, die behoben werden müssen:
Achtung: In diesem Thema wurde seit 120 Tagen nichts mehr geschrieben.
Wenn Sie nicht absolut sicher sind, dass Sie hier antworten möchten, starten Sie ein neues Thema.
Einschränkungen: 8 pro Beitrag (8 verbleibend), maximale Gesamtgröße 8,79 MB, maximale Individualgröße 1 MB
Entfernen Sie den Haken der Dateianhänge, die gelöscht werden sollen
Klicken Sie hier oder ziehen Sie Dateien hierher, um sie anzuhängen.
Anhänge und andere Optionen
Verifizierung:
Bitte lassen Sie dieses Feld leer:
Geben Sie die Buchstaben aus dem Bild ein
Buchstaben anhören / Neues Bild laden

Geben Sie die Buchstaben aus dem Bild ein:

Tastenkürzel: Alt+S Beitrag schreiben oder Alt+P für Vorschau

Zusammenfassung

Autor picass
 - 08.06.2021, 14:56:47 CEST
Es kann schon enervierend sein, nach der Nicht-Funktion in einer Schaltung den Fehler zu suchen!
Dieses gilt ganz sicher auch für den Fall, dass gar kein Fehler vorhanden ist. Tatsächlich war ich über meinen Versuch gestolpert, sorgsam vorzugehen und nach wichtigen Teil-Arbeitsschritten diese gleich zu prüfen, um nicht später in einer angewachsen und komplexeren Umgebung ganz kalt erwischt zu werden. Also wurde beim Erstellen der benötigten Gruppierung – bestehend aus gesamt drei Boards  - zunächst das Erste geprüft, der ,,kell-pic" und auch gleich das darauf laufende Prog. Alles Paletti. Dann das Duo ,,roll-pics", und vor dem Huckepack-Zusammenbau diverse Grundfunktionen jeder Platine. Alles gut. Dann der Huckepack-Bau und das Aufbringen des angepassten Progs und natürlich sollte dieses Huckepack-Duo sofort geprüft werden. Nix gut ! Das war echt nicht gut! Die Hardware war eher unverdächtig, aber das Prog machte, was es wollte, insbesondere verweigerte es die vorgesehene sofort anfängliche Sleep-Phase.

Muss gestehen, dass es mich erfolgreich verwirrte, weil im Simulator alles prima war, und es mir nicht gelingen wollte, den Fehler zu packen. Bis mir nach Einfügungen im Prog und dem Einbau von Kontroll-Leds es so nach und nach dämmerte, dass....
Der empfangende PIC im ,,Roll-Duo" sollte für den Test-Anfang nur auf zwei Ereignisse hin tätig werden, auf zwei Tastendrücke. Der war aber weit fleissiger als erwartet, schließlich schlummerte weiter hinten im Prog die schon für später vorgesehene Routine, welche den Port-Eingang abfragte.
Und dann hatte ich die Rechnung ohne den Wirt namens MAX gestellt! Weil ja nur das frische ,,roll-duo" quasi als frisches Teilprodukt auf evtl. frische Fehler untersucht werden sollte, wurde auch nur dieses Duo in Betrieb genommen. Will sagen: Das Dilemma begründete sich, weil sowohl der Bus als auch die Schaltzentrale als dritte Schaltung nicht mit im Bunde dabei waren. Der unbebusste Eingang des MAX war offen und lag wegen der MAX-Einstellung auf ,,0". Das produzierte dann eine ,,1" vom MAX zum PIC, und dieser arme, aber gute Kerl hielt das für ein Daten-Eingangssignal, wachte - kaum dass er überhaupt in den Schlaf gefallen war - auch sofort schon wieder aus seinem Schlummer auf und schon legte die für später vorgehaltene Bus-Abfrage-Routine los. Und die wartete nach dem Wecksignal auf das erste Daten-Bit und wartete und wartete.......

Hätte ich doch gleich das Dreierpack zusammengefügt, wäre dieser Schlammasel an mir vorüber gegangen. So hatte mir ausgerechnet das Bemühen um sorgfältiges Vorgehen und gründliche Kontrolle von Teilergebnissen diesen Bus- Strich durch die Rechnung gemacht.
Grüße, picass
Autor picass
 - 05.06.2021, 13:08:58 CEST
Mist, flixter! Die Prototypen1-Anlage für die Werkstatt funktioniert in allen Belangen, nun sollten die ersten drei Prototypen2 erstellt werden für den Einbau im Haus, aber nix: es steckt ein Wurm drin! Die Anlage besteht wie beschrieben aus der zentralen Steuereinheit – Arbeitsname: ,,kell" – und den beiden Rundplatinen ,,rollk" und ,,rollp", die huckepack übereinander montiert sind. Als Letztes wurde das Steuerprogramm für den ,,rollk" einprogrammiert, dessen PIC tut auch was, aber leider nicht das Erwünschte. Und dabei ist dessen Prog quasi nur eine nur wenig geänderte Teilmenge desjenigen Progs, welches im Steuer-PIC prima seine Arbeit verrichtet. Die Hardware funktioniert bestens, ist mehrfach getestet, aber im Prog tummelt sich ein Wurm! Voll der Horror das! Im Simulator wurde mehrfach simuliert, und dort läuft alles so wie vorgesehen. Nur im PIC klappts nicht. Is klar, dass die Programm-Entwicklungs-Version die Nummer 13 trägt!
Grüße, picass
Autor picass
 - 09.04.2021, 12:12:10 CEST
So recht mag ich's noch nicht fassen: es ist geschafft!
Vor einer halben Stunde hat sich auf meinem Werktisch dieses ereignet:

Der PIC für die zentrale Steuerung – µC-Kosename (falls es so was gibt) lautet ,,kell-pic" – hat wie üblich gepennt. Auf Tastendruck (alle Rollladen hoch) ist er aufgewacht, hat die Taste erkannt und einen entsprechenden Befehl an den verbandelten MAX481 gegeben. Der das Ganze über Zweidrahtleitung transferiert an sein Brüderchen, der dieses Ganze am ,,roll-pic" abgeliefert. Jener – is klar – pennte genauso, hat aber wohl was gemerkt, nach dem Störer geschaut, ihn auch ausgemacht und sich ausnahmsweise dazu entschlossen, einen Steuerbefehl an die darüber liegende (das kommt später) Powerplatine zu senden. Dort wird zunächst über einen Winzig-Trafo für ausreichend eigene Power gesorgt – siehe grüner Pfeil auf die Kontroll-LED – und dann über einen Opto-Triac der Rollladenmotor – ähm, hier zwei 230-Volt-Lampen – angeworfen. Is auch klar, nach der Kraftanstrengung tritt alles wieder einträchtig zum Schlummern ab.

Geschafft!
Natürlich ist das Programm lange nicht fertig, und es wird aus diversen Gründen auch noch was dauern, aber..... aber alle 3 Einzel-Platinen arbeiten und das sogar miteinander, der Simulator in der MPLAB-IDE simuliert und – ach ja – stimuliert, in dem Programm-Dschungel ist ein Pfad angelegt worden, und zumindest beschlägt mir nicht mehr die Brille, wenn ich in das PIC18Fxx-Datenblatt reinschaue.

Im Moment bin ich im Zustand des Glücklichen....., was gleich noch verstärkt werden wird. Da verkoste ich einen Schluck eines 10 Jahre alten Portweins, das ist aus meiner Sicht bei diesem Anlass gerechtfertigt. Bei allen, die mir zu diesem Erfolg mit geholfen haben, möchte ich mich sehr, sehr herzlich bedanken, auch und insbesondere für euren Langmut, wenn ihr euch mit meinen Eingewöhnungsfehlern auseinander setzen musstet. Danke. Hab' jetzt aber keine Zeit mehr für evtl. Sentimentalitäten....., Abgang zur Flasche!
Prost, picass
Autor picass
 - 06.04.2021, 10:33:45 CEST
Auch der Prototyp für die dritte Platine ist fertig. Damit sind nun alle drei Teilplatinen in gebrauchsfähigem Zustand. Das war kein reiner Grund zur Freude, denn bei den Probetests, rsp. den ersten Inbetriebnahmen zeigten sich doch "Unterlassungen" oder auch Fehler: mal war ein Port-Pin hardwaremäßig falsch belegt, mal fehlten zwei Dioden.., oder es wurden schlicht doch noch Stiftleisten für bequemeren Anschluss nachgerüstet, so z.B. an der dritten P rechts der Programmier-Sockel. Prototypen halt..... , aber sie funktionieren alle und sind auf dem angestrebten Stand.
Nun hebt das Testen des Zusammenspiels und das Schreiben des Steuerprogs an, schwitz, das wird noch was werden....
Grüße, picass
Autor picass
 - 01.04.2021, 18:18:14 CEST
Heute ist "morgen", will sagen, der erste Versuch der Programmierung einer eingelöteten MSOP-Version eines PICs hat stattgefunden. Is klar, das wollte erst nicht. Warum nicht, dazu später mal. Aber im zweiten Anlauf klappte es und dann passierte es: eine LED leuchtete. :D
Die Freude eines Mannes über das Leuchten einer einzelnen LED können viele Frauen - auf jeden Fall meine - nicht nach vollziehen. Und nein, es ist nicht "Hello World", stattdessen mein erstes kleines Rumpf- u. Test-Programm. Das LED-Leuchten bedeutet, dass die frisch erstellte Steuerplatine nun wirklich fertig und funktionabel ist, dass das Grundprog in Ordnung ist, dass auch der PICkit3-Programmer nicht defekt ist, wie ich zwischenzeitlich befürchtete, und dass nun der "Rest" des Steuerprogramms in Angriff genommen werden kann, und "nur" noch eine Zeitfrage sein wird. Ach ja, noch was bedeutet es: alles kein April-Scherz, eine LED kann nicht lügen.
Grüße, picass
Autor picass
 - 31.03.2021, 17:32:06 CEST
Der Prototyp für den Steuer-PIC ist fertig. Als Platine gibt es ja schon eine erkennbar weiter entwickelte Version, hier habe ich noch eine Vorversion genommen und da Etliches nachgerüstet, z.B. die Stiftleisten-Anschlüsse. Beim Nachrüsten kommt man kaum um Fädeldraht rum. Dafür ist der echt gut, wenn nicht dieses vermaledeite Fädeln wäre. Bis der Draht mal so will, wie man möchte.....
Ist halt ein Prototyp, der entspricht jetzt aber technisch der neuesten Version und morgen hebt es mit dem Versuch der ersten Programmierung des eingelöteten MSOP-PICs an.
Der blaue Jumper hat 'ne nette Funktion: So, wie er jetzt steckt, gibt er den RA4 für die hohe Programmierspannung frei. Wenn man die Platine umrüsten will zwischen Programmieren und normalem Betrieb, dann muss nur dieser Jp umgesteckt werden. "Normal" ist dann RA3 für einen möglichen Hardware-Reset zuständig.
Grüße, picass
Autor picass
 - 28.02.2021, 09:51:38 CET
Nix ist dann gut! >:(
Habe nach dem ersten Musteraufbau einen Schock beim Einschalten des Netzgerätes gehabt und dann begonnen, den vermuteten Fehler in der Schaltung zu suchen, weil da über 80 mA gezogen wurden. Schaltblätter gewälzt, auf Fehlbeschaltung kontrolliert, bis ich endlich den Taschenrechner anwarf und ausrechnete, dass der Stromverbrauch auf diese R's zurück zu führen war. Und das brachte dann doch Fragen auf. So hatte ich in all den Steuerschaltungen pro Rollladen einen Winzigtrafo mit max. 100 mA vorgesehen. Da kämen dann noch zwei Optokoppler-LEDs mit je 10 mA ins Spiel, und schon wirds drubbelig.

Deshalb hatte ich die in Datenblättern vorgehaltenen 120 Ohm R's gleich mutig gegen solche mit 390 Ohm ausgetauscht. Danach war der Strombedarf wieder passabel. Am Oszi konnte ich keinen Unterschied ausmachen, allerdings fehlen auch noch die vielen dann parallelen Abzweige der Gesamtzahl an Steuerschaltungen. Hoffe darauf, dass die angepeilte niedrige Übertragungsfrequenz irgendwo zwischen 10 bis 20 kHz das so akzeptiert.
Wäre ein eigenes Thema wert, mal sehen, bin da noch am Anfang.
Grüße, picass
Autor pic18
 - 27.02.2021, 16:03:22 CET
Hast recht, es geht nur um die Spannungsdifferenz. Ich war bei RS232. Am Ende noch ein Abschlußwiderstand von 120 Ohm. Gut ist es.
Autor picass
 - 27.02.2021, 14:44:10 CET
Kannst du einen Grund dafür benennen? Es ist schon putzig, dass die Übertragung auch ganz ohne Masse-Bezug funktioniert. Der Empfänger reagiert offenkundig nur auf die Differenzspannungen. Da beides funkt, ist das aber für mich kein Anlass, lange zu grübeln. Wahrscheinlich werde ich den GND-Punkt des "Keller-PICs", das ist derjenige, welcher vom Keller aus die Zentral-Steuerung innehat, mit dem Abschirmgeflecht verbinden, um ggf. einen Teil von Außen-Störungen abhalten zu können. Oder ich verknüpfe den mit dem Erdleiter des Hausstromnetzes, was allerdings dazu führen würde, dass in dem gekauften Datenkabel kein Leiter für GND mehr verfügbar wäre. In beiden Fällen würde an den Empfängern nicht durch verbunden. So meine bisherige Vorstellung.

Inzwischen sind die hoffentlich letzten Versionen der drei benötigten Platinen eingetroffen. So langsam wirds ernst.
Grüße, picass
Autor pic18
 - 27.02.2021, 09:50:26 CET
ich würde auf jeden Fall die Masse mit verbinden.

Similar topics (1)