Points forts {#highlights}
Les modifications apportées à la configuration de la gamme d'équipements sont désormais synchronisées sur toutes les sessions client utilisant cet équipement, et non plus uniquement sur celle à l'origine de la modification.Le deuxième client n'effectue plus d'interrogation, mais utilise sa propre mis à jour lors de la session Actualisation des événements : chaque session disposant de cet appareil reçoit exactement un événement ; l'émetteur ne reçoit en aucun cas deux événements.
Il est désormais possible de transmettre au client l'emplacement réel de l'appareil, etnon plus systématiquement le mode d'installation configuré dans la session.L'étiquette servant à indiquer le type d'emplacement d'installation actuellement affiché est désormais conçue de manière à garantir une précision optimale et à s'adapter à tous les formats de sortie.
Lorsque l'appareil met à jour automatiquement ses valeurs de référence, le serveur suit ces modifications. Auparavant, le serveur renvoyait les valeurs enregistrées au démarrage de l'appareil, sans jamais les vérifier à nouveau par la suite.Désormais, le serveur peut actualiser cette valeur de référence à la demande, en fonction du rythme de rendu propre à chaque client, et appliquer une limitation de débit côté serveur afin d'empêcher les clients effectuant des actualisations à haute fréquence de saturer la liaison de l'appareil ; de plus, il ne signale les modifications qu'après une rotation effective de l'appareil.
Améliorations internes {#internal-improvements}
Correction automatique expérimentale de la dérive de lacet de la poignée. Le nouveau module de service assure une correction en boucle fermée de la dérive inértique en yaw du Wireless VerseGrip : il effectue un ajustement entre l’angle de yaw absolu de la poignée et les mouvements de l’ Inverse3 ou du Minverse appairé auquel elle est connectée ; dès qu’une série de seuils de qualité est atteinte, une valeur de correction est écrite dans le micrologiciel de la poignée. Cette fonctionnalitéest désactivée par défaut etn’est disponible que lorsque le commutateur expérimental est activé ; elle dispose d’un commutateur d’exécution qui,qui, une fois activé, force tous les manettes connectés à désactiver immédiatement cette fonctionnalité — ce qui est indispensable pour une fonctionnalité qui écrit dans le micrologiciel de l'appareil.La mise en œuvre des configurations sur tous les appareils fonctionne désormais selon le principe « tout ou rien ». Avant de modifier un appareil, le système vérifie l'ensemble de la sélection (y compris les capacités du micrologiciel et l'état de préparation des appareils) ; ainsi, un groupe d'appareils dont les versions de micrologiciel diffèrent ne restera plus bloqué dans un état de transition partielle en raison d'une erreur sur un deuxième appareil.Les signaux de confirmation du micrologiciel de la poignée sont désormais suivis séparément pour chaque requête. Auparavant, toutes les requêtes partageaient un même emplacement de résultat, ce qui pouvait amener deux requêtes simultanées à écraser mutuellement leurs réponses ; une même valeur ambiguë pouvait également signifier à la fois « rejeté » et « aucun résultat »,ce qui pouvait conduire à une interprétation erronée du refus comme nécessitant une nouvelle tentative, provoquant ainsi une avalanche de tentatives. Désormais, chaque requête est associée à son propre jeton ; les requêtes qui n’ont jamais été réellement envoyées ne génèrent aucune trace, tandis que les réponses perdues sont marquées comme ayant échoué, ce qui évite tout blocage. Le programme de nettoyage chargé de cette opération n’entraîne aucune surcharge lorsqu’il n’y a pas de requêtes en attente.L'étalonnage de la base de l'Inkwell n'est pas affecté par le nouveau contrôle des capacités du micrologiciel de la poignée. Le fait de placer le stylo dans la base déclenche un réétalonnage complet de la posture, ce qui est valable pour tous les stylos déjà commercialisés, quelle que soit la version du micrologiciel ; ce processus est expressément exclu du seuil minimal de capacité introduit pour la correction de cap calculée, et cette exclusion est explicitement mentionnée au point d'appel, sans qu'il soit nécessaire de la déduire.Corrections {#fixes}
La réinitialisation de la compensation de la gravité permet désormais de rétablir la véritable valeur par défaut, au lieu d'une compensation excessive. Malgré ce nom,config/compensation_de_la_gravité sur facteur_d'échelle Le champ « Coefficient » ne correspond pas à un multiplicateur : il s'agit de la masse de la charge de l'actionneur final (en kilogrammes) que l'équipement compense en plus de son propre poids. La réinitialisation précédente avait interprété ce nom au sens littéral, le rétablissant comme un coefficient « neutre ». 1——c'est-à-dire une charge fictive d'un kilogramme——; par conséquent, après la réinitialisation, l'appareil pousse la manette vers le haut, ce qui ne correspond pas au comportement d'un appareil nouvellement connecté. Désormais, la réinitialisation rétablit les véritables valeurs par défaut : la compensation est activée, et facteur_d'échelle pour 0, ce qui signifie que l'équipement ne supporte que son propre poids et ne prend en compte aucune charge. Si, jusqu'à présent, votre application utilisait la réinitialisation pour augmenter l'intensité de la compensation, veuillez désormais définir explicitement la valeur souhaitée.La fonction de réinitialisation permet désormais de la réactiver correctement. Auparavant, concernant config/retour_à_l'accueil La réinitialisation désactive la fonction de retour à la position initiale, tout en indiquant à l'appelant que cette fonction est activée. Désormais, la réinitialisation rétablit véritablement les valeurs par défaut d'usine (activées), et la valeur lue par la suite par l'application correspond à la valeur réellement utilisée par l'appareil.Les écritures concernant le mode d'installation ou l'orientation au niveau de l'appareil ne rendent plus obsolètes les données des autres clients. Avant la version 3.5.6, une écriture sur l'appareil lui-même (partagée par toutes les sessions détenant cet appareil) ne rafraîchissait que la configuration du client à l'origine de l'écriture, tandis que les paramètres de routage au niveau de l'appareil n'étaient rafraîchis pour personne. Les autres clients sur le même appareil continuaient d'afficher les anciennes valeurs jusqu'à ce qu'ils effectuent une interrogation active. Désormais, toutes les sessions détenant cet appareil reçoivent une notification.Les tentatives répétées d'amarrage du socle Inkwell ne sont plus abandonnées après un seul refus. L'état de l'amarrage précédent est conservé d'une tentative à l'autre ; ainsi, la deuxième tentative considère le premier refus comme la fin de la fenêtre de réessai. Désormais, chaque tentative d'amarrage réinitialise la fenêtre de réessai.Correction d'un conflit d'accès aux données dans le cycle de tick de l'appareil Wireless VerseGrip. L'identifiant de l'appareil pouvait être réinitialisé dans le thread de connexion alors qu'un chemin de traitement temporaire était en train de lire cet identifiant sous un autre verrou. Désormais, cet identifiant fait l'objet d'un instantané unique protégé par le verrou approprié, et chaque chemin en aval (y compris les cas de refus) fonctionne à partir de cette copie.Correction d'un problème de mise en file d'attente des messages non synchronisés sur quatre émetteurs Wireless VerseGrip. Ces quatre chemins de messages sortants n'obtenaient pas de verrou d'écriture lors de l'assemblage de la charge utile et de la somme de contrôle, puis lors de la demande d'envoi ; par conséquent, deux émetteurs pouvaient se chevaucher sur un tampon partagé.Modifications susceptibles d'entraîner des incompatibilités {#potential-breaking-changes}
Aucune modification n'a été apportée à l'API, aux protocoles de communication ou aux paramètres. La sortie par défaut correspond mot à mot à celle de la version 3.5.5 : aucun chemin de routage n’a été supprimé ou modifié, l’API C publique ne présente aucune différence, et aucune clé de configuration n’a été renommée, supprimée ou dotée d’une nouvelle valeur par défaut.Les applicationsayant choisi d’activer la préversion du SDK ou les interfaces expérimentalesdoivent effectivementeffectuer leur migration au cours de ce cycle, ce qui inclut une modification au niveau des commutateurs et la suppression d’un ensemble de jetons ; chaque étape est consignée dans le journal des mises à jour associé au projet.La valeur renvoyée par la réinitialisation de la compensation de gravité diffère de celle de la version 3.5.5. Aucun champ, route ou structure de réponse n'a été modifié, mais la réinitialisation des dépendances va facteur_d'échelle Écrit comme 1 L'application utilise désormais les valeurs par défaut définies en usine. 0—— La fonction de compensation reste activée quoi qu'il arrive. Veuillez définir explicitement cette valeur plutôt que de compter sur la réinitialisation ; voir les instructions de correction ci-dessus.Après la réinitialisation, la fonctionnalité de retour à la position initiale reste désormais activée, et non désactivée. Aucun champ, routage ou structure de réponse n'a été modifié, mais les applications qui dépendent de la réinitialisationpour désactiver cette fonctionnalitéconstateront désormais qu'elle est activée. Pour la désactiver, veuillez la désactiver explicitement après la réinitialisation ; reportez-vous aux instructions de correction ci-dessus.Le client recevra des événements de configuration supplémentaires. On supposait initialement que mis à jour lors de la session Les applications qui ne recevaient auparavant cet événement que lorsqu'il était généré par elles-mêmes reçoivent désormais cet événement lorsqu'un autre client modifie un périphérique partagé par les deux, et reçoivent ensuite un rendu complet de la configuration. Il s'agit là du résultat attendu du mécanisme de diffusion mentionné plus haut ; les clients qui ne relisent les données qu'après la réception de l'événement n'ont aucune modification à apporter.
