Exemple de code OOP avec LabVIEW

[Desruelle_luc]

Le code LabVIEW est dans le post 

Cet article a pour finalité d'illustrer un exemple de mesure de déformation via une couche d'abstraction qui est réalisée en Objet. Dans cet exemple, le code des classes est contenu dans le fichier binaire de l'exécutable. Nous ne sommes pas sur une architecture "plugin". Un autre article permet de décrire l'évolution de ce exemple vers une architecture "plugin", avec les classes dans des PPLs, pour obtenir une couche d'abstraction. 

La couche HAL est un  couche intermédiaire entre le logiciel applicatif et le matériel. Cette couche offre des fonctions standardisées de manipulation du matériel tout en cachant les détails techniques de la mise en œuvre. 

Suite à une demande sur le forum, un exemple de OOP avec LabVIEW

La demande : Pouvoir configurer le même logiciel avec 2 cartes d'acquisition différentes.

L'initialisation, boite de dialogue de configuration, acquisition et close des références seront donc différents en fonction des cartes.

Donc:

• Une class Deformation avec 2 enfants ConditionneurExterne et CarteSpecifique
• 1 méthode configuration, avec dans chaque class enfant une méthode en dynamic dispatch pour la fenêtre de configuration spécifique, qui ser donc appelée lors de la définition de l’objet de la carte utilisée
• Idem pour les méthodes acquisition, méthode acquisition en dynamic dispatch
• Les données spécifiques à une carte sont donc dans la donnée privée de la class de l’enfant.

J’ai fait un « brouillon d’architecture ». Je précise car le code n’est pas totalement « propre ».

Le projet UML

En LabVIEW cela va ressembler à

> Dans le projet  

et sur la hiérarchie des class

Une class Deformation avec 2 enfants

> ConditionneurExterne

> CarteSpecifique

il y a un vi exemple

 avec en face avant

 en fonction du boolean "Conditionneur Externe", l'objet sera du type d'une carte ou de l'autre. Le code de la class correspond sera alors exécuté.

liens sur le site de National Instruments : LabVIEW Object Oriented Programming Resource Directory

Luc Desruelle |  Voir mon profil | Contact

CLA : Certified LabVIEW Architect / Certifié Architecte LabVIEW
CTD : Certified TestStand Developer / Certifié TestStand LabVIEW

[Ficare]

question annexe (mais applicable à d'autres projets utilisant OOP) : comment faire pour partager "proprement" des classes OOP entre plusieurs projets ?

Un des intérêts de l'OOP est la réutilisation, donc logiquement, il est interessant de maintenir un seul source, utilisé dans plusieurs projets. Faut-il faire un répertoire spécifique, qu'on intégre systématiquement dans chaque nouveau projet ? Dans ce cas comment se passe la gestion avec le CCS ?

Bonne journée ...

[Desruelle_luc]

Bonjour, très bonne question à aborder lors de la prochaine rencontre LUGE ! J’espère que vous serez avec nous!!.

Nous avons effectivement du code objet que nous utilisons dans beaucoup de projets. Certains sont des toolkits « propriétaires », d’autres sont téléchargés via le LabVIEW Tools Network. S’ils ne sont pas de NI LabVIEW, ils sont localisés sous le dossier « user.lib ».

Dans mon cas, le code est réalisé pour les besoins d’un client. Contractuellement il a accès à l’ensemble du code. L’ensemble du code est donc distribué au client. Donc même le code de la « user.lib » est « copié » dans le dossier « Windows » du projet client, et n’est plus localisé sur le disque c:\.... Cette opération est réalisée à un moment « défini » du projet.

Nous avons un dépôt SCC par projet, donc il y a du code commun entre les dépôts SCC.

Cela présente des inconvénients et des avantages. En avantages, nous pouvons citer de « figer » une version exacte du code avec la version logicielle validée, le code peut être « ouvert » sur n’importe quel PC. En inconvénient une duplication du code entre les dépôts SCC.

Pour résumer, seulement le code « lié » à la version de LabVIEW n’est pas distribué dans le dépôt SCC du projet.

[Desruelle_luc]

Pour répondre à la question (après 6 ans !) : comment faire pour partager "proprement" des classes OOP entre plusieurs projets ?

La réponse est de partager les classes dans des PPLs ou lvlibp.

Un article sur le sujet est >>> VI dynamique, HAL en Objet, plugins via classes dans PPLs ou code externe entre 2 exe LabVIEW