Filtertreiber mit externer Verrigelung



  • Ich habe einen Filtertreiber für USB Eingabegeräte geschrieben (bzw. eine Vorlage erweitert), mit dem man die Eingabegeräte gegeneinander verriegeln kann. Da dieser im Maschinenbau zum Einsatz kommt, soll nun verhindert werden, das die Eingabegeräte gewechselt werden während jemand die Maschine am einrichten ist. Dies soll durch ein externes Signal geschehen. Es soll bei jeder Tastatur ein Schalter hin, den man betätigt, wenn man die Umschaltung deaktivieren will.

    Kann mir jemand einen Tip geben, wie man so etwas realisieren könnte oder hat jemand andere Lösungsvorschläge. Ich bin auf dem Gebiet der Treiberprogrammierung ein absoluter Laie. [cpp]



  • Also Treiberprogrammierung hat schon mal nichts mit Winapi zu tun... Ich versteh auch nicht, was du meinst. Irgendwie kann ich mir jetzt kaum was konkretes drunter vorstellen.



  • Aus reinem Interesse: muss man bei einer solchen Bastelei sich eigentlich kein Gedanke bezüglich der Betriebssicherheit machen? Gibt es hier evtl. Rechtliches, was man beachten müsste?



  • (Windows-)Treiberprogrammierung hat eigentlich schon recht viel mit WinAPI zu tun.
    Ich verstehe nur auch überhaupt nicht was gemeint ist.



  • hustbaer schrieb:

    (Windows-)Treiberprogrammierung hat eigentlich schon recht viel mit WinAPI zu tun.
    Ich verstehe nur auch überhaupt nicht was gemeint ist.

    Ich würde als WinApi nur die Userspace Funktionen bezeichnen und nicht die Kernel Schnittstelle, aber wo dus sagst, bin ich mir in der Tat nicht sicher, ob die nicht auch dazuzählen.



  • Keine Ahnung ob die Kernelmode-API offiziell zur WinAPI gerechnet werden.
    Ich meinte nur: die Kernelmode-API und die Usermode-API sind sich bei Windows an vielen Stellen so ähnlich, dass ich nicht sagen würde dass das eine mit dem anderen nichts zu tun hat.

    Und etliche der Kernelmode Funktionen kannst du aus dem Usermode genau so aufrufen -- auch wenn es kaum jmd. macht.



  • Ich versuche, das Problem näher zu erklären:

    Wir bauen Maschinen und in diesen Maschinen sind für die Bedienbarkeit mehrere Tastaturen und Mäuse (z.B. eine vorne und eine hinten) eingebaut, um die Maschine leichter bedienen zu können. Damit aber immer nur eine Tastatur und Maus aktiv ist, wird der Filtertreiber eingesetzt. Das funktioniert auch soweit. Das Problem ist nun, wenn einer hinten an der Maschine was am einstellen ist und nun vorne einer was machen will (z.B. eine Achse verfahren), so soll dies nun verriegelt werden. Dazu soll der Bediener an "seiner" Tastatur einen Schalter betätigen und solange wie dieser Schalter betätigt ist, darf der Treiber eine Umschaltung nicht erlauben. Die Frage ist nun, wie man im Filtertreiber an ein solches "Signal" kommt und verarbeiten kann.



  • d.h. du willst verhindern, dass jemand hinten eine Eingabe macht während ein anderer Bediener vorne irgendwas macht? Dazu soll dann der Bediener vorne sowas wie einen Schlüsselschalter haben, damit ihm die Tastatur nicht geklaut werden kann?

    Um das umzusetzen wäre es IMHO am einfachsten irgendeinen Pin vom seriellen Port zu nutzen, auf den man die Schalterstellung per Koppelrelias legt. Vermutlich dürftet ihr ja aber auch eine SPS einsetzen und deswegen würde ich dem Bedienprogramm auf dem PC einfach von der SPS aus irgendwelche Nachrichten schicken, die dann an den Treiber weitergereicht werden können.


  • Mod

    Was sprichte dagegen eine Tastenkombination zu nemen.
    Oder ein Timeing zuzulassen. d.h. ca. 30sec. nach der letzten Eingabe wirddie Freigabe erst für die andere Tastatur geben.

    Wenn es eine normale Tastatatur ist könnte man auch die "Rollen"-Taste zweckentfremden, die ist ja sticky!



  • Nimm einfach einen Taststus/Maus-Umschalter.... den kann man per Tastatur dann umschalten...



  • +1 für Scroll-Lock



  • Ich habe gelesen, das man mit der DeviceIoControl API zwischen einer Anwendung und einem Treiber kommunizieren kann. Jetzt habe ich aber auch gelesen, dass dies bei Tastatur und Maustreibern nicht gehen soll, da man dort kein 2. Handle öffnen kann. Stimmt das?



  • 2x richtig.
    Also ob konkret Maus und Tastaturtreiber auch von dem "kein 2. Handle" Limit betroffen sind weiss ich nicht, aber es gibt diese Fälle auf jeden Fall.

    Um das zu umgehen ist die übliche Lösung dass der Treiber ein Dummy-Device registriert. Das Dummy-Device kann man dann mit CreateFile aufmachen, und mit DeviceIoControl Control-Messages hinschicken.
    Und das Dummy-Device leitet diese Messages dann an den Treiber weiter.



  • Kannst Du mir zeigen, wie man so etwas programmiert?



  • Nö, ich weiss das nimmer auswendig, und ich hab auch keinen Link mehr parat wo das gezeigt wird.

    Es sollte aber ein Sample im DDK geben wo man sieht wie man das macht.
    Was ich mich erinnere unterscheidet es sich auch nicht grossartig davon wie man einen "software-only" Treiber implementiert, nur dass man dem Dummy-Device-Objekt das man erstellt eben einen Zeiger oder ein Handle auf das "eigentliche" Device-Objekt mitgibt, damit es mit diesem kommunizieren kann.

    Guck mal im DDK, oder ansonsten frag im OSR-Online Forum nach - da tummeln sich ein Haufen Leute die relativ viel Erfahrung mit Treiberprogrammierung haben, die können dir vermutlich besser helfen.


Log in to reply