Notes de Labo

J’ai dû faire récemment une petite comparaison des tarifs des balises personnelles de sécurité pour la navigation en mer. Quelques réflexions:

• La législation est démodée
• Les capacités techniques ont fait un bond en avant énorme depuis 2000
• C’est cher…

Législation

Sur la législation, la France demande toujours l’enregistrement de toutes les « stations VHF », ça inclut donc une balise de sécurité individuelle qui n’aura de toute sa vie qu’une communication ASN de type « MOB » le jour où elle sera déclenchée… mais on demandera toujours à l’inscription un numéro MMSI (de station « fixe » donc) à lui associer et d’avoir le CRR.

La loi fait « comme si » un équipement de protection individuel sur piles à messages ASN « tout numérique » pour un marin seul à bord ou sur le pont présentait le même risque de parasitage des bandes de fréquences qu’une station VHF fixe: Pour donner une idée, la portée d’une balise de sécurité est entre 4 et 8 miles, une VHF fixe c’est 25 miles, on n’est pas du tout dans la même catégorie.

Je pense que cela limite artificiellement l’usage de ces équipements individuels de sécurité, avec potentiellement des morts évitables.

On pourrait sans doute pour ces équipement aligner la législation sur celle des balises SARSAT (pas de CRR, simple déclaration après création de compte sur le site du CNES). On n’est plus en 1970!

Dernier point: pourquoi deux sites concurrents pour l’enregistrement des balises? (et je ne parle même pas du design des sites)
VHF: site de l’ANFR
SARSAT: site du CNES

Capacités techniques

On trouve maintenant des balises individuelles qui font SARSAT, AIS, VHF ASN + GPS/GLONASS/GALILEO tout en un, portables sur le gilet ou dans la poche. Il est probablement temps d’en faire un équipement recommandé pour la navigation de nuit.

Tarifs

Les tarifs sont assez élevés, probablement liés à deux contraintes fortes:

1. la batterie

La batterie doit tenir plusieurs années sur étagère et garantir un fonctionnement >24h après ce délai.

2. La certification

Les certifications sont apparemment nationales: il y a des différences entre les USA et la France, et les règles ont l’air différentes (code national à flasher lors de l’achat, registre national) entre pays, alors que les canaux de détresse et le fonctionnement sont régis par la convention SOLAS et sont donc internationaux. Il y a peut-être, au moins en Europe, une petite marge de simplification possible.

Et maintenant les prix..

LabView XControl.

Dans les événements prédéfinis de la façade, on a « data change », « direction change », exact « State change » et « display State change ».
Quelles sont les conditions qui déclenchent ces événements ?
« Data change ». Donc d’après la doc cet événement déclenche quand on passe à une valeur sur le terminal, sur une variable locale, ou une valeur de propriété du contrôle.
En pratique, si je définis une variable locale sur un des éléments du contrôle, est-ce-que si je modifie cette variable, j’ai le déclenchement de cet événement?
Donc j’ai défini une variable locale à l’intérieur de la boucle while du VI façade. Cette variable est actualisée à chaque itération. Et je n’ai aucun déclenchement de l’événement Data change.

Exécution en mode débug
Ok donc à l’exécution en mode debug un qu’est ce qu’on observe ? Que le contrôle ne sort jamais de sa boucle while interne tant qu’il est en exécution.
Il reste en exécution jusqu’à ce que le VI appelant soit arrêté donc sa valeur n’est jamais mise à jour. Et donc on ne peut pas récupérer sa valeur simplement en liant l’icône de du contrôle du X Control dans sur le diagramme du VII appelant, puisque le programme ne sort pas de la boucle, tant que le VI façade s’exécute.

Test simple avec un Xcontrol de type nombre
En ouvrant l’exemple thermomètre de la commande X, on voit que dans l’exemple, le thermomètre transmet sa valeur à l’indicateur. Pourtant, dans notre cas, dans notre test, ça ne fonctionne pas, donc la question c’est pourquoi ? Donc, si on ouvre le diagramme pendant l’exécution, clic droit ouverture ouvrir le diagramme. Et qu’on essaie de modifier la valeur du du champ du champ numérique. Je vois qu’en mode debugs on arrive, on ne rentre jamais dans la modification de valeur dans le changement de data.

Bon donc on a refait un exemple de zéro un XControl je lui mets en numérique sur sa face avant. Je le mets dans 1VI qui fait une boucle avec un bouton stop de base quoi. Et le but du jeu, c’est de sortir la valeur du numérique du X Control dans un indicateur qui est sur le VI de test.
Donc je mets mon numérique sur la facade, le numérique du X Control qui est une commande. Je le relie à à mon fil data out dans l’événement changement de données.
Théoriquement, si j’ai bien compris, l’événement chargement de données devrait se déclencher quand on clique sur le contrôle dans le dans le VI de test pour changer sa valeur. Donc voilà, je lance le VI de test, je mets 2 dans le truc. Réponse, non. Je n’ai pas l’évènement change la valeur.

La seule condition qui s’exécute, c’est le time out. Dans l’exemple de contrôle X du thermomètre, il est indiqué que labview appelle le VI façade avec Valeur changed si l’utilisateur change la valeur du thermomètre. De fait, si je modifie avec le slide la valeur du thermomètre, et bien le changement qui est fait sur l’indicateur dans le VI de test.

Sur le forum de LAVA, on a quelqu’un qui indique avoir le même problème, c’est que le data changed ne ne se produit jamais. Et une des réponses qui est donnée, sans plus de détails. Est que Le data change property de l’action Output Doesn’T Trigger de Data Changed Évent.

Affecter une valeur à la propriété « Value signal » du XControl dans le VI de test permet de déclencher l’événement « Data change » du XControl.

Ajouter un événement face avant de valeur changée sur le la commande numérique à l’intérieur du X Control permet de récupérer la valeur du X Control en sortie de la boucle while mais ne déclenche pas les évènements.

Création de propriété.
Quand on crée une propriété pour le X Control, on peut ensuite, sur le VI de test déposer un nœud de propriété qui accédera à cette propriété.
On peut donc manipuler le X contrôle par des nœuds de méthode et des nœuds de propriété accessibles dans le menu d’application depuis le VI de test.
Lorsque ces propriétés et ces méthodes sont appelées, elles déclenchent à leur tour les événements display change ou data change en fonction de ce qui est prévu.
On définit une propriété en lecture, écriture. Je peux écrire dans cette propriété, auquel cas j’aurais le déclenchement de l’événement Display Change dans le X Control. De la même façon, si je définis une méthode, j’aurais un appel à cet événement display change dans le X Control. Par contre, si je fais un appel en lecture à une propriété de X Control que j’ai défini alors je n’ai aucun événement qui est déclenché dans le X Control.

L’événement Display change peut être conçu comme un événement qui se déclenchera si on manipule l’objet X Control depuis l’extérieur, par exemple depuis un autre VI, un autre contexte. Par contre, la manipulation d’événements internes ou X Control, par exemple, un clic de souris sur un champ du X contrôle ou un changement de valeur à l’intérieur du X contrôle doivent être gérées différemment avec des événements de face avant comme dans une boucle classique.

Dans le cas d’un X Control défini comme indicateur, je peux affecter de façon classique des données à l’indicateur dans le VI de test. Chaque fois qu’une donnée est affectée au X contrôle, alors j’ai le l’événement « Data change » qui est déclenché.