Jump to content

[RED] Zuverlässigere Sensorenauswertung?


ETS

Recommended Posts

Hallo zusammen,

 

zum folgenden Thema konnte ich leider bisher keine Informationen finden.

 

Ich habe ein System am Laufen, dass per IO-4-Bricklet die Unterbrechung mehrerer Lichtschranken erkennt. Bei jeder Unterbrechung wird ein Interrupt ausgelöst. Nun ist es ja aber so, dass zwischen dem IO-4 und meiner Callback-Funktion der Master Brick sowie eine Netzwerk- und USB-Verbindung liegen, womit es zu Abweichungen bei der Messung kommen kann (bei mir aktuell ca. 10ms, im Extremfall auch mal 20ms).

 

Wenn ich jetzt einen Red Brick einsetzen würde, spare ich mir die USB-Verbindung. Aber spare ich mir intern auch die Netzwerkverbindung? Ich meine irgendwo gelesen zu haben, dass für den Red Brick die Kommunikation zwischen den Bricks und Bricklets geändert werden musste.

 

Mein Ziel ist, dass ich deutlich weniger Abweichung bei der Messung erhalte. Ich würde dann auf dem Red Brick den Interrupt auswerten und in aller Ruhe die Daten an einen Rechner im Netzwerk senden. Dabei wäre ja dann egal, ob ich Ethernet oder WLAN benutzen würde.

 

Also, wäre eine genauere Messung mit dem Red Brick möglich? Vielleicht auch mit einer anderen Programmiersprache als C#?

 

MfG

Link zu diesem Kommentar
Share on other sites

  • 2 weeks later...

Mit dem RED Brick entfällt die USB Verbindung, wenn du das Bricklet an einem Brick angeschlossen hast, dass auf den RED Brick gesteckt ist.

 

Die Netzwerkverbindung bleibt, wenn auch in anderer Form. Dein Programm auf dem RED Brick verbindet sich immer noch über localhost mit dem brickd auf dem RED Brick.

 

Potentiell könnte das mit Auswertung auf dem RED Brick schneller/stabiler werden, weil du die externe Netzwerkverbindung nicht mehr in der Kommunikationskette hast. Das hängt aber wirklich davon ab wo dir in deinem jetzigen Aufbau die 10-20ms verloren gehen.

Link zu diesem Kommentar
Share on other sites

Ok, schade, ich hatte gehofft, dass ich mir irgendwie auch die Netzwerkstrecke sparen kann.

 

Ich denke das größere Problem stellt aktuell die USB-Verbindung dar. Ein "Zeitverlust" wäre auch nicht so schlimm, nur variiert die Messung um 10-20ms. Da muss ich mir mal überlegen, ob ich mir den Red-Brick wirklich zulege und es mal ausprobiere, ob es damit besser wird. Zumindest dürfte es ja nicht viel geben, dass die interne Netzwerkkommunikation stört, wenn ich nur ein Programm laufen lasse.

Link zu diesem Kommentar
Share on other sites

Momentan habe ich lediglich ein IO-4-Bricklet am MasterBrick angeschlossen, der wiederum per USB am Rechner angeschlossen ist. Am IO-4 ist eine Lichtschranke angeschlossen, von der ich an einem der Eingänge den Interrupt per Callback-Function abfange. Geschrieben mit C#. In der Callback-Function erfasse ich die Millisekunden über die Stopwatch-Klasse und lege ein Objekt mit diesem und weiteren Werten (z.B. Interruptmask) in einer Queue ab, die ich bei Bedarf in Ruhe auswerte.

 

Worauf ich halt am liebsten hinaus möchte, wäre die Netzwerk- und USB-Strecke komplett zu eliminieren um möglichst wenig Abweichung bei der Erfassung der vergangenen Millisekunden (oder weniger!) seit Programmstart zu haben. Wenn dazu eine andere Programmiersprache nötig ist, dann würde ich das schon irgendwie hinbekommen.

Link zu diesem Kommentar
Share on other sites

Eine andere Programmiersprache macht hier kaum einen Unterschied. Im TF System spricht jede Sprache TCP mit dem brickd. Das macht C# genauso schnell wie Java oder Python.

 

Wenn du Genauigkeit von Millisekunden oder sogar weniger brauchst wirst du mit TF nicht glücklich. Dann müsstes du vermutlich direkt einen Microcontroller programmieren.

Link zu diesem Kommentar
Share on other sites

