From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

Discussions au sujet de NI LabVIEW

annuler
Affichage des résultats de 
Rechercher plutôt 
Vouliez-vous dire : 

Comment faites-vous vos rapport de test?

Bonjour,

 

Pour ce qui on des rapports de test à faire, j'aimerais savoir comment faites-vous vos rapports de test, quelle outils utilisez-vous?

 

Moi, jusqu'à maintenant j'utilisai le toolkit report avec un model excel, je venai renseigner pour chaque mesure, la où elle devait apparaitre sur le rapport modèle. Cette manière de faire est viable si il n'y a pas trop d'information à gérer et que le nombre de mesure à renseigner est toujours la même... je créai mon "modèle" excel vide que je venai remplir à l'aide du toolkit report, cette méthode peut devenir tres longue si il y beaucoup d'information à renseigner...

 

Je rencontre un soucis pour un de mes banc de test qui demande cette fois ci beaucoup plus d'information à renseigner (plus de 200 mesures environ) et ce nombre d'information peut varier d'un test à l'autre... l'utilisation du toolkit report devient alors bcp trop lourd à gérer.

 

Pour le moment, chaque test effectué est enregistré dans une base de donnée SQL et je ne sais pas comment créer mon rapport de test. Je dispose du logiciel DIadem mais franchement je ne comprend grand chose, je n'arrive même pas à récupérer mes informations de ma base de donnée dans diadem et l'utilisation de script ne m'enchante pas dutout (je n'ai jamais fait ca...).

 

Connaitriez-vous un moyen "simple" (sans utiliser Diadem?) de créer mon rapport de test?

 

Merci d'avance pour vos réponse.

0 Compliments
Message 1 sur 5
3 239 Visites

 Salut, pour répondre à la première question « comment faites-vous vos rapport de test ? ».

> Sous TestStand les rapports au format XML avec feuille de style xsl (activation report du result processing).

 

> Sous LabVIEW, j’utilise le plus souvent Excel. Comme toi. Avec un classeur modèle, que je duplique et dans lequel je vais écrire les données, via le Report generation toolkit. Souvent dans le classeur modèle, il y a un onglet modèle, qui je duplique pour chaque essai.

j'ai actualisé un post que j'avais fait pour faire un rapport sous Excel

 

J’utilise alors la puissance du tableau Excel. Parfois il y a des formules pour convertir des mesures brutes en corrigées, faire un calcul de statut sur des limites, afficher un graphique. J’insère également des macros, pour des petites mises en forme (autoscale d’un graphique, ...).

 

Toutes les solutions ont des limites, mais j’ai réalisé « quelques » applications, et 200 points n’a pas été une limite. 50 000 points sur 4 voies, je comprends, mais pour 200 points, non.

 

question 1) pourquoi cette méthode peut-elle devenir très longue ? peux-tu préciser SVP ? si tu as 200 points tu peux écrire les 200 points en une seule fois. Tu as un code qui explique cela?

 

Pour les bases de données tu peux utiliser le database connectivity toolkit (je pense que tu l’utilises déjà), pour gérer la base. Tu fais l’écriture dans la base pendant le test. Par la suite, à la fin du test, une autre application peut extraire les donner pour générer le rapport… qui peut être un modèle Excel, avec le RGT.

 

J’aimerai comprendre les lenteurs que tu « ressens » avec un rapport de 200 points.

A suivre, A+ Luc

banniere Luc Livre NXG Champion.png

Luc Desruelle | Mon profil | Mon blog LabVIEW | Auteur livre LabVIEW : Programmation et applications - G Web
Certified LabVIEW Architect (CLA) & Certified TestStand Developper (CTD) | LabVIEW Champion

MESULOG - LinkedIn site | NERYS - NERYS Group
| directeur CEO MESULOG
| CODIR - NERYS group

0 Compliments
Message 2 sur 5
3 197 Visites

Bonjour Luc et merci pour ta réponse,

 

Déjà je me rend compte que ma facon de faire (modèle excel que je viens compléter ensuite)  n'est pas délirante et c'est déjà une bonne chose 😉

 

Ensuite oui j'utilise également les bases de données(SQL express) à l'aide du toolkit connectivity.

 

Pour mon problème de lenteur, je remarque que dans l'exemple que tu propose tu viens rapatrier tes données en une seule fois sous forme d'un gros tableau à un seul endroit, mon problème est que je ne peux pas faire ca, perso je dois compléter mon modèle avec des informations qui se situent un peu partout, je ne peux donc pas sortir un tableau de "x" valeur d'un seul coup. Je dois récupérer chaque valeur pour venir la placer à un endroit précis. Je te joint un screenshot d'un VI rapport que j'avais réalisé pour un autre Banc de test, il n'y avait pas 200 points a renseigner par raport et pourtant ya déjà du monde dans mon VI.

 

Je pense que la lenteur vient du nombre de fois que j'utilise les VI "Ajouter du texte au rapport" ou "ajouter une image au rapport". Plutot que de les mettre à l'enfilade comme j'avais fait, je pourrais peut etre faire une boucle for avec un seul "ajouter du texte au rapport". Je ne suis pas sur que je gagnerais du temps car ca reviendrait au même... (Vi peut etre plus lisible par contre? pas sur...)

 

Comme tu peux le voir sur le screenshot, pour chaque information à renseigner (ref cable, Numéro de lot, version BT ...) je viens lui indiquer a quel endroit il doit placer l'info sur mon rapport modèle. La structure condition "1Gb/s" à 12 conditions différentes (varie en fonction de la fréquence du test) et la condition ("1paire") varie de 1 à 4 paires. ca te donne une idée du nombre de position différentes à renseigner dans mon rapport de test. Pour chaque test on ne réalise pas à chaque fois les 12 fréquences sur les 4 paires différentes mais déjà si on test 3 fréquences différentes sur 2 ou 3 paires ca fait déjà pas mal de monde pour construire mon rapport de test final je trouve...

 

A la fin de mes test, quand le VI de génération du rapport de test se lance, je peux attendre environ 5 bonne minutes voir plus avant d'avoir mon rapport construit. Je ne peux pas me permettre de laisser l'opérateur attendre comme ca, il faudrait qu'une fois le test fini il ai le rapport 1 min plus tard grand max pour pouvoir enchainer sur une autre pièce. Au final, la génération du rapport de test est plus longue que le test en lui même...

 

Je viens de faire le calcul du nombre de valeur à renseigner pour mon "nouveau" banc de test. Dans le pire des cas, j'aurais 992 valeur de test, sans compter les références (version BT, Ref du Cable, nom opérateur, date ect...). Je pense pouvoir claquer quelque tableau en un seul bloc cette fois ci mais ca fait quand mème pas mal de référence à renseigner...

 

Bref, j'aurais aimé savoir si il n'y avait pas une autre méthode plus rapide tout en continuant d'utiliser le TGR. Peut etre une autre facon de construire mon VI qui serait plus efficace que la mienne?.

 

Je possède diadem mais à première vu ca me semble bien compliqué à utiliser(les scripts ne m'insipre pas dutout...) et vous parlez aussi de TestStand mais je ne connais pas dutout nonplu...

 

Merci d'avance pour vos réponse.

 

Message 3 sur 5
3 173 Visites

j'ai oublié de préciser que le rapport de test doit se générer automatiquement à la fin de chaque test sans intervention de l'opérateur.

 

A la fin du test l'opérateur récupère le rapport de test imprimé directement. Je dois donc tout construire par programmation.

0 Compliments
Message 4 sur 5
3 171 Visites

Ok pour le retour.

Je me permets : 200 c'est pas "si énorme que cela" et "5 minutes c'est énorme" pour 200 valeurs, même en 200 écritures

 

Je te propose de faire un test : tu mesures le temps

  • avec ton exemple (exemple minimized) 
  • avec ouverture d'Excel "maximized". Pourquoi? l'OS va attibuer plus de ressource à une application au premier plan.

C'est juste pour avoir une idée

 

après sur ton code en 200 écriture, il faudrait faire un test avec

  • Excel au premier plan,
  • Au départ, désactiver les mise à jour graphique "screenUpdating" False, remettre à la fin "True"

ScreenUpdating.png

 

  • éventuellement "xlCalculationManual" de la méthode "Calculation", pour ne pas activer les mises à jour des calculs, et remettre à la fin.

A tester, je pense

A+

banniere Luc Livre NXG Champion.png

Luc Desruelle | Mon profil | Mon blog LabVIEW | Auteur livre LabVIEW : Programmation et applications - G Web
Certified LabVIEW Architect (CLA) & Certified TestStand Developper (CTD) | LabVIEW Champion

MESULOG - LinkedIn site | NERYS - NERYS Group
| directeur CEO MESULOG
| CODIR - NERYS group

0 Compliments
Message 5 sur 5
3 155 Visites