ETS Posted January 17, 2015 at 11:52 AM Share Posted January 17, 2015 at 11:52 AM 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 Quote Link to comment Share on other sites More sharing options...
ETS Posted January 28, 2015 at 11:39 AM Author Share Posted January 28, 2015 at 11:39 AM 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. Quote Link to comment Share on other sites More sharing options...
photron Posted January 28, 2015 at 01:57 PM Share Posted January 28, 2015 at 01:57 PM 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. Quote Link to comment Share on other sites More sharing options...
ETS Posted January 28, 2015 at 04:25 PM Author Share Posted January 28, 2015 at 04:25 PM 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. Quote Link to comment Share on other sites More sharing options...
photron Posted January 28, 2015 at 04:44 PM Share Posted January 28, 2015 at 04:44 PM 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? Quote Link to comment Share on other sites More sharing options...
ETS Posted January 28, 2015 at 07:46 PM Author Share Posted January 28, 2015 at 07:46 PM 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. Quote Link to comment Share on other sites More sharing options...
raphael_vogel Posted January 28, 2015 at 08:03 PM Share Posted January 28, 2015 at 08:03 PM 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. Quote Link to comment Share on other sites More sharing options...
borg Posted January 28, 2015 at 10:40 PM Share Posted January 28, 2015 at 10:40 PM 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. Quote Link to comment Share on other sites More sharing options...
ETS Posted January 29, 2015 at 11:47 AM Author Share Posted January 29, 2015 at 11:47 AM 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. Quote Link to comment Share on other sites More sharing options...
Nic Posted January 29, 2015 at 12:11 PM Share Posted January 29, 2015 at 12:11 PM 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 ? Quote Link to comment Share on other sites More sharing options...
ETS Posted January 30, 2015 at 03:54 PM Author Share Posted January 30, 2015 at 03:54 PM 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 Quote Link to comment Share on other sites More sharing options...
Nic Posted January 30, 2015 at 04:17 PM Share Posted January 30, 2015 at 04:17 PM 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. Quote Link to comment Share on other sites More sharing options...
ETS Posted January 31, 2015 at 09:17 AM Author Share Posted January 31, 2015 at 09:17 AM 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. Quote Link to comment Share on other sites More sharing options...
Nic Posted January 31, 2015 at 11:11 AM Share Posted January 31, 2015 at 11:11 AM 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. Quote Link to comment Share on other sites More sharing options...
Dragony Posted January 31, 2015 at 01:10 PM Share Posted January 31, 2015 at 01:10 PM 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. Quote Link to comment Share on other sites More sharing options...
ETS Posted January 31, 2015 at 05:41 PM Author Share Posted January 31, 2015 at 05:41 PM 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. Quote Link to comment Share on other sites More sharing options...
FlyingDoc Posted January 31, 2015 at 09:51 PM Share Posted January 31, 2015 at 09:51 PM 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. Quote Link to comment Share on other sites More sharing options...
ETS Posted February 1, 2015 at 10:42 AM Author Share Posted February 1, 2015 at 10:42 AM 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. Quote Link to comment Share on other sites More sharing options...
FlyingDoc Posted February 1, 2015 at 12:05 PM Share Posted February 1, 2015 at 12:05 PM 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. Quote Link to comment Share on other sites More sharing options...
ETS Posted February 5, 2015 at 04:58 PM Author Share Posted February 5, 2015 at 04:58 PM 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 :-/ Quote Link to comment Share on other sites More sharing options...
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.