le 05-12-2017 07:06 AM
merci ouadji pour ta reponse
une info supplementaire sur mes investigations:
Lorsque mon code a buggé
1)j'ai capturé le tableau de cluster dans le sous-vi,
2)puis je l'ai réinjecté sous forme de constante. j'ai détourné la définition de type du VI principal (partie superieure de la structure condition) et j'ai cablé cette constante sur une condition précédente (envoi CSV)
3)resultats: ca ne marche pas. PAR CONTRE, si je cable la constante DIRECTEMENT sur l'entree du sous-vi, CA FONCTIONNE
4) conclusion: a un moment du VI principal, la définition de type qui irrigue le sous-vi se corrompt. le probleme est que je ne peux pas dire où, car je n'ai aucun retour d'erreur
5) question: peux tu me dire precisement quelle portion de code tu as modifié pour résoudre le probleme?
si c'est bien le cluster de definition de type du VI parent qui s'est corrompu, alors je le remplacerais par une variable globale
le 05-12-2017 07:12 AM
salut, as-tu fait le test de forcer la recompilation du code?
-> ouvre le code du main
-> Ctrl + Shift + clic sur la fléche Run du vi
A+ Luc
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
le 05-12-2017 07:47 AM
Salut en LV2016, j'ouvre le code et il fonctionne. Je force la recompilation (CTRL + Shift + Run) et il n'execute plus le code. Idem je place une Prob, et il crashe
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
le 05-12-2017 07:51 AM
le comportement n'est plus le meme après le crash...
je tente de changer le connecteur du VI pour l'obliger à changer le passage des paramètres
Alors le code me semble fonctionner "normalement". (indexation opérationnelle).
A tester.
Le code semble ne pas passer correctement les valeurs du Main vers le paramètre d'entrée du sous-VI (bug du sous-VI). Le forcer a refaire, semble corriger le problème.
A+
Luc
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
le 05-12-2017 07:51 AM
j'ai finalement fait ce que ouajid m'a conseillé: modifié la forme du diagramme en enlevant et remettant les indicateurs. le bug semble etre disparu.
je vais marquer son post comme solution.
j’espère que ce problème ne se répercutera pas ailleurs dans mon code, car cela sous-entend un manque de fiabilité de l'interpréteur du langage
merci a tous pour votre aide
le 05-12-2017 08:55 AM
oui, j'avais retiré et ensuite replacé l'indicateur dans le sous-VI,
j'avais aussi enlevé et replacé ensuite le tunnel d'indexation.
Tu parles d'une définition de type ... je n'ai rien touché à cette définition.
ça "sent" l'insane object, ça sent le VI corrompu.
Est-ce un bug ? dans l'absolu on peut dire que "oui", dans la mesure où, dans la suite dynamique de tes différentes manip et constructions, LV à un moment donné à "créé" une erreur "d'objet" ou une erreur de code. Je ne suis pas dans le saint des saints du team des développeurs de LV, je ne peux donc pas définir avec précision le type d'erreur que LV à généré. Ceci dit, la notion "d'insane objet" existe et est reconnue (et même un peu documentée). Ce type de soucis est rare et oblige souvent à reconstruire le VI complètement. Sur 5 1/2 ans d'utilisation de LV j'ai rencontré une fois ce type de soucis. Le problème est que ce type de problème est souvent le résultat d'une longue suite de manips et donc dépendant d'un grand nombre d'interactions au sein du code interne de LV. Moi, j'appelle ça un bug dynamique, ce sont les pires !! Un bug qui dépend de l'historique avec quasi une infinité de paramètres possibles .... le cauchemar de tous les développeurs !!! Dans un code comme LV qui comporte des millions de lignes de code, ce type de bug peut persister des années et peut-être ne jamais être identifié. Vive la programmation