Die Sensorabfrage über die serielle USB-RS485-Schnittstelle bleibt bei 16 ms hängen, obwohl sie schneller sein sollte

Ich habe ein Setup, bei dem ich eine Razor IMU - Sensorplatine mit einer RS-485-Breakout- Platine über ein USB-Kabel an eine serielle USB-RS485-Schnittstelle an meinen Laptop anschließe. Ich betreibe auf dem Laptop (Max/MSP) eine Software, die Polling-Nachrichten an den Sensor sendet, auf die Antwortdaten wartet und beim Erhalt der Antwort automatisch eine neue Polling-Nachricht auslöst. Es ist eine ständige Schleife:

  1. eine Abfragenachricht senden
  2. warte auf eine Antwort
  3. bei Antwort gehe zu 1.

Ich möchte, dass diese Abfrage so schnell wie möglich ist, da ich 21 dieser Sensoren an denselben RS485-Bus anschließen muss. Die Firmware auf dem Razor ist mit der Arduino IDE programmiert , und laut Code sollte es nur eine Verzögerung von ~2 ms zwischen der Abfragenachricht und dem Schreiben der Antwort geben. Die Firmware verbringt auch alle 20 ms 12 ms mit der Sensorzuordnung und -berechnung. Diese Berechnung verzögert manchmal die Antwort auf die Abfrage. Dessen bin ich mir bewusst und alle Ergebnisse sind dementsprechend.

Mein Problem im Moment ist, dass die Abfrage des Sensors bei einer Aktualisierungsrate von durchschnittlich 15 Millisekunden hängen bleibt. Ich habe mir die Daten mit meinem kleinen USB-Oszilloskop angeschaut und ein Diagramm erstellt (>PDF).

Geben Sie hier die Bildbeschreibung ein

Mein Oszilloskop sitzt direkt auf der USB-RS485-Schnittstelle und sieht, wie das Polling ausgeht und das Antworttelegramm eintrifft. Die Verzögerung zwischen beiden liegt zwischen 2 und 13 ms. Dieser Unterschied ist damit zu erklären, dass der Rasierer manchmal mit seinen Sensor-Mathe-Berechnungen beschäftigt ist. Das Seltsame ist, dass, obwohl die Antworten mit unterschiedlichen Verzögerungen eintreffen, die Abfrage immer im gleichen Intervall von etwa 15 ms zu gehen scheint.

Wir haben das gleiche Setup auch mit implementiert

  • Programmieren der Firmware in C und Programmieren des Razor mit avr-dude
  • Durchführen der Softwareabfrage im Python-Code
  • auf Mac OSX und PC Windows 7

Alle möglichen Kombinationen führten zu demselben 15-ms-Intervall. Das Problem liegt also weder im Arduino-Code noch in Max/MSP. Ich habe den Verdacht, dass das Problem am USB-RS485 Serial Interface und/oder dem notwendigen FTDI-Treiber liegen könnte.

Kommt dieses Problem jemandem bekannt vor??

Die Abfrage erfolgt also immer von einem Computer mit OSX oder Windows 7? Die Verzögerung bei USB kann unabhängig von der verwendeten Programmiersprache ziemlich groß sein.
Im Moment testen wir auf Windows 7 und auf OSX. am Ende läuft es auf Windows 7.
Anstatt Ihre Frage zu bearbeiten, können Sie Ihre eigene Frage beantworten. Auf diese Weise können Sie es als Antwort auswählen und sogar Upvotes erhalten!
In 7 Stunden werde ich! :) <.... Benutzer mit weniger als 100 Reputation können ihre eigene Frage 8 Stunden lang nach dem Stellen nicht beantworten. Sie können innerhalb von 7 Stunden selbst antworten. Bis dahin verwenden Sie bitte Kommentare oder bearbeiten Sie stattdessen Ihre Frage.>

Antworten (2)

Das liegt am 16-ms-Latenz-Timer des FTDI-Treibers und an der Tatsache, dass meine Polling-Antworten nicht lang genug waren, um den 64-Byte-Puffer zu füllen, um das automatische Leeren des Puffers auszulösen. Lesen Sie AN232B-04_DataLatencyFlow.pdf , wenn Sie interessiert sind, oder gehen Sie einfach zu Ihrem Geräte-Manager und ändern Sie die Einstellungen in Ihren USB-Serial-Port-Eigenschaften.

Ohne viele Details zu kennen (die ich nicht wirklich wissen möchte), würde ich dem USB-zu-RS-485-Adapter die Schuld geben. Wir hatten ein ähnliches Problem auf einem Intel Q7-Prozessor, auf dem Linux mit einem dieser Adapter ausgeführt wurde.

Wir haben den Adapter vorübergehend verwendet, bis unsere benutzerdefinierte Hardware fertig war. Unsere kundenspezifische Hardware verwendet eine PCIe-Verbindung und ein FPGA, um dieselbe RS-485-Schnittstelle (und vieles mehr) auszuführen. Die Software blieb für den Adapter und unsere kundenspezifische Hardware gleich. Als wir auf die benutzerdefinierte Hardware umgestiegen sind, war das Problem verschwunden.

Jawohl! Ich habe gerade herausgefunden, dass ich eine Menge Sachen in den USB-Serial-Port-Einstellungen ändern kann (insbesondere den Latenz-Timer) und dann wird alles schneller ...
Die Sensorabfrage über die serielle USB-RS485-Schnittstelle bleibt bei 16 ms hängen, obwohl sie schneller sein sollte
AntwortenHierDatenschutz-Bestimmungen1y, 0v