RFID Lese- und Schreibgerät, geeignet für Delphi

[himitsu]

Zitat:

Zitat von DJ-SPM (Beitrag 1178360)

Ich habe gerade mal nach OBIT gesucht und einen alten Thread "Zeiterfassung" gefunden, in dem du diesen Code auch gepostet hast. Ich nehme an, OBIT ist eine Marke oder?

Zitat:

Zitat von Bummi (Beitrag 1178372)

OBIT ist die Marke, Feig der Hersteller, aber ich denke der Markt in diesem Bereich ist recht groß.

Du meintest ja bestimmt OBID.
FECOM ... Mit welche Deplhi-Verison arbeitet ihr eigentlich?

Die Pascal-Header sind fast alle total veraltet, bzw. es gib teilweise noch garkeine.
Meistens aus dem Jahre 2005/2006 (FECOM, FEUSB, FETCP, FEFU) und bei Einem (FEISC) steht zumindestens ein Hinweis, aus dem Jahre 2011, drin, aber es wurde nicht gleich passend gesucht+ersetzt.

Zitat:

WICHTIG:
Bei Verwendung von Delphi XE sind Datenypen von "PChar" --> "PAnsiChar" zu ändern!!

Und einige zwischenzeitliche Änderungen der API wurden sowieso verschlafen.

Schade, daß man mit Delphi nicht direkt gegen die C++Header compilieren kann. (z.B. einfach die *.h als Unit einbinden)

Die neueren APIs ala FESCR und FETCL sind noch garnicht übersetzt (also seitens Feig.de ... gibt's nur als C++-Header)
und die C++-Klassenbibliothek FEDM kann man in Delphi sowieso nicht verwenden. (ist mir bisher auch zu aufwändig da mal zu schauen, ob man die DLLs nicht doch einbinden kann, aber hier wird ein einfaches Übersetzen der C++-Header bestimmt nicht ausreichen)

Bezüglich des Threads http://www.delphipraxis.net/183471-f...id-reader.html
bin ich jetzt mal dazu gekommen die Pascal-Dateien zu aktualisieren und die ersten Verbindungsversuche zu unserem Testgerät funktionieren so weit schonmal,
FETCP muß ich nochmal prüfen (aber ganz aktuell geht da nicht, da die Dokumentation und die C++-Header immernoch auf dem Stand von 02.02.00 sind, aber die DLL meint, sie sei bereits eine 03.00.00 :gruebel:)
Und FEISC fehlt auch noch. Für alles Andere gibt es bereits auch Wrapper, welche die Fehlerprüfung vornehmen (Fehlercodes in Exceptions umwandeln) und dazu noch PChar<>String, bzw. Pointer<>TBytes umwandeln (vorallem bei den Lese-Methoden).

[Captnemo]

Möglicherweise ist eine Anbindung per RS232 oder auch überhaupt per Kabel mal schwierig. In dem Fall könnte auch eine Lösung RFID-Leser<->Arduino<->WLAN. Arduino ist preiswert und laufen in der Regel recht stabil. Es gibt dafür auch Mini-USV's, die im Fall eines Stromausfalls dessen Funktion aufrecht erhalten. Gerade bei Türöffnersystemen wäre ja ein Stromausfall weniger schick.
Und statt eines Arduino könne man auch einen Raspi nehmen. Ist zwar jetzt keine fertige Lösung, aber ggf. auch mal einen Blick wert.

Hier mal 2 Seiten, die ich mir zwar jetzt nicht näher angeschaut habe, aber so überflogen wäre das ein Ansatz.
http://funduino.de/index.php/3-programmieren/nr-19-rfid
http://www.instructables.com/id/Ardu...tudio/?lang=de

Vorteil evtl. man könnte sich das Übertragungsprotokoll selbst schreiben, und bei einer Speicherung der Zugangscodes könnte der Adruino auch bei Netzwerkausfall oder Netzausfall einen Zugang ermöglichen.

[himitsu]

Die von Feig sollen, laut ein paar Sätzen in der Dokumentation auch via SPP (Bluetooth > Serial Port Profile) angesprochen werden können. (konnte ich so zumindestens aus einem der Bilder in deren PDFs erkennen)
Ich weiß aber nicht, ob es da schon Geräte für Bluetooth gibt.
USB im Android geht nicht. (nja, man braucht zumindestens Root-Rechte dafür, damit es gehen würde, da sonst keine Möglichkeit besteht den Treiber zu laden)

Ansonsten gibt es von Feig und Datafox auch Geräte für Anbindung per LAN und WLAN.