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!
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!
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