Remise à 0 d'un Sub VI après exécution

[Robin.EGG]

Bonjour,

Dans le cadre d'un projet j'ai du créer un sous-vi contenant un régulateur PI.  Celui-ci fonctionne parfaitement, mais le problème est que si je tente de relancer ma simulation, mon régulateur garde la valeur de ses actions (proportionnelle et intégrale) de l’exécution précédente. C'est embêtant dans mon cas car le régulateur pilote un moteur en couple. Si par exemple le régulateur avait un MV (Manipulated Value) de 30, je me retrouve avec un couple de 30Nm au au lancement de simulation.

Comment pourrais-je réinitialiser le sous-vi au lancement de la simulation? J'ai tenté de mettre les actions intégrales et proportionnelles à 0 mais cela ne change rien. La seule solution que j'ai actuellement est de fermer LabView et de le rouvrir ...

[laboukouille]

Salut,

J'arrive pas à lire ton VI tu as une version trop récente pour moi tu peux envoyer une photo??

Tu peux essayer avec un nœud de propriété (Valeur) au début du sub

[ben64]

Il n'y a rien dans le sous-vi qui puisse conserver une valeur en mémoire. Le problème se situe probablement au niveau du vi principal. Y aurait-il un registre à décalage non initialisé?

Ben64

[Robin.EGG]

Non, je n'ai pas utilisé de registre à décalage, il me semblait aussi que le sous-vi ne retenait rien. Je ne comprend vraiment pas le problème! Je remet pourtant bien à 0 l'ensemble des valeurs d'entrée de mon sous-vi avant exécution mais rien n'y fait.

[ouadji]

à ce stade du problème il serait bon de pouvoir avoir accès à l'ensemble du code. Il semble évident qu'il y a là un comportement "vicieux" à déloger ... placer des BP, des probes, localiser le problème, réduire le code, etc ... Il n'y rien de mieux qu'un code qui plante pour apprendre quelque chose. Mais sans le code au complet, impossible. (si cela est "possible" pour vous bien entendu).

[Robin.EGG]

Bonjour,

Merci de votre aide, voici le vi. J'ai isolé partie contenant le régulateur PI (sous-vi), désole si c'est un peu bordélique.

En gros je génère un sinus à fréquence fonction de la cadence actuelle de pédalage (normalement extraite du moteur mais ici remplacée par la variable "Cadence actuelle". Le régulateur PI agit sur l'amplitude du sinus (qui est ensuite envoyée comme commande de couple au moteur). Les bornes du PI sont soit calculées par la puissance max du cycliste ( un cycliste ne peut fournir un grand couple si il pédale rapidement) soit par un couple max au démarrage (pour éviter d'avoir un trop fort couple).

J'espère que vous comprendrez un peu mieux le VI.

Merci

[ben64]

Il n'y a pas de register à décalage mais il y a un feedback node (ce qui est identique). Par défaut ce feedback node est initialisé lors de la compilation ou du chargement du vi. Fait un clic-droit sur ce feedback node et sélectionne "Move Initializer One Loop Out". Un terminal apparaitra à l'entrée de la boucle temporisée. Relie une constante 0 à ce terminal.

Ben64

[ouadji]

oui, en effet, il y a un noeud de rétroaction ... mais la sortie de ce noeud de rétroaction ne semble pas intervenir dans les valeurs d'entrée du sous-vi "PI-Régulator" ... or, d'après la question de départ c'est le comportement de ce sous-vi qui pose soucis, soit les valeurs des sorties "Prop.action" et "Integ.action". Au risque de n'avoir rien compris de la question de départ, pour moi ce noeud de rétroaction n'intervient pas dans le comportement spécifique du sous-vi "PI-Régulator".

[ben64]

En effet, il n'intervient pas dans les valeurs d'entrées du régulateur PI. L'énoncé du problème est un peu confus, ça semble être un problème d'avoir un couple de départ de 30 Nm mais c'est pourtant la valeur par défaut du contrôle "couple max au démarrage". Comme la cadence actuelle est de 0 au démarrage alors c'est la valeur de 30 qui est utilisée. C'est donc cette valeur qu'il faudrait changer pour diminuer le couple au démarrage.

Ben64

[ouadji]

Accessoirement, coder "plus propre" serait "un plus".

Je dis "accessoirement" ... en réalité, c'est absolument essentiel. Un code "propre", quelque soit le langage utilisé, est un b-a-ba incontournable. Mais ici, avec un langage graphique, donc visuel ... ce n'est pas une facilité ou une option, c'est une Loi. Montre moi comment tu codes, et je te dirai qui tu es ... non ? Pour soi-même, pour la lisibilité, la compréhension, pour le partage du code, pour la maintenabilité, et j'en passe. Plus un code est "brouillon", plus il posera des problèmes, difficiles à identifier/déceler, difficiles à débugger, difficiles à résoudre. Plus un code est "brouillon", plus son espérance de vie sera courte.

Ouf ... je me suis fait plaisir là !     (ça fait du bien  )

Par exemple peut-être quelque chose comme ceci ... il s'agit exactement du même code !