Worauf ich halt am liebsten hinaus möchte, wäre die Netzwerk- und USB-Strecke komplett zu eliminieren um möglichst wenig Abweichung bei der Erfassung der vergangenen Millisekunden (oder weniger!) seit Programmstart zu haben. Wenn dazu eine andere Programmiersprache nötig ist, dann würde ich das schon irgendwie hinbekommen.

 

Wenn du das mit hundertprozentiger Sicherheit benötigst ist das mit einem "normalen" Betriebssystem nicht möglich. Weder unter Windows noch OS X oder Linux (ohne RT PREEMPT patch) ist es garantiert dass dein Programm überhaupt einmal pro ms gescheduled wird.

 

 

Link zu diesem Kommentar
Share on other sites

Ich meine irgendwo gelesen zu haben, dass für den Red Brick die Kommunikation zwischen den Bricks und Bricklets geändert werden musste.

Mit dem RED wurde quasi der HostPC näher zu den Bricks/Bricklets gebracht, d.h. die Kommunikation über USB ist dann nicht mehr gegeben. Der RED kommuniziert intern mit den Bricks über das SPI Interface.

Allerdings bedingt durch die USB Anbindung von Anfang an, ist auch das interne SW-Design ausgelegt auf höchstens 1ms Auflösung egal ob nun via USB oder SPI.

 

Was noch noch gar nicht erwähnt wurde, ist die IO Schnittstelle am RED die bisher sw-und hw-seitig noch nicht unterstützt wird. Aber ich bezweifel ob damit wesentlich schnellere Verarb. als mit den Brick-Teilen möglich ist, dann wird das zum Tragen kommen was borg schon bzgl. der Betriebssystem-Limits erwähnte.

 

Mich würde interessieren warum der Verlust von 10-20ms dir zu lang ist ?

Link zu diesem Kommentar
Share on other sites

Du sprichst von mehreren Lichtschranken (?), wieso reicht nicht eine Lichtschranke am Zielpunkt ?

Es kommt noch hinzu dass die Interrupts (je Lichtschranke) bedingt durch den USB m.W. nicht parallel beim PC auflaufen wenn 2 Wagen auf die ms gleichzeitig durchs Ziel jagen. Du triggerst nur die Zeit, wenn der Callback sich in deinem Programm meldet.

Link zu diesem Kommentar
Share on other sites

Nehmen wir an du kannst das Nadelöhr USB irgendwie umgehen und der HostPC bzw. RED empfängt und verarbeitet die Interrupts und Bricklets ohne Umweg dann kommst du mit den TF-Teilen niemals schneller als 1ms:

http://www.tinkerunity.org/forum/index.php/topic,2525.msg16509.html#msg16509 und

http://www.tinkerunity.org/forum/index.php/topic,2127.msg14118.html#msg14118

 

Ich würde mal sagen, dass die TF Firmware und Protokoll quasi wie im Zeitscheibenprinzip konzipiert ist.

Link zu diesem Kommentar
Share on other sites

Wäre das wirklich möglich? Um das mal durchzugehen: Um möglichst kompatibel zu bleiben, könnte ich den Parameter für die ValueMask zweckentfremden (oder hat die eine maximale Stringlänge?). Dann müsste ich aber irgendwie einen Zeitstempel oder ähnliches abfragen können, z.B. über einen Timer auf dem Bricklet, richtig? Ist das überhaupt gegeben? Falls ja, wäre das ein schöner Ansatz. Denn es kommt nicht drauf an, wie lange es dauert, bis die Daten beim Interrupt ankommen, wenn die Zeitstempel exakt und vergleichbar sind.

Link zu diesem Kommentar
Share on other sites

Auf dem Bricklet befindet sich weiter nichts als der IO Baustein oder Sensorbaustein und ein kleiner EEPROM in dem sich die Software, die der Master für den Betrieb des Bricklet benötigt, befindet.

Dieser wird beim Systemstart ausgelesen und im Master oder ebend dem Brick an dem der Sensor angeschlossen ist abgearbeitet.

Solch ein Timer müsste dann im Master laufen.

Dafür wäre der RED eher geeignet, da er eine interne Systemzeit laufen hat.

Also auch Timerfunktionen.

 

Da fällt mir gleich ein Bricklet ein das man eventuell gebrauchen könnte.

Ein Funkuhrempfänger der den Empfang des Atomuhrsignales ermöglicht um zum Beispiel die Systemzeit im RED zu synchronisieren wenn man keinen GPS Brick angeschlossen hat. ;D

Link zu diesem Kommentar
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Gast
Reply to this topic...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Clear editor

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...