[VB.NET] Callbacks und Threads

[Plenz]

Allgemeine Frage: bekommen Callbacks einen eigenen Thread, oder kann es vorkommen, dass Callbacks verzögert verarbeitet werden, wenn das Hauptprogramm gerade voll beschäftigt ist?

 

Ich baue gerade eine Motorsteuerung mit dem IO16. Während der Motor läuft, kann ein Schalter betätigt werden, was zeitkritisch erkannt werden muss, egal womit der Computer gerade beschäftigt ist. Ist das Beispiel mit dem Callback für den IO16 in der Docu dafür geeignet, oder sind irgendwelche zusätzlichen Maßnahmen erforderlich?

 

Ich bin leider weit davon entfernt, ein VB.NET-Spezialist zu sein, und mit solchen Themen wie Threads und dergleichen tue ich mich echt schwer.

[photron]

Callbacks werden von einem eigenen Thread abgearbeitet. Unter normalen Umständen sollten Callbacks ohne weitere Verzögerung abgearbeitet werden.

[Plenz]

OK, danke! Dann habe ich vielleicht ein anderes Problem, jedenfalls werden manche Schalterwechsel nicht registriert. Ich muss dazu sagen, dass es sich um einen Microschalter handelt, der teilweise nur sehr kurz betätigt wird. In den Datenblättern von Microschaltern habe ich noch nirgendwo eine Angabe über eine minimale Betätigungsdauer gefunden, aber ich gehe davon aus, das der Schalter tatsächlich betätigt wird.

 

Die Frage wäre also, wie der IO16 intern funktioniert. Kann es vielleicht sein, dass die Eingänge mit einer gewissen Frequenz regelmäßig abgefragt werden, und wenn ein Eingang kürzer auf "1" liegt als die Zeit zwischen zwei Abfragen, dann wird das nicht registriert? Falls dem so ist, sollte ich vielleicht mal versuchen, den Schaltimpuls mit Hilfe eines Kondensators zu verlängern?

 

Ich weiß "Versuch macht kluch", aber für die nächsten 2 Tage bin ich zu weit weg von der Bastelei und möchte die Sache schon mal im voraus klären.

[photron]

Der Port Extension Chip auf der IO-16 reagiert auf Interrupts und speichert sich diese. Das Bricklet fragt dann den Zustand des Interruptregisters des Port Extension Chip periodisch ab und sendet entsprechende Callbacks. Da sollte eigentlich kein Interrupt verloren gehen.

 

Die Standard Debounce Period sind 100ms. Zwei Interrupts zwischen denen weniger als 100ms liegen werden als einer gewertet. Wenn du schnelle Interruptfolgen mit weniger als 100ms Zeit zwischen den Interrupts erkennen willst musst du die Debounce Period kleiner stellen.

[AuronX]

Callbacks werden von einem eigenen Thread abgearbeitet. Unter normalen Umständen sollten Callbacks ohne weitere Verzögerung abgearbeitet werden.

 

Noch ein kurzer Disclaimer, weil Plenz seine Schwierigkeiten mit Threads angedeutet hat: Während du einen Callback verarbeitest läuft dein Code im einzigen Thread der Callbacks ausliefert. Das heißt wenn du dort lange rechnest, dann verzögert das schon die folgenden Callbacks. Wenn deine Hauptarbeit im Main-Thread läuft und deine Callback-Verarbeitung schnell geht, dann ist das aber alles kein Problem ^^

[Plenz]

Die Callback-Routine prüft nur, ob der Interrupt durch High oder Low ausgelöst wurde, und bei High wird eine globale Variable auf True gesetzt, die regelmäßig vom Hauptprogramm abgefragt wird.

 

Die Debounce-Zeit hatte ich schon auf 1 gesetzt, das sollte aber nicht das Problem sein, denn der Eingang ist lange genug auf Low, nur nach dem High kann sehr schnell wieder ein Low kommen.

 

Nun gut, ich danke erst mal für die Antworten. Die Software-Seite ist also offensichtlich nicht das Problem. Dann muss ich wohl erst mal mit einem Oszilloskop testen, ob der Schalter bei sehr kurzen Betätigungen überhaupt schaltet. Notfalls muss ich ihn halt durch eine Gabel- oder Reflexlichtschranke ersetzen.