AuronX

Die Geschwindigkeit sollte ja nur auf dem kleinen PC in der Fräse eine Rolle spielen oder? Dort ist denke ich das wichtigste, dass du Unterbrechungen durch das Betriebsystem vermeidest. Also am Besten nix anderes laufen lassen und den Steuerungsprozess auf eine hohe Priorität setzen. Die Wahl der Programmiersprache sollte darauf meiner Ansicht nach keinen Einfluss haben ^^ (Zumindest solange du dich von PHP fernhältst )

Und es wäre einfach nur geil wenn es dieses Dictionary direkt aus den Bindings gäbe, man also keine Reflection dafür einsetzen müsste. Aber sehr gute Arbeit!

LOL! Ich hatte ja so ein großes Brett vor dem Kopf... ich habe oben geschrieben, dass maximal 1000 Umdrehungen pro Minute gehen sollten weil ja ein IO nur maximal 1000 Impulse pro Sekunde verarbeiten kann. Da hab ich in der Schule wohl nicht aufgepasst. Meine neue Vermutung liegt demnach bei maximal 60000 RPM (1000 RPS) ;-) Ansonsten kann man sich aber natürlich auch mit einer Übersetzung behelfen. Also da wo gemessen wird mit halber Drehzahl arbeiten.

Da fällt mir nur Firmware-Programmierung ein... Von der Firmware weiß ich, dass dort der "Takt" eine Millisekunde ist. Das heißt im Millisekundenbereich exakt zu schalten wäre prinzipiell möglich.

Ich habe Jan gerade mit Masder verwechselt... letzterer hat nämlich hier auch Bilder gepostet: http://www.tinkerunity.org/forum/index.php/topic,1183.msg7795.html#msg7795

Will sagen man könnte den Stack per USB anschließen und hoffen, dass es sich per WLAN gleich verhalten würde. Was ihr damit natürlich nicht aufdeckt sind Fehler im TF-Protokoll, aber das ist auch nciht die Aufgabe von Unit-Tests.

Hmmm... könnte im Rahmen der Unit-Tests egal sein, dass es WiFi ist... (außer organisatorisch). Von eigener Firmware zu diesem Zweck würde ich abraten, das wäre overkill. Ideal wäre es für Unit-Tests eigentlich, wenn jedes Device ein zugehöriges Interface hätte. Dann könnte man die Devices ganz einfach mocken und ihr wärt nicht auf echte Hardware angewiesen. (Wie wollt ihr testen, ob Methode x mit einer TimeoutException klarkommt?)

Man kann ja die CallbackPeriod von irgendwas als Semaphore nutzen Aber wie schon von Batti gesagt: Das ist nicht sonderlich Thread-safe. Wie wäre es wenn ihr euren eigenen Brickd schreibt (bzw. den originalen modifiziert). Einfache Variante: Nur eine offene Verbindung, danach keine weitere akzeptieren. Fortgeschritten: der Brickd reagiert auf einer virtuellen UID auf einen Test-And-Set Funktionsruf (dadurch sind echte Semaphoren/Mutexe möglich).

@Topic: Da es sich hierbei um ein "ungültig" und nicht um ein "default" handelt wäre ich vermutlich für einen null-string, also nicht String.Empty. @tri-state/OT: Genau das war der use-case, allerdings ist das nur auf den ersten Blick cool. Am Ende hast du dann Code wie diesen: if(myTriState == true) foo; else if(myTriState == false) bar; Und vieles wird komisch und unklar ^^

