Hallo zusammen Ich möchte über LabView Daten eines uC auslesen. Dazu öffne ich einen ComPort mit einem FTDI chip (https://www.sparkfun.com/products/9873), Baudrate 115200. Die Datenübertragung funktioniert einwandfrei, jedoch kriege ich nur ca 4Hz raus. Um dies zu debuggen habe ich ein kurzes LabView VI (siehe Bilder) geschrieben, dass einen Befehl (A0) schickt und dann die Antwort ausliesst (versionsNr). UART TX und RX lese ich auf dem Scope aus (siehe Bilder). Die Antwort scheint wenn sie mal auf dem UART ist schnell zurück zu kommen. Also schliesse ich daraus, dass das Problem beim FTDI-Chip oder auf PC seite liegt. Hier komme ich jedoch nicht mehr weiter. Hat jemand eine Ahnung an was dies liegen könnte? Vielen Dank für eure Hilfe. Gruss Christian
Angehängte Dateien:
-
Labview.PNG
8,1 KB -
Uart_500us.PNG
180 KB -
Uart_100ms.PNG
160 KB
USB arbeitet Blockweise. Ich sehe leider nicht wie du die Daten überträgst. Wenn du 1 Zeichen sendet und dann auch 1 Zeichen wartest dann wird das niemals schnell werden. Du musst dafür sorgen, das viele Daten in einem Rutsch übertragen werden.
Danke dir für deine Antwort, ich sende die ASCI zeichen "A0" und erwarte 10 Byte zurück. CR bedeutet das Ende der Übertragung. Es war mir bewusst, dass ich so den USB nicht gerade optimal ausnütze, hätte jedoch erwartet, dass ich 20Hz rauskriege um ein flüssiges Bild darstellen zu können. 4 Hz dünkt mich doch ein wenig sehr tief?
Christian schrieb: > jedoch kriege ich nur ca 4Hz raus. Also irgendwas mit 250ms Timeout. > Also schliesse ich daraus, dass das Problem beim FTDI-Chip oder auf PC > seite liegt. Such mal nach einer Flush-Funktion oder programmiere die Latency um: http://www.ftdichip.com/Support/Documents/ProgramGuides/D2XX_Programmer's_Guide(FT_000071).pdf
:
Bearbeitet durch Moderator
Christian schrieb: > Die Datenübertragung funktioniert einwandfrei, jedoch > kriege ich nur ca 4Hz raus Mach doch mal das Gleiche nicht mit Labview, sondern mit einem Terminalprogramm. Man kann eine Datei senden und die Verzögerung nach jeder Zeile einstellen. Georg
@Christian (Gast) >Bilder). Die Antwort scheint wenn sie mal auf dem UART ist schnell >zurück zu kommen. Also schliesse ich daraus, dass das Problem beim >FTDI-Chip Nicht wirklich. >oder auf PC seite liegt. Dort schon eher. LabVIEW ist nicht gerade ein Sprinter. >Hat jemand eine Ahnung an was dies liegen könnte? Man muss man schauen, ob man ein paar Einstellungen im LabVIEW verstellen kann. Bzw. muss man prüfen, ob diverse andere Abläufe (Anzeige des Strings etc.) dein LabVIEW Programm ausbremsen.
@Lothar Miller (lkmiller) (Moderator) >> Also schliesse ich daraus, dass das Problem beim FTDI-Chip oder auf PC >> seite liegt. >Such mal nach einer Flush-Funktion oder programmiere die Latency um: >http://www.ftdichip.com/Support/Documents/ProgramG... Muss er nicht, die ist um Größenordnungen geringer. Der Fehler liegt wahrscheinlich im LabVIEW und dessem Treiber.
Du kannst im Gerätemanager in den Einstellungen des COM-Ports das Timeout einstellen, das kannst du bis auf 1ms runterstellen. Reiter "Anschlusseinstellungen" -> Erweitert -> BM Einstellungen -> Wartezeit auf 1ms einstellen. Die Timeouts kannst du auch gleich mal auf 0ms setzen falls die anderes eingestellt sein sollten.
Christian schrieb: > Also schliesse ich daraus, dass das Problem beim > FTDI-Chip oder auf PC seite liegt. Hier komme ich jedoch nicht mehr > weiter. Den Timeout müsste man in der LabView Komponente für den seriellen Port parametrisieren können. Ich verwende hier auch FTDI Chips (aber ohne Labview), da kommen die Daten fast augenblicklich (<10ms) raus. In seriellen Komponenten sind manchmal relativ lange Timeouts drin, um einzeln gesentete Bytes zu kompletten Messages zusammenfassen zu können.
Angehängte Dateien:
Ich habe es im Terminalprogramm "HTERM" ausprobiert und kriege vergleichbare Taktzeiten. Auf die Anregung von Chris habe ich die Einstellungen des Com Ports verändert (siehe Anhang), leider sind die Ergebnisse gleich. Christian
Wegen schwierig zu handhabenden Latenzen, sollte man sich an eine grosse Blockgroesse gewoehnen. Dh anstelle 3er einzelner Commands, mit je einer eigenen Antwort, besser einen Block, der alles enthaelt.
Christian schrieb: > Ich habe es im Terminalprogramm "HTERM" ausprobiert und kriege > vergleichbare Taktzeiten. Auf die Anregung von Chris habe ich die > Einstellungen des Com Ports verändert (siehe Anhang), leider sind die > Ergebnisse gleich. > > Christian Sieht bis auf die Puffergrößen bei mir gleich aus, dort habe ich jeweils 4096 Bytes drin.
Da habe ich auch beides probiert. Ich habe gehofft dass das Problem zu grosse Pakete sind (wo ich doch sehr kleine verwende).
Christian schrieb: > Da habe ich auch beides probiert. Ich habe gehofft dass das Problem zu > grosse Pakete sind (wo ich doch sehr kleine verwende). Hoffen, anstatt auszuprobieren. Menschen reden miteinander schneller als 4Hz. FTDI hat bestimmt nicht solche Verzögerungen. Falk B. schrieb: > Muss er nicht, die ist um Größenordnungen geringer. Der Fehler liegt > wahrscheinlich im LabVIEW und dessem Treiber. Aber du kannst natürlich den Fehler weiter in Paketgröße suchen...
:
Bearbeitet durch User
Wie gesagt, habe ich beides PROBIERT, nicht nur GEHOFFT :D und wie gesagt, ich habe es nicht nur im LabView ausprobiert sondern auch in einem Terminalprogramm. Also wird der Fehler höchst wahrscheinlich nicht in LabView liegen. Hast du sonst noch eine Idee?
Christian schrieb: > Hast du sonst noch eine Idee? Ja. Irgendein File mit ZModem senden und staunen. Wie schon gesagt, 4 Bytes/sec kann nicht mit FTDI zusammenhängen, jedenfalls was die hardware betrifft, ist es so schwer zu verstehen ? LabView, Driver, Windoof - alles, aber FTDI nicht.
Sehe ich gleich, dass es der FTDI Chip nicht sein wird. Ich tippe auf Windows bzw Treiber. Nur hilft mir dies nicht viel weiter. Ein weiterer Punkt; ich kriege 4 Übertragungen raus, egal ob ich jetzt 1 Byte oder 20 Byte schicke --> nicht FTDI.
Christian schrieb: > Sehe ich gleich, dass es der FTDI Chip nicht sein wird. Ich tippe auf > Windows bzw Treiber. Nur hilft mir dies nicht viel weiter. Fang doch um himmelswillen systematisch an! Also zu allererst ein logischer Kurzschluß direkt auf der seriellen Seite des FTDI, also TxD an RxD. Dann probierst du aus, wie schnell deine ganze Strecke von der Applikation über's OS zum FTDI und wieder zurück ist. Normalerweise geht das ruckzuck, die Latenzzeit zwischen einzelnen Datenblöcken auf den USB liegt so bei 1 ms. Du solltest also beim Terminalprogramm beim Tippen keinerlei Verzögerungen spüren. Die nächste Sache ist dann das Programm, was auf deinem µC läuft. Wenn sich das zu dämlich anstellt, dann wird das Ganze eben langsam. Und genau das vermute ich. W.S.
Ich habe schon eine Menge mit unterschiedlichen USB-UART Adaptern gemahct, nur nicht mit dem FT232 Chip. In allen Fällen lagen die Latenzzeiten ohne besondere Konfiguration im Bereich um 1ms. 250ms ist nicht in Ordnung. Teste den Adapter mit Hterm in einer Schleife, also ohne weitere Hardware und ohne Matlab.
Der Logische Kurzschluss von TX-RX habe ich durchgeführt. Antwort kommt ohne spürbare Verzögerung. Getestet habe ich in Hterm. Nur auch hier vergehen bis 250ms bis er eine erneute Meldung sendet, wenn ich den Befehl aus Hterm in einer schleife ohne Verzögerung schicke.
@Christian (Gast) >Der Logische Kurzschluss von TX-RX habe ich durchgeführt. >Antwort kommt >ohne spürbare Verzögerung. Getestet habe ich in Hterm. Nur auch hier >vergehen bis 250ms bis er eine erneute Meldung sendet, wenn ich den >Befehl aus Hterm in einer schleife ohne Verzögerung schicke. Und was schließen wir daraus?
Ein Lösungsansatz wäre hilfreich. Ich habe diese Konfiguration auch schon an einem anderen PC mit hTerm ausprobiert, leider mit gleichem Ergebnis.
Wo kommen die riesigen LOW-Zeiten (break) zwischen den Datenpaketen her? Hat dein FTDI-Kabel vielleicht einen Wackelkontakt?
Das ist eine gute Frage. Ich habe das USB-Kabel getauscht und es sieht immer noch gleich aus.
@Christian (Gast) >Das ist eine gute Frage. >Ich habe das USB-Kabel getauscht und es sieht immer noch gleich aus. Ich glaube du macht grundlegend was falsch. Was auch immer. Aus dem FTDI darf in den Pausen kein Break (=LOW) rauskommen. Entweder hast du einen total vermurksten Treiber, andere Software, die auf die COM-Ports mit zugreift oder irgendwo anders einen elementaren Fehler.
Angehängte Dateien:
-
Timing.PNG
11 KB
Ich habe es herausgefunden :D Das Problem ist der CLR Befehl den ich im Labview eingebaut habe. Dieser braucht ca 250ms. Wenn ich diesen weg lasse kriege ich ca 600Hz raus (Bild Timing im Anhang). Warum ich auf die gleichen Ergebnisse mit HTerm komme weiss ich nicht. Vielen Dank an alle die geholfen haben eine Lösung zu finden. Gruss Christian
Christian schrieb: > Das Problem ist der CLR Befehl den ich im Labview eingebaut habe. Ein klassisches Layer 8 Problem... > Dieser braucht ca 250ms Man fasst es nicht. In dieser Zeit zählt ein heutiger Bolide eine Endlosschleife 3 mal komplett durch... > Warum ich auf die gleichen Ergebnisse mit HTerm komme weiss ich nicht. Aber es wäre doch interessant, oder nicht?
:
Bearbeitet durch Moderator
@Lothar Miller (lkmiller) (Moderator) >> Warum ich auf die gleichen Ergebnisse mit HTerm komme weiss ich nicht. >Aber es wäre doch interessant, oder nicht? Möglicherweise hat LabVIEW einen eigenen Treiber für die COM-Ports installiert, auf den auch HTERM zugreift.
Dann müsste HTerm ja jetzt nach der Korrektur auch schneler sein. Ist
das der Fall?
> Der Logische Kurzschluss von TX-RX habe ich durchgeführt.
Haben wir alle verstanden. Richtig heisst es: Loop-Back, nicht
Kurzschluss.
Das wäre eine Möglichkeit. Ich bin auch ziemlich überrascht. Ich habe eine Programmlaufzeit (ohne Kommunikation) von ca 150us, da fallen 250ms doch ziemlich ins Gewicht ;D. Ich nehme an, dass es einen schnelleren Weg geben wird den Buffer zu lehren.
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.