remotecontrol Geschrieben July 20, 2013 at 07:31 Share Geschrieben July 20, 2013 at 07:31 Hallo, wenn ich zwei Hosts gegen einen Stack connecte, so bekommt der 1. Host einen erneuten enumeration Callback, wenn sich der 2. connected (-> OK). Der 1. Host muss dann die Callbacks neu registrieren (-> OK). Disconnected sich nun der 2. Host, so bekommt der 1. Host aber keinen enumeration Callback mehr und alle Bricklet-Callback sind dennoch weg. Oder habe ich was übersehen? Wie kann ich mitbekommen, wenn sich der 2. Host disconnected und der 1. seine Callbacks neu registrieren muss? Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
AuronX Geschrieben July 20, 2013 at 08:56 Share Geschrieben July 20, 2013 at 08:56 Mir war ehrlich gesagt neu, dass irgendwelche Callbacks ausgeschaltet werden, wenn sich ein Host disconnected... Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
remotecontrol Geschrieben July 20, 2013 at 09:05 Autor Share Geschrieben July 20, 2013 at 09:05 Ist mir bisher auch nicht aufgefallen. Ich versuche aber gerade, meine Anwendung gegen Ausfälle und externe Connects zu stabilisieren und dabei ist mir aufgefallen, dass ich nicht mitbekomme, wenn sich z.B. der brickv disconnected. Danach sind aber "fast" alle Callbacks weg: - von den Sensoren (temp, baro, ambi, humi) kommt nichts mehr (hier hatte ich 5 Sekunden Callback-Period eingestellt) - die Buttons des LCDs senden aber noch Callbacks Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
borg Geschrieben July 20, 2013 at 09:17 Share Geschrieben July 20, 2013 at 09:17 Der Brickv setzt wenn du ihn schließt alle Callbacks die er selbst aktiviert wieder auf Default zurück. Das ist aber kein Standardverhalten der Firmware oder sowas, das macht der aktiv. Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
remotecontrol Geschrieben July 20, 2013 at 09:45 Autor Share Geschrieben July 20, 2013 at 09:45 Das bedeutet aber, dass eine 2. Anwendung die Callbacks der 1. ebenfalls löscht, ohne dass die 1. das mitbekommt. Ist für mich erstmal kein Problem, da es wohl eher die Ausnahme ist, dass sich eine 2. Anwendung connected. In meinem Fall prüfe ich nun ob x Sekunden kein einziger Sensor-Callback erfolgt ist, wenn ja starte ich den Enumerate neu und registriere damit die Callbacks neu. Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
AuronX Geschrieben July 20, 2013 at 09:59 Share Geschrieben July 20, 2013 at 09:59 In diesem Bereich sind aber viele weitere Probleme denkbar: - Period wird nur angepasst (statt alle 50ms nur alle 5s) - Threshold wird angepasst - irgendwelche anderen Settings werden überschrieben Am Ende muss man einfach festhalten, dass keine zwei beliebigen Anwendungen auf den gleichen Stack zugreifen dürfen. Wenn beide Anwendungen von dir stammen, dann kannst du natürlich Spielregeln einhalten durch die das trotzdem funktioniert... (etwa: Einheitliche Periods, kein Abschalten bei Schließen der Anwendung usw.) Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
Loetkolben Geschrieben July 20, 2013 at 10:08 Share Geschrieben July 20, 2013 at 10:08 Hallo zusammen. Nur mal eine (Design) Frage: Kann man nicht feststellen, dass ein Callback gesetzt wurde und dementsprechend handeln? Also sollte die zweite Anwendung nichts tun oder vorher eine Warnung ausgeben. Waehre das nicht eine Notwendigkeit fuer den Brickviewer? Der Loetkolben Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
AuronX Geschrieben July 20, 2013 at 10:34 Share Geschrieben July 20, 2013 at 10:34 Ich gebe dir recht Loeti. Wenn zum Start des Brickv schon ein Callback aktiv war, dann sollte er zumindest am Ende nicht deaktiviert werden. Vorsichtiger kann man aber leider nicht mehr sein. Beim Beenden beispielsweise den Wert vom Start wiederherzustellen ist beispielsweise auch nicht für Anwendungen geeignet, die zwischendurch Änderungen am jeweiligen Wert vornehmen. Deswegen sollte grundsätzlich klar sein, dass zwei Anwendungen aktiv aufeinander abgestimmt werden müssen, damit sie sich parallel verbinden können. Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
Loetkolben Geschrieben July 20, 2013 at 10:42 Share Geschrieben July 20, 2013 at 10:42 Deswegen sollte grundsätzlich klar sein, dass zwei Anwendungen aktiv aufeinander abgestimmt werden müssen, damit sie sich parallel verbinden können. Jep und in diesem Fall wird dem Brickviewer eben eine besondere Stellung zu teil. Zum einen ist er notwendig um mal etwas zu kontrollieren oder an einem Bricklet etwas einzustellen und zum anderen ist die Anwendung nicht von einem selbst geschrieben. Wenn Tinkerforge da etwas aendern moechte/sollte/wuerde dann ist das wohl leider nicht in 10 Minuten gemacht. Der Loetkolben Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
The_Real_Black Geschrieben July 21, 2013 at 17:45 Share Geschrieben July 21, 2013 at 17:45 Der Brickv setzt wenn du ihn schließt alle Callbacks die er selbst aktiviert wieder auf Default zurück. Das ist aber kein Standardverhalten der Firmware oder sowas, das macht der aktiv. Dass erklärt so manchen Bug... kann man dieses Verhalten ausschaltbar machen? Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
borg Geschrieben July 22, 2013 at 08:51 Share Geschrieben July 22, 2013 at 08:51 kann man dieses Verhalten ausschaltbar machen? Ob wir die Callbacks jetzt am Ende wieder ausschalten oder nicht ändert ja nichts daran das Brickv an den Einstellungen rumstellt. Entweder Brickv zeigt Daten an und stellt auch entsprechend dafür alles ein oder Brickv zeigt keine Daten an. Man könnte höchstens Brickv so umstricken, das nur noch getter verwendet werden. Das ist aber bei Sachen die reaktionsschnell seien sollen (IO-4/16, Ind. Digital In etc) blöd, da man dadurch Lag reinbekommt. Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
remotecontrol Geschrieben July 22, 2013 at 09:42 Autor Share Geschrieben July 22, 2013 at 09:42 Ich finde das Verhalten vom brickv OK. Ich frage mich aber dennoch ob es prinzipiell überhaupt möglich wäre, einen Event zu verteilen, wenn durch eine andere Anwendung callbacks gelöscht werden. Das geht dann doch in Richtung Firmware. Für den normalen Betrieb ist das eher ein Sonderfall, da nicht zwei Anwendungen gegen einen Stack arbeiten sollten. Aber das "mal eben den Detailstatus auslesen" z. B. über brickv ist doch nicht so selten. Dann wäre es gut, wenn die Anwendung solche Fälle erkennen kann. Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
Loetkolben Geschrieben July 22, 2013 at 12:43 Share Geschrieben July 22, 2013 at 12:43 Ich versuche es mal so: * Einmal mit dem Brickviewer auf den Stack geclickt und ein produktives System ist "im Eimer". ?! * Ich kann mir auch gut vorstellen, dass man mehrere Bricklets hat, wobei ein Bricklet produktiv/testhalber Callbacks sendet und man mit einer anderen Software/Brickviewer an den anderen Bricklets arbeitet. Um es einfach zu machen sollte man die Brickletcallbacks pro Bricklet im Brickviewer enablen/disablen koennen. ... Hier kommt mir die Frage nach dem Zugriff von aussen wieder in den Sinn! ;D Der Loetkolben Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
AuronX Geschrieben July 22, 2013 at 19:12 Share Geschrieben July 22, 2013 at 19:12 Ich denke einen "non-intrusive-mode" im Brick-Viewer kann man schon gebrauchen. Eben mit Hinweis, dass das nicht so hochwertige Daten sind (gerade was kurzfristige Änderungen auf den IO-Bricklets betrifft). Zitieren Link zu diesem Kommentar 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.