Theoretisch könnten die Bindings überprüfen, ob ein Device das die IPConnection gerade benutzt auch noch in der IPConnection bekannt ist. Falls nicht könnten sie statt einer TimeoutException nach 2 Sekunden, besser sofort eine IllegalStateException mit hilfreichem Text werfen. (Bei Java sollte man aber darauf achten, dass es sich dabei auch um eine (Subklasse von) RuntimeException handelt, da diese Exception nicht checked sein sollte.

Nullable<string> (string?) macht gar nciht so viel Sinn, weil Strings auch null sein können ;-) Ich bin abre auch dafür, dass diese Dinge per Getter verfügbar sind. Allerdings bin ich kein Freund von int? (habe sogar schonmal bool? gesehen ). Ich denke das gehört zu den Dingen die vermieden werden sollten, wenn es nicht unbedingt notwendig ist (z.B. Kompatibilität mit fremden - nicht beeinflussbaren - Interfaces). Mein Vorschlag: public int Port { get; } public string Host { get; } public int ConnectionState { get; } Bin gerade nicht in Reichweite der aktuellen Bindings und möglicherweise ist der ConnectionState schon verfügbar (und vielleicht sogar als Enum... das wäre cool, aber ist meiner Erinnerung nach nicht so). Ob man dann für Disconnected bestimmtes Verhalten garantiert kann man noch diskutieren. Im vorliegenden Fall wären ja Host: null und Port: 0 durchaus geeignet, da 0 kein gültiger Port ist. P.S.: Zum Erkennen der IPConnection würde ich in der Regel dennoch auf einen Vergleich zurückgreifen. Je nach Anwendungsfall könnte ein Dictionary hilfreich sein. (Eine Aussage die ich blauäugig treffe ohne zu wissen was du genau vor hast)

Das mit dem GC ist ja echt bedenklich ^^ Müsste man glatt mal schauen, ob die Bindings in dieser Hinsicht auch sparsam mit den Ressourcen des Geräts umgehen. Habe bisher nicht so sehr auf das Speicherverhalten geachtet (und wenn überhaupt nur die C#-Bindings reviewt), aber ich glaube das wäre nochmal einen Blick wert ^^

Wie viele Aufrufe sind das jeweils insgesamt? (ich gehe davon aus, dass du sie in einer Schleife mehrfach gerufen hast) Was ich meine: Der bloße Aufruf der Funktion getResponseExpected() ist jetzt 15% schneller (weniger CPU-Zeit), insgesamt sind aber die ganzen TF-Funktionen eher IO-Bound und nicht CPU-Bound, das bedeutet, dass du zwar einige Takte auf der CPU sparst, aber die Kommunikation noch immer eine Millisekunde dauert. Ich überschlage das mal sehr grob: vorher: 1 ms + 1 µs = 1001 µs nachher: 1 ms + 0 µs = 1000 µs ------------------------------ Ersparnis: 1 µs (= 0.1%) edit: Ich will übrigens gar nicht meckern, ich finde es gut, wenn sich viele Leute den Code anschauen und verbessern. Ist also nicht böse gemeint. Ich befürchte aber, dass es verschenkte Mühe ist, wenn deine Motivation darin besteht die Performance zu verbessern.

Antworten soweit ich mich erinnere (TF darf hier gerne widersprechen ^^): Sollte bei beiden gehen. Insbesondere bei USB wurde zu 1.0 Zeiten viel Schweiß investiert, dass das klappt. Das ist soweit ich weiß, erwartetes Verhalten. Das klingt nach Fehlverhalten. Kann allerdings sein, dass TF irgendwann zwischendurch beschlossen hat, dass mehrere Clients nciht mehr supported werden sollen. Fände ich aber schade, da es viele Anwendungsfälle gibt (gerade im Bereich Ansteuerung durch Android/iOS) wo das funktionieren sollte.

Du konntest dadurch messbare Geschwindigkeitsverbesserungen erzielen? Ich finde deinen Code besser lesbar (habe den getter mit dem Original verglichen), insofern würde ich in jedem Fall dazu raten deine Änderung zu übernehmen. Allerdings kann ich mir nicht vorstellen, dass in einem IO-lastigen System wie TF solche Mikro-Optimierungen messbar helfen. Oder übersehe ich hier etwas? Immerhin ist doch bei "viel" Servo Kommunikation insbesondere viel IO enthalten oder? Wenn ich bedenke, dass die Taktrate der Nachrichten zum Brick bei 1000 Hz liegt (1 ms), dann kann ich mir nicht vorstellen wie eine Optimierung im µs (oder gar ns?) Bereich Verbesserungen bringen kann.

Ich kann dir nicht direkt auf deine Frage antworten. Allerdings glaube ich, dass hier nur wenige direkt mit PipesBox arbeiten. Vielleicht solltest du besser bei PipesBox direkt nach Hilfe fragen. Möglicherweise täusche ich mich aber auch und jemand kann dir auch hier fachkundig antworten

Aus purer Neugier: Ist das die vorübergehende Lösung bis du herausgefunden hast was genau falsch läuft oder ist dieser Fix jetzt final? (+ Ergänzungen wie "einige wenige Einstellungen restoren")

Soweit ich das weiß ist die externe Spannung vom Rest des Bricks/Stacks getrennt. Das heißt du brauchst von woanders noch deine 5V (entweder USB oder Stack)

Stimmt, mein Fall war nur relevant wenn das gleiche Device in mehreren Threads genutzt wurde. Bei Java ist es ja auch bei mehr als einem Device ein Problem. Hoffe der Beitrag war trotzdem halbwegs relevant Viele Grüße Jan

Naja... grundsätzlich bist du halt dafür verantwortlich die Referenzen die du selbst brauchst auch selbst zu behalten Was ich geschrieben habe war eh unsinn. Erst wenn die IPConnection weg ist kommt der hungrige GC und isst alles auf. Weil solange hat die IPConn ja noch ne Referenz. Das ist auch gut so ^^ Ich halte es auf jeden Fall für vertretbar, dass man nur ein Objekt pro Stackelement haben darf. Eine Methode zum Erlangen des Devices aus der IPConnection finde ich nicht vollkommen verwerflich, würde sie aber (wäre es mein Framework) nicht zur Verfügung stellen. Wie ich als IPConnection meine Devices verwalte (z.B. dass ich sie problemlos per UID wiederfinden kann) würde ich verbergen.

Denke schon. Sagen wir ich lege mir ein Device an, verliere dann alle Referenzen (das alte Objekt lebt aber noch wegen ausstehender GC) und möchte mir ein frisches Device zum Weiterarbeiten anlegen. Das würde jetzt schiefgehen. Dann bräuchte ich plötzlich einen expliziten Mechanismus zum Freigeben von Devices, um dieses neue Problem zu umgehen. Ich denke dadurch wird das Fehlerpotenzial eher größer als kleiner. Viele Grüße Jan

Funktionieren andere Methodenrufe an die Bricks? Falls nein würde ich auf eine falsche UID tippen.

Grundsätzlich sollte das bereits jetzt schon gehen oder? Wenn ich mich recht entsinne dann ist die Standardimplementierung von Object doch ein Referenzvergleich oder? Das würde lediglich bedeuten, dass du Probleme bekommst, wenn du für die gleiche UID zwei Device-Objekte anlegst. Ich würde behaupten, dass du dadurch auch von Seiten der TF-Bindings Probleme bekommst. Spätestens bei Verwendung zweier Devices mit gleicher UID in unterschiedlichen Threads können die Bindings für nichts mehr garantieren. Oder übersehe ich gerade einen anderen Vorteil des Überschreibens von hashCode und equals? Ansonsten würde ich es vermutlich über die interne (int/long) UID implementieren.

Meine Vermutung ist, dass es aus einer anderen Sprache übernommen wurde wo für diesen Zweck delegates genutzt wurden. Ich denke dein Vorschlag macht für Java Sinn.

Aufgrund der Erfahrungen der letzten Wochen: Vermutlich spinnt die WiFi-Extension. Denke dein Log gerade ist dabei hilfreich. Das Connection refused bedeutet, dass die Extension den Verbindungsverusch bewusst ablehnt (als würde der brickd dort nicht mehr lauschen).