Hallo zusammen, ich soll in einem Praktikumsversuch einen Arbeitsplatz neu machen: Der Versuch hat mit Bedienerschnittstellen zu tun. Vorher waren alte PCs mit Windows 98 und Bedienergeräte wie Barcode Reader, Lesestift, Magnetkartenleser usw über COM Port an den PC angeschlossen. Auf diese Geräte wurde dann in einem C Programm zugegriffen, bzw auf die Daten die da versendet worden sind. Der Versuch soll jetz an einem Windows XP Rechner stattfinden, die Geräte alle von COM auf USB umgestellt werden. Jetzt meine Frage : gibt es eine Möglichkeit auf die versendeten Daten vom USB zuzugreifen? Es ist egal ob in einem C-Programm, virtueller Com Port , über FTDI Chips, wie auch immer, und wenn ja bitte mit Lösungansatz. Falls euch Angaben fehlen einfach posten. Dankesehr, yrkeul...
Wenn die einen echten RS232 Anschluss hatten, also kein Bitgewackel auf der Leitung, dann ist die einfachste Möglichkeit ein USB zu RS232 Umsetzer, der wird völlig transparent über einen virtuellen COM Port angesprochen, also keinerlei Änderung an der Software nötig.
Hatte ich vergessen mit in den Beitrag zu schreiben, die alten Geräte sind zum größten Teil hin und es sollen neue Geräte mit nur USB Anschluss verwendet werden.
Achso. Naja, dann bau einen USB-Serial Chip ein. Das ist die einfachste Möglichkeit. Entweder FT232R oder den CP2101 oder sowas. Die gehen ziemlich gut, nicht ganz so stabil laufen die Prolific Chips. Jedenfalls haben wir die Erfahrung gemacht. Am zuverlässigsten klappt der FTDI.
Kannst du mir noch erklären wie du das mit dem einbauen meinst? Gerät aufschrauben und dann einen Chip einlöten, oder gibt es die Möglichkeit einen "USB-Adapter" zu bauen und zu verwenden, den ich in die USB Leitung sozusagen zwischenstecke. Danke.
Ich denke, ihr wollt die Geräte neu bauen? Oder wollt ihr neue Geräte kaufen, die dann eine USB Schnittstelle schon von Werk aus haben? Wenn ihr selbst die Geräte baut, dann könnt ihr den FTDI Chip gleich mit einbauen. Wenn ihr Geräte kauft, die schon eine USB Schnittstelle haben, dann müsst ihr mit dem leben, was der Hersteller eingebaut hat. Entweder hat er auch einen virtuellen COM Port über USB, das wäre dann einfach. Kann aber sein, dass der Hersteller irgendeinen anderen USB Chip eingebaut hat, dann seid ihr auf das API des Herstellers angewiesen, um mit dem Gerät zu sprechen. Das zieht evtl. große Änderungen der Software nach sich. Oder aber ihr kauft die Geräte wie bisher mit serieller Schnittstelle und baut einen ganz gewöhnlichen USB zu RS232 Adapter ins Kabel. Das ist ein fertiges Gerät, einfach anstecken und gut. Das sieht dann zum Beispiel so aus: http://www.reichelt.de/?;ARTICLE=81743
Habe ich denn bei den Geräten mit normaler RS232 Anbindung und dann anschliessen mit dem Adapterkabel dann einen ganz normalen COM Port in meinem Geräte Manager oder läuft das dann auch über eine virtuelle Schnittstelle? Das ganze soll halt vom Umfang her nicht ausaten und bevor man sich da in die Tiefen der Programmierung vorwagen muss, kann man dann ja auch auf alt bewährtes zurückgreifen. Auf jedenfall schonmal danke für deine Anregungen!
Christian L. wrote: > Habe ich denn bei den Geräten mit normaler RS232 Anbindung und dann > anschliessen mit dem Adapterkabel dann einen ganz normalen COM Port in > meinem Geräte Manager oder läuft das dann auch über eine virtuelle > Schnittstelle? Es ist zwar ein virtueller COM Port (klar ist ja kein echter), aber im Gerätemanager genau wie ein echter, also COM2, COM3 usw. lässt sich auch genauso ansprechen und verhält sich genau so. Die Sofware muss nicht geändert werden.
> Die Sofware muss nicht geändert werden.
Sofern nur die Schnittstellen(namen) verwendet werden, die die alte
Software ansteuern kann. Windows unterstützt zwar 256 serielle
Schnittstellen, entsetzlich viele Programme aber können nur COM1..COM4
ansprechen, weil deren Entwickler mit der Kneifzange gedacht haben.
Da muss man halt die virtuellen COM Ports auf COM1 bis 4 legen. Und dann gehts. Wenn die Entwickler die serielle Schnittstelle als solche benutzt haben. Was aber bei solchen Geräten der Fall sein dürfte.
Ich versuche jetz Schritt für Schritt den Versuch neu aufzubauen, da ich
erstmal denke, wenn es mit einem Gerät funktioniert, wird es bei den
anderen Eingabegeräten nicht sehr viele Veränderungen geben, wie man
dann an die Daten kommt.
Hab mich jetz mal ausführlich mit dem Barcode Reader über USB
beschäftigt. Dieser funktioniert wie eine einfache Tastatureingabe, was
im C-Code über den scanf("%s", &string[x]); einfach eingelesen werden
kann. Anschliessend soll dann der eingelesen Barcode mit einer Datenbank
verglichen werden, und bei erfolgreichem Vergleich ein Bild geöffnet
werden. Da ich noch ein altes Gerät mit RS232 Anschluss habe, kann ich
auch altes Programm, neues Programm miteinander vergleichen.
Das einlesen funktioniert bei beiden Programmen. Der Dateiaufruf aber
nur noch bei dem neuen Programm, ich glaube das dies an Windows XP
liegt.
In dem neuen Programm verwende ich die <prozess.h> und die Funktion
system("Datei.tif"), dies funktioniert auch. Bei dem alten Programm
greife ich noch auf eine selbst geschriebene header-file "seriell.h"
zurück, welche aber nur im DOS-Ausführungsmodus funktioniert. Sowohl mit
dem Funktionsaufruf
system("Datei.tif"); als auch
spawnl(P_WAIT,"view","view","Datei.tif",NULL); kann ich nicht die Datei
aufrufen. Kann mir an dem Punkt jmd. noch Tips geben?
Die headerfile "seriell.h" habe ich einfach mal angehängt.
Nun zu den vorschlägen von vorher: Die Lösung für RS232 Geräte mit einem
USB seriell Adapter funktioniert einwandfrei und wird wohl für dieses
Projekt die einfachste Sache sein. Auch das einstellen der COM-Ports ist
kein Problem. Wenn dasa Projekt komplett fertig ist, werde ich das
natürlich mal posten, damit man sich ein kleines Bildchen davon machen
kann, was alles geändert worden ist.
Hatte vergessen die Datei seriell.h anzuhängen. Dankesehr für weitere Hinweise!...
Vergiss die Interrupts, heutzutage geht das so: createFile( "\\.\com11", ... );
Und wenn CreateFile auch noch richtig geschrieben wird, dann gehts erst recht.
Kann ich mir dann die ganze seriell.h sparen oder wie macht man das mit der CreateFile() ? Dankesehr...
Ja, "seriell.h" ist damit hinfällig. CreateFile ist eine Win32-API-Funktion, und wie man damit serielle Schnittstellen anspricht, wurde in diesem Forum ad nauseam diskutiert.
Komme irgendwie nicht mit CreateFile() zurecht...
Kann mir das bitte jmd nochmal erklären, auch wenn es hier im forum
schon öfter diskutiert wurde...?
Habe also die Funktion CrateFile(...), da muss ich jetz aber noch
irgendwie die Parameter meines com Ports unterbringen, oder?
CreateFile ("COM1", GENERIC_READ, 0, NULL, OPEN_EXISTING, 0, NULL)
wenn ich es also erstmal richtig verstanden habe.
Möchte also nur lesen und nur vorhandenen öffnen.
Doch wie arbeite ich jetz damit weiter? Muss ja jetz noch die Daten
einlesen und dann hinterher wieder den ganzen Spass schliessen wenn ich
an meine Daten gekommen bin...
Dankesehr für weitere Hilfe....
Es gibt für diese Aufgabenstellung ausreichend Codebeispiele.
Hallo supachris, wenn ich das richtig sehe ist das aber C++ Code, kann ich das einfgach so in C-Code auch verwenden oder hast du auch ein Beispiel für einen C-Code? Dankesehr....
Naja, ein bisschen Denken beim portieren wird ja wohl möglich sein, oder? Lässt du halt das Klassengrüst weg.
Naja, wäre ja bestimmt kein Problem wenn man öfter was mit C++ gemacht hat, aber leider sind meine Kenntnisse da eher bescheiden...
Habe mich jetz mehrere Male im Labor an den Rechner gesetzt und ein
wenig programmiert, und irgendwann ist folgender Schnipsel an code
zusammen gekommen, bei dem ich jetz die serielle Schnittstelle auch
abfragen kann.
siehe anlage "einlesen.h".
So jetzt folgendes Problem: Rufe diese Funktion jetzt aus ner anderen
c-File auf.
In dem C-File ist ein unsigned char einle[14] global deklariert.
Dann sollen die Daten eingelesen werden und dann in der C-File zum
Beispiel ausgegeben und weiter verwendet werden.
Wenn ich mir ein normalen String mit printf("%s .", text); auf dem
bildschirm ausgeben lasse, dann erscheint im Ausgabefenster "Inhalt_text
."
Habe ich aber jetz mit meiner einlesen.h im string InString z.B. JUMPER
stehen und gebe das jetzt mit printf("%s .", einle); aus, kommt da
folgendes raus: " .UMPER"
-> also er gibt erst JUMPER aus, schreibt dann aber am Anfang der Zeile
direkt das Leerzeichen und den Punkt über meine Ausgabe.
Weiss jmd was das Problem ist?
Dann habe ich noch eine andere Sache: Habe ein digitalisiertablett an
der RS232 hängen, das gibt mir Folgenden String : "XXXX,YYYY,n"
Das sind dann erst 4 mal x-Koordinaten, dann 4 mal y-Koordinaten, dann
Taste n, also 1 oder 2.
Das ganze funktioniert für alle Werte die ich einlese bei XXXX größer
gleich 1000, sobald ich da eine 0 am Anfang stehen hätte, steht in
meinem String "InString" ein y mit Apostroph drauf.
Wie kann ich denn den Fehler behebn.
Dankesehr für eure Hilfe...
Christian L. schrieb: > Habe ich aber jetz mit meiner einlesen.h im string InString z.B. JUMPER > stehen und gebe das jetzt mit printf("%s .", einle); aus, kommt da > folgendes raus: " .UMPER" > -> also er gibt erst JUMPER aus, schreibt dann aber am Anfang der Zeile > direkt das Leerzeichen und den Punkt über meine Ausgabe. > Weiss jmd was das Problem ist? Dein String wird nicht "JUMPER" enthalten, sondern JUMPER gefolgt von einem Carriage Return.
Ok, das mit dem Carriage Return passt: die Funktion ReadFile hat mir in InString zB JUMPER + ASCII 13 + ASCII 10 angehängt und dann das '\0' . Wenn ich aus -> InString[dwRead] = '\0'; // in "zero-ended"-String verwandeln -> InString[dwRead-2] = '\0'; // in "zero-ended"-String verwandeln mache, dann ist die Baustelle schonmal behoben. Zu dem zweiten Problem mit dem ý ,das kam aus folgender Quelle, hatte die serielle Schnittstelle mit -> dcb.Parity = NOPARITY; // Parität initialisiert, dort muss aber -> dcb.Parity = EVENPARITY; // Parität hin, dadurch scheint es sonst immer gefunst zu ahben, warum auch immer, sobal ich aber die 0 am anfang hatte, hat er mir dirket die ASCII 13 + ASCII 10 angehängt und dann das '\0' und dann den Müll den er noch in seinem Speicherbereich rumfliegen hatte. Werde morgen mal weiterprobieren und schauen was mir da noch so auffällt. Besten Dank aber für eure weitere Hilfe...
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.