Instrumentation - Programmation indépendante du matériel

[ATdevice]

Bonjour,
Voilà pour un client nous devons automatiser un banc de test/caractérisation de semi-conducteurs, et l'idéal serait d'utiliser Visual ou Python (pas de LabView!)

Le problème que je rencontre, c'est que le client est principalement équipé d'appareils Rode & Schwartz (oscilloscopes et générateurs de fonction), et à l'entreprise nous n'avons que du HP (générateur) et Lecroy (oscilloscope), et la location de matériel n'est pas donnée.

Les mesures à effectuer sont assez "complexes" : mesure de différence de delay (ordre de la ns) sur 4 voies, largeur de pulse (ns également), calcul d'écart type, mise en mémoire de "fantôme" et histogramme.

En clair notre oscilloscope Lecroy sait faire tout ça, les oscilloscopes du client aussi (je n'ai plus les différentes références en tête, mais ils ont des specs similaires), donc j'aimerais savoir si il existe une librairie HAL qui pourrait convenir, sans devoir se taper la liste des commandes pour chaque référence d'oscillo/générateur et devoir faire la cross-compatibilité à la main (surtout si le parc matériel évolue ou si on a besoin d'ajouter des fonctions au banc).

Merci
-----

[jiherve]

Bonjour,
comment la communication s'effectue t elle ?
GPIB ?
si oui voir les normes afférentes.
JR

[antek]

Et dans le pire des cas tu demandes l'identité de l'appareil et paf, tu appliques les paramétrages de communication adéquats !

A noter qu'elle ne sera pas strictement indépendante mais adaptée.

[ATdevice]

Pour la communication ce sera USB, mais j'imagine que les commandes sont les mêmes qu'en GPIB. Il faudrait que je creuse du côté des DLL, avec un peu de chance il y a des exemples téléchargeables pour intégrer dans Visual, je n'ai encore jamais fait de Python mais on risque de nous le demander un jour ou l'autre donc je préfère anticiper aussi

[A voir en vidéo sur Futura]

[Antoane]

Bonjour,

Je ne connais pas de bibliothèque permettant de s'adresser aussi bien à du Lecroy qu'à du R&S. Je prendrai volontiers si tu trouves, mais pense qu'il y a peu d'espoir vu la quantité de travail que cela représenterait vs. les besoins a priori assez précis. De là, seules des entreprises pourrait payer pour de telles bibliothèques, qu'elle n'auraient que peu d'intérêt à rendre publiques (et, surtout, libres).

A cela s'ajoute les différences de traitement entre les fabricants: les instruments n'utilisent pas nécessairement les mêmes méthodes pour des résultats similaires (e.g. le eRES de Lecroy vs. le HiRes de tektro : https://teledynelecroy.com/doc/diffe...eres-and-hires pour fabriquer des bits).

Si le but du SCPI - I3E 488.2 est de simplifier et normaliser les commandes entre les instruments, seules les plus simples sont immédiatement transposables (le seul fait de récupérer les courbes demande des scripts différents suivant les oscilloscopes ).

[Patrick_91]

Bonjour,

Justement c'est tout l’intérêt de LabView, si on récupère les librairies de chaque appareil de mesure c'est toujours cela de moins a se tapper ... et cela permet de capitaliser au fil du temps n ajoutant des modules spécifiques quand nécessaire (meme chose pour les protocoles de communication), c'est sur cela coute mais cela permet de capitaliser sur le travail effectué .. je ne vois pas Python au même niveau mème si on peut tout faire c'est clair ..
La logique de commande d'un scope ou analyseur de spectre de deux marques différentes étant tout aussi différentes , il faut malheureusement une bibliothèque de synthaxes de commandes par matériel.
A plus

[ATdevice]

Bonjour,

vu la quantité de travail que cela représenterait vs. les besoins a priori assez précis. De là, seules des entreprises pourrait payer pour de telles bibliothèques, qu'elle n'auraient que peu d'intérêt à rendre publiques (et, surtout, libres).

Ouais c'est bien dommage...

Justement c'est tout l’intérêt de LabView

C'est pour un projet particulier, nous n'avons pas LabView dans nos bureaux car aucune utilité pour nous, et le client n'en veut pas non plus (j'ai cru comprendre que la gestion entre des projets faits dans différentes versions c'était galère).
Le projet embarque une carte électronique que nous avons conçu et qui est elle aussi pilotée en USB, et nous n'avons pas de librairies LabView pour l'utiliser, seulement une DLL avec une interface graphique faite sous Visual. Le but est d'étendre cette interface graphique pour prendre en charge les différents appareils de labo pour automatiser toute la procédure, et comme on n'a pas les mêmes appareils de mesure que le client et qu'ils n'ont pas la possibilité de nous en prêter le temps du développement, ça m'aurait aidé d'avoir une lib "universelle"

[Patrick_91]

Hello,

Oui cela avait existé sur certains simulateurs de test fonctionnels , des macro commandes avaient été développées pour organiser les test en incluant toutes les mesures de tension, courant, commutations, spectres , oscillogrammes fréquences etc etc ..
Mais le problème, et c'est logique, on passait plus de temps a développer les bibliothèques de base appareil par appareil et marque par marque de toute façon ..
Le remède a tout ceci serait le développement d'un langage de test universel qui s'imposerait a tout constructeur en tant que couche de programmation supérieure, mais cela sent le déjà vécu .. c'est un travail colossal le caractère universel d'un tel langage est difficile a concevoir ...
A plus

[polo974]

Bonjour,

il y a quelques projets:
https://instrumentkit.readthedocs.io...est/intro.html
https://pyvisa.readthedocs.io/en/latest/