Jump to content

[RED] Zuverlässigere Sensorenauswertung?


ETS
 Share

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 to comment
Share on other sites

  • 2 weeks later...

Keiner? Wenn ich nochmal genauer nachdenke, wäre es ohne die Netzwerkstrecke ja eine native Programmierung, dann wahrscheinlich mit C? Ich bin der Meinung, darüber etwas gelesen zu haben. Theoretisch müsste es ja möglich sein, ist halt nur die Frage ob der Weg auch offen ist.

Link to comment
Share on other sites

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 to comment
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 to comment
Share on other sites

Es ist sicherlich schon ein Unterschied ob du zwischen zwei Rechnern übers Netzwerk kommunizierst oder nur auf einem mit sich selbst über die Loopback Schnittstelle. Da würde ich die Flinte nicht gleich ins Korn werfen.

 

Wie ist den dein bisheriger Aufbau genau?

Link to comment
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 to comment
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 to comment
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 to comment
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 to comment
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 to comment
Share on other sites

Mehrere Lichtschranken für Zwischenzeiten oder auch um Fahrzeuge getrennt zu erfassen. Dass Lichtschranken, die an verschiedenen IO-4 angeschlossen sind nicht auf die Millisekunde genau gleichzeitig über USB erfaset werden können ist mir klar. Das ist ja grad der Umstand, den ich gern behoben hätte.

Link to comment
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 to comment
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 to comment
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 to comment
Share on other sites

Dann ist mir noch nicht klar, wie das genau läuft... Die Firmware befindet sich auf dem Bricklets, wird dann aber vom Master ausgelesen und auf eben diesem ausgeführt? Dann wäre ja "nur" die Frage, wie ich an den Timer komme. Nur dass ich von Mikroprozessoren absolut keine Ahnung habe :-/

Link to comment
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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...