Highlights {#highlights}
Das Speichern von Gerätebereichseinstellungen wirkt sich nun nicht mehr nur auf die Sitzung aus, in der die Änderungen vorgenommen wurden, sondern auf alle Client-Sitzungen, die dieses Gerät nutzen.Der zweite Viewer nutzt anstelle des Pollings seine eigene In dieser Sitzung aktualisiert Die Aktualisierung erfolgt auf Basis von Ereignissen. Für jede aktive Sitzung wird genau ein Ereignis gesendet; an den Client, der den Schreibvorgang durchgeführt hat, wird kein Ereignis zweimal gesendet.
Es ist nun möglich, dem Client die physische Anordnung der Mounts des Geräts zu melden. Bisher meldete der Dienst stets die in der Sitzung konfigurierten Mounts. Die Beschriftung, die angibt, welcher Wert gerade angezeigt wird, wird nun in allen Ausgabeformaten strukturell stets korrekt dargestellt.Wenn ein Gerät eigene Befestigungsstandards verwendet, passt sich der Dienst nun diesen Änderungen an. Der bisherige Dienst gab die beim Start des Geräts ermittelten Werte unverändert zurück und überprüfte sie danach nicht erneut. Jetzt kann dieser Standard auf Anfrage entsprechend dem Darstellungsintervall des Clients aktualisiert werden. Da auf Seiten des Dienstes eine Ratenbegrenzung gilt, kommt es nicht zu einer Überlastung der Verbindung zum Gerät durch Clients mit hoher Darstellungsfrequenz. Sobald sich die Halterung tatsächlich gedreht hat, wird die Änderung einmalig gemeldet.Interne Verbesserungen {#internal-improvements}
Experimentelle automatische Korrektur der Gierwinkelabweichung des Greifers. Ein neues Servicemodul korrigiert die durch die Trägheit des drahtlosen VerseGrip verursachte Gierwinkelabweichung im geschlossenen Regelkreis. Der absolute Gierwinkel des Greifers wird an die Bewegung des daran befestigten, gekoppelten Inverse3 oder Minverse angepasst, und sobald alle Qualitätskriterien erfüllt sind, wird ein Korrekturwert in die Firmware des Greifers geschrieben.Diese Funktionist standardmäßig deaktiviertund steht nur zur Verfügung, wenn der experimentelle Opt-in-Schalter aktiviert wird. Darüber hinaus verfügt sie über einen Laufzeit-Schalter, der alle im Betrieb befindlichen Griffe sofort nach dem Umschalten zwangsweise in den Korrektur-Aus-Zustand zurückversetzt. Da es sich um eine Funktion handelt, die in die Firmware des Geräts geschrieben wird, ist dieser Schritt unverzichtbar.Das Schreiben von Einstellungen für alle Geräte erfolgt nun nach dem Alles-oder-Nichts-Prinzip. Bevor auch nur ein einziges Gerät geändert wird, werden alle ausgewählten Geräte – einschließlich des Firmware-Status und des Bereitschaftszustands – überprüft. Daher kommt es in einer Flotte mit unterschiedlichen Firmware-Versionen nicht mehr vor, dass der Vorgang in einem Zustand, in dem nur die Hälfte der Geräte umgestellt wurde, zum Stillstand kommt, wenn beim zweiten Gerät ein Fehler auftritt.Die Überprüfung der Antworten aus der Firmware des Griffs wird nun für jede einzelne Anfrage nachverfolgt. Da nur ein gemeinsamer Ergebnisslot zur Verfügung stand, kam es beim gleichzeitigen Senden von zwei Anfragen gelegentlich vor, dass die Antworten verwechselt wurden. Außerdem konnte ein einziger mehrdeutiger Wert sowohl „Ablehnung“ als auch „keine Antwort“ bedeuten, was dazu führen konnte, dass eine Ablehnung eine Flut von Wiederholungsversuchen auslöste.Derzeit verfügt jede Anfrage über ein eigenes Token, und Anfragen, die nicht gesendet wurden, werden gar nicht erst registriert. Falls eine Antwort verloren geht, wird dies als Fehler bestätigt, anstatt dass die Verarbeitung ins Stocken gerät. Dieser Überprüfungsvorgang verursacht keine Belastung, solange keine unbearbeiteten Anfragen vorliegen.Die Kalibrierung des Inkwell-Docks wird durch die Überprüfung der Firmware-Funktionen des neuen Griffs nicht beeinflusst. Wenn der Stift in das Dock gelegt wird, erfolgt eine vollständige Neukalibrierung der Position. Dies ist das korrekte Verhalten bei allen ausgelieferten Stiften, unabhängig von der Firmware-Version. Dieser Fall wurde ausdrücklich von den Mindestanforderungen an die Funktionen für die rechnergestützte Orientierungskorrektur ausgenommen, wobei der Grund für diese Ausnahme nicht auf Vermutungen beruht, sondern an der entsprechenden Stelle ausdrücklich angegeben ist.Korrekturen {#fixes}
Die Rückstellung der Schwerkraftkompensation erfolgt nun nicht mehr als Überkompensation, sondern kehrt zum korrekten Standardwert zurück.Entgegen dem Namen,config/Schwerkraftkompensation の Skalierungsfaktor Das Feld ist kein Multiplikator. Es handelt sich um die zusätzliche Nutzlastmasse des Endeffektors (in Kilogramm), die zusätzlich zum Gewicht des Geräts selbst ausgeglichen wird. Frühere Neufestlegungen wurden wörtlich genommen und als „neutraler“ Koeffizient 1 zurückgesetzt. Da dies einer fiktiven Nutzlast von 1 Kilogramm entspricht, drückte das Gerät nach dem Zurücksetzen den Griff weiter nach oben. Dies weicht vom Verhalten des Geräts unmittelbar nach dem Anschließen ab. Beim aktuellen Zurücksetzen wird nun der tatsächliche Standardwert wiederhergestellt. Das heißt, die Kompensation ist aktiv, undSkalierungsfaktor は 0 wird eingestellt. Das Gerät trägt nur sein Eigengewicht und arbeitet so, als ob keine Nutzlast vorhanden wäre. Falls die Anwendung die Kompensationsstärke über einen Reset erhöht hat, legen Sie den erforderlichen Wert stattdessen explizit fest.
Durch das Zurücksetzen der Home-Return-Funktion ist diese nun tatsächlich wieder aktiv. config/home_return Beim Zurücksetzen wurde dem Aufrufer mitgeteilt, dass die „Home Return“-Funktion aktiviert sei, obwohl sie tatsächlich deaktiviert war. Jetzt werden durch das Zurücksetzen tatsächlich die Werkseinstellungen (aktiviert) wiederhergestellt, und die Werte, die die Anwendung anschließend ausliest, stimmen mit den tatsächlich vom Gerät verwendeten Werten überein.Nach dem Schreiben von Daten zur Befestigung oder Ausrichtung im Gerätebereich bleibt die Anzeige bei anderen Clients nicht mehr veraltet. Vor Version 3.5.6 wurden bei Schreibvorgängen für das Gerät selbst (die für alle Sitzungen, die dieses Gerät nutzen, gemeinsam gelten) nur die Einstellungen des Clients aktualisiert, der den Schreibvorgang durchgeführt hat, während die Geräte-Root für niemanden aktualisiert wurde. Andere Clients, die dasselbe Gerät nutzten, zeigten weiterhin die veralteten Werte an, bis sie eine Abfrage durchführten. Jetzt werden alle Sitzungen, die dieses Gerät nutzen, benachrichtigt.Bei Inkwell-Docks wird nun nicht mehr nach einer einzigen Ablehnung aufgegeben. Da der Status des vorherigen Docks auf das nachfolgende Dock übertragen wurde, wurde beim zweiten Dock die erste Ablehnung als Ende des Wiederholungszeitraums behandelt. Der Wiederholungszeitraum wird nun bei jedem Dock-Versuch zurückgesetzt.Ein Datenkonflikt bei der Tick-Verarbeitung des Wireless VerseGrip-Geräts wurde behoben. Es kam vor, dass die Geräte-ID vom Verbindungsthread neu zugewiesen wurde und der Staging-Prozess diese währenddessen unter einer anderen Sperre auslas. Nun wird die ID nur einmal unter der richtigen Sperre erfasst, und alle nachfolgenden Pfade (einschließlich der abgelehnten) basieren auf dieser Kopie.Das Problem der nicht synchronisierten Bereitstellung von Nachrichten bei vier Wireless-VerseGrip-Sendern wurde behoben. Die vier Sendewege hatten zwar die Nutzdaten und Prüfsummen zusammengestellt und die Übertragung angefordert, jedoch keine Schreibsperre erworben. Daher kam es vor, dass sich die Verarbeitung durch zwei Sender im gemeinsam genutzten Puffer überschnitt.Mögliche kompatibilitätsbrechende Änderungen {#potential-breaking-changes}
Es gibt keine Änderungen an der API, den Kabelverbindungen oder den Einstellungen. Die Standardausgabe entspricht in Byte-Einheiten der Version 3.5.5, es wurden keine Routen entfernt oder umgeleitet, es gibt keine Abweichungen in der veröffentlichten C-API, und es wurden keine Konfigurationsschlüssel umbenannt, entfernt oder mit neuen Standardwerten versehen.Anwendungen, die sich für die Vorschau- oder experimentellen Oberflächen des SDK angemeldet haben,müssenin diesem ZyklusMigrationsmaßnahmen durchführen. Dazu gehören Änderungen an der Switch-Hierarchie sowie entfernte Token-Sätze. Die einzelnen Schritte sind im ergänzenden Änderungsprotokoll für Entwickler aufgeführt.Das Zurücksetzen der Schwerkraftkompensation liefert nun andere Werte als in Version 3.5.5. Die Form von Feld, Route und Antwort hat sich zwar nicht geändert, doch durch das Zurücksetzen Skalierungsfaktor aber 1 Anwendungen, die davon ausgingen, dass Daten dort geschrieben werden, verwenden stattdessen die werkseitigen Standardwerte 0 wird übernommen. In beiden Fällen bleibt die Entschädigung selbst weiterhin gültig. Bitte legen Sie den Wert explizit fest, ohne sich auf das Zurücksetzen zu verlassen. Siehe die oben genannten Korrekturen.Nach dem Zurücksetzen der Home-Return-Funktion bleibt diese aktiviert und nicht deaktiviert. Die Form von Feld, Route und Antwort bleibt unverändert; in Anwendungen, bei denen davon ausgegangen wurde,dass die Home-Return-Funktion durch das Zurücksetzen deaktiviert wird, ist sie stattdessen aktiviert. Wenn Sie die Funktion nach dem Zurücksetzen deaktivieren möchten, müssen Sie sie explizit auf „Aus“ setzen. Siehe die oben genannte Korrektur.Der Client erhält nun zusätzliche Konfigurationsereignisse. In dieser Sitzung aktualisiert Eine Anwendung, die davon ausgegangen ist, dass Ereignisse ausschließlich durch eigene Einträge ausgelöst werden, empfängt diese Ereignisse nun auch, wenn ein anderer Client, der dasselbe Gerät nutzt, Änderungen vornimmt. Anschließend wird die gesamte Ansicht neu gezeichnet. Dies ist das beabsichtigte Ergebnis des oben beschriebenen Fan-Out-Verfahrens. Bei Clients, die lediglich Ereignisse empfangen und daraufhin die Seite neu laden, sind keine Änderungen erforderlich.
