![]() |
USB mit Message
Frohes neues Jahr
ich hab mal eine Frage bezüglich USB. Ich habe ein Profibus-USB Gerät. Dieses kann ich über mitgelieferte DLLs ansprechen. Um Daten zu lesen, muss ich einen Timer laufen lassen, der eine bestimmte funktion durchläuft. Kann man dieses auch ohne Timer machen? Ich dachte an ein Event, was das USB-Gerät bzw. Windows-XP (Interrupt) auslöst und ich dann diese Message bekomme und die Empfangsfunktion dann erst aufrufe. Hat jemand eine Idee, ob so etwas bei USB möglich ist? mfg edmu |
AW: USB mit Message
Wenn Du nicht schreibst, um was für Hardware es geht, kann Dir niemand helfen.
Es gibt billigste Hardware, da muss mit Polling alles geregelt werden und es gibt Hardware, die den PROFIBUS Communication Status auswertet. |
AW: USB mit Message
Hallo hathor
Danke erst einmal für deine Antwort. Ich habe von Fa. Softing ein "ProfiUSB" Gerät. An der einen Seite einen Profibus-Anschluss und an der anderen Seite einen USB-Anschluss. Bereit gestellte DLLs sind auch vorhanden. Grundsätzlich funktioniert die Kommunikation, aber mit dem Pollen (50ms) und dem ständigen Aufrufen der "Receive" Funktion wird meine Anwendung langsamer. Die Receive Funktion benötigt wohl einige Zeit bis diese wieder zurück kehrt. Aber ich muss auch ständig kontrollieren, ob neue Telegramme vorhanden sind. Ich habe mal mit einem CP5511 gearbeitet und dort gab es eine "Windows-Botschaft". Wenn Botschaft vorhanden, dann habe ich die Receive-Funktion aufgerufen. Ich dachte, so etwas könnte auch mit dem USB-Gerät gehen. Im Windows-GeräteManager kann ich auch nichts einstellen. Kann man mit einem USB auch mit Windows-Botschaften arbeiten oder geht das grundsätzlich nicht? Danke mfg edmu |
AW: USB mit Message
Zitat:
Grundsätzlich hört sich dein Problem aber eher hausgemacht an... Wie wäre es einfach mit einem Thread, der mit dem Gerät kommuniziert, und dann die empfangenen Daten weitergibt? (Der kann das z.B. per Windows Message tun, wenn du das möchtest.) // EDIT: Anders wird das vermutlich beim CP5511 auch nicht gewesen sein. Die Ansteuerungs-DLL hat nur vermutlich den Thread selbst erstellt usw. |
AW: USB mit Message
So wie bei COM-Ports gibt es auch bei USB Handshakes:
Transaction types which support flow control return handshakes to indicate: Successful reception of data Command acceptance or rejection Flow control Halt conditions ![]() Aber man müsste die Hardware-Umsetzung RS485-USB kennen, um das Handshaking zu kennen. Am Besten wäre eine Weiterleitung eines Interrupts, um CPU-Waste time zu vermeiden. Nachtrag: In den Software-Beispielen gibt es C#-Code - da wird aber leider auch nur gepollt:
Code:
#define PROFI_RCV_CON_IND() do \
{ \ con_ind_buffer_len = 256; \ result = profi_rcv_con_ind (&con_ind_sdb, con_ind_buffer, &con_ind_buffer_len); \ if (_kbhit ()) if (_getch () == 'q') exit (0); \ } while (result == NO_CON_IND_RECEIVED); \ \ if (result == E_IF_FATAL_ERROR) handle_fatal_error ((T_EXCEPTION*) con_ind_buffer) |
AW: USB mit Message
Das hört sich sehr kompliziert an.
Ich habe das mit dem Thread schon vorbereitet. Ich schau mal, ob mir das so reicht. danke |
AW: USB mit Message
Hallo
ich wollte mich noch mal eben melden. Ich habe eine Einstellung bei dem USB-Gerät gefunden. Und zwar muss man beim öffnen der Verbindung die Timeout-Zeit einstellen. Die war bei mir viel zu hoch eingestellt, 1000ms. Diese habe ich jetzt auf 100ms gestellt und es läuft deutlich besser. Ich denke, das eine Rückantwort erst nach teilweise 1000ms kam, es sei denn, es ist vorher ein Telegramm empfangen worden. Ich werde noch ein bißchen mit herum spielen. Danke mfg edmu |
AW: USB mit Message
Richtig gut laufen wird es, wenn du die Abfrage in einem Thread laufen lässt und dann das empfangene Telegramm weiterreichst.
Dann ist auch der Timeout mit 1000ms quasi egal, bzw. evtl. sogar nicht so stressig. |
AW: USB mit Message
Hinweis: In den Software-Beispielen läuft ein 55ms-Timer.
|
Alle Zeitangaben in WEZ +1. Es ist jetzt 22:13 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz