ETS Geschrieben January 17, 2015 at 11:52 Geschrieben January 17, 2015 at 11:52 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 Zitieren
ETS Geschrieben January 28, 2015 at 11:39 Autor Geschrieben January 28, 2015 at 11:39 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. Zitieren
photron Geschrieben January 28, 2015 at 13:57 Geschrieben January 28, 2015 at 13:57 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. Zitieren
ETS Geschrieben January 28, 2015 at 16:25 Autor Geschrieben January 28, 2015 at 16:25 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. Zitieren
photron Geschrieben January 28, 2015 at 16:44 Geschrieben January 28, 2015 at 16:44 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? Zitieren
ETS Geschrieben January 28, 2015 at 19:46 Autor Geschrieben January 28, 2015 at 19:46 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. Zitieren
raphael_vogel Geschrieben January 28, 2015 at 20:03 Geschrieben January 28, 2015 at 20:03 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. Zitieren
borg Geschrieben January 28, 2015 at 22:40 Geschrieben January 28, 2015 at 22:40 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. Zitieren
ETS Geschrieben January 29, 2015 at 11:47 Autor Geschrieben January 29, 2015 at 11:47 Ok, dann muss ich mir mal irgendwann Gedanken darum machen, wie ich das mit Mikrocontrollern machen könnte und akzeptiere erstmal die Schwankungen und auf den Red Brick. Danke für eure Hilfe. Zitieren
Nic Geschrieben January 29, 2015 at 12:11 Geschrieben January 29, 2015 at 12:11 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 ? Zitieren
ETS Geschrieben January 30, 2015 at 15:54 Autor Geschrieben January 30, 2015 at 15:54 Mich würde interessieren warum der Verlust von 10-20ms dir zu lang ist ? Es geht mir im Endeffekt um eine mobile Rundenzeitmessung für Autos aller Art. Für Vergleichszwecke zählt jede Millisekunde Zitieren
Nic Geschrieben January 30, 2015 at 16:17 Geschrieben January 30, 2015 at 16:17 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. Zitieren
ETS Geschrieben January 31, 2015 at 09:17 Autor Geschrieben January 31, 2015 at 09:17 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. Zitieren
Nic Geschrieben January 31, 2015 at 11:11 Geschrieben January 31, 2015 at 11:11 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. Zitieren
Dragony Geschrieben January 31, 2015 at 13:10 Geschrieben January 31, 2015 at 13:10 Um dir mal einen direkten Lösungsvorschlag zu präsentieren: Schreibe deinen Code direkt in die Firmware des IO4. Da hast du dann gar keine Latenz mehr. Ist ja alles Open Source. Zitieren
ETS Geschrieben January 31, 2015 at 17:41 Autor Geschrieben January 31, 2015 at 17:41 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. Zitieren
FlyingDoc Geschrieben January 31, 2015 at 21:51 Geschrieben January 31, 2015 at 21:51 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. Zitieren
ETS Geschrieben February 1, 2015 at 10:42 Autor Geschrieben February 1, 2015 at 10:42 Hm, aber am Red kann kein Bricklet angeschlossen werden, also hätte ich wieder die Netzwerkstrecke und bestenfalls eine Abfrage pro Millisekunde drin. Dann brauch ich auch nicht an der Firmware des IO4 rumdoktorn. Zitieren
FlyingDoc Geschrieben February 1, 2015 at 12:05 Geschrieben February 1, 2015 at 12:05 Auf dem Master ist auch ein Microcontroler. Diese habein auch Timer. Du müstest also die Timer des Microcontrolers benutzen. Ich müsste erst dir Schaltpläne und Datennblätter des Masters anschaunen. Basti kann dazu bestimmt mehr sagen. Zitieren
ETS Geschrieben February 5, 2015 at 16:58 Autor Geschrieben February 5, 2015 at 16:58 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 :-/ Zitieren
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.