probleme de code qui bloque aleatoirement

[cyril13110]

bonjour à tous,

Je rencontre un problème sur un compteur de décrément.

Le code fait fonctionner une machine spéciale, le code de l’api occupe 92% de la mémoire programme, je n’ai pas regardé l’état du chien de garde.
En résumé, la logique d’initialisation du compteur comporte un comparateur et un ou avec un bit.
Le DB26.DBW260 est écrit depuis un pupitre protool et il est déclaré en format compteur, cette variable remonte donc directement en BCD pour attaquer l’entrée ZW du compteur.
Le DB26.DBW260 est copié dans le DB26.DBW262. La recopie intervient juste après la comparaison qui active l’init du compteur.

Après plusieurs tests, nous nous sommes rendus compte que le comparateur fonctionne 1 coup sur 2 et de manière ponctuelle l’entrée S du comparateur ne détecte pas le front montant.
De plus, certaines valeurs ne semblent pas être accepté lors de l’init du compteur (10 à 16, 100 et bien d’autre)

Je viens de penser au chien de garde mais en lisant l’aide, apparemment, l’Api passerai en stop avec défaut et ici ce n’est pas le cas.

Est-ce qu’il y aurai une raison à ce type de problème ?
Est-ce que la mémoire programme à 92% ne poserai pas problème ?
Est-ce que le chien de garde passe à tous les coups l’API en stop avec erreur ?

Merci d’avance

ps: depuis mon bureau l'envoye des fichiers images est bloqué je ne peux donc pas vous mettre l'imprime ecran du code depuis le bureau

[Cyril93]

bonjour à tous,

Je viens de penser au chien de garde mais en lisant l’aide, apparemment, l’Api passerai en stop avec défaut et ici ce n’est pas le cas.

Bonjour Cyril et bienvenue.

L'API passe en stop seulement si l'OB80 n'as pas été chargé. Si tu as un doute sur le chien de garde charge l'OB80 et met une variable dedans que tu incrémentes à chaque appel de bloc.
De mémoire c'est 150ms de base mais tu peux changer la valeur de déclenchement.

[cyril13110]

Bonjour Cyril et bienvenue.

L'API passe en stop seulement si l'OB80 n'as pas été chargé. Si tu as un doute sur le chien de garde charge l'OB80 et met une variable dedans que tu incrémentes à chaque appel de bloc.
De mémoire c'est 150ms de base mais tu peux changer la valeur de déclenchement.

l'API ne passe ni en stop ni indique d'erreur programme. Et puis si c'etait le chien de garde je pense que mon client aurai eu un probleme bien avant.
Pour les OB d'erreur j'ai posé un large panel (de OB80 à OB121) il y a une semaine suite à la rupture d'un segment profibus.

Ce qui m'intrigue un peut pour mon probleme de code qui se deroule mal, c'est que en simulation ca fonctionne sans probleme.
sur l'API réel ca fonctionne et de temps en temps il y a un ratté de maniere vraiment trés aléatoire.
L'entrée set du compteur qui rate un frot montant, le comparateur qui ne fonctionne pas de temps en temps.

En faite ca fait 4 ans que je code sur du siemens mais c'est la 1 ere fois que je rencontre ce type de probleme.

[JC87]

Je comprend pas ce qu'Il y a en fait sur ton entrée de comptage, un bit ou une comparaison ?

JC

[itasoft]

slts,
on ne sait pas ce que ça compte, LOL
c'est un codeur incrémental ? un compteur bestial qui compte les impulsions qui arrivent sur une entrée automate ? ou autre chose ?
ps:
Si c'est un compteur rapide pour codeur incrémental , celui-ci est asynchrone par rapport au cycle automate, ça peut tout expliquer.

[Cyril93]

slts,
Si c'est un compteur rapide pour codeur incrémental , celui-ci est asynchrone par rapport au cycle automate, ça peut tout expliquer.

Non c'est le compteur Z donc pas de comptage rapide, perso l'entrée ZW avec la valeur au format <C#Decimal> j'aime pas trop.
Le comptage se passe bien c'est l'init qui merde ? c'est ce que j'ai compris en tout cas.
N'y a t'il pas une erreur sur le format <C#Decimal> entre ton afficheur et ton API qui pourrais faire que la valeur ne soit pas prise en compte par le bloc.

[cyril13110]

alors le compteur décompte le nombre d’ouverture d'une vanne afin d’éditer un créneau d'une seconde qui va servir a activer le cycle de nettoyage d'un électro-aimant.
j'ai reussi a faire passer l'imprime ecran ca pourra aider.
En gros la logique du set du compteur a un comportement que j'ai du mal a comprendre.
ces 3 lignes de codes sont fonctionnelles jusqu’à un moment ou l'API je ne sais pas pour quelle raison rate le frond montant du SET et du coup tous ce bloque et le compteur ne redémarre plus.

Le comparateur sert à initialiser le compteur sur changement de valeur depuis un pupitre, cette variable est configurer en compteur dans le pupitre d'origine par le fournisseur et passe donc le bon format C#xxx.

en simulation (oui ok je sais que la simulation ne reflète pas la vrai réaction d'un API mais ca permet de tester le fonctionnement global) je n'arrive pas a avoir cette etat de blocage et le comparateur ne rate jamais de changement de valeur.

du coup je ne comprend pas ce qui pourrai faire que l'API rate la comparaison 1 coup sur 2 et le front montant sur le set de manière aléatoire.

[itasoft]

slts,
La recopie intervient juste après la comparaison qui active l’init du compteur.

je me demande si on ne compare pas du BCD avec du INT ?

[cyril13110]

slts,
La recopie intervient juste après la comparaison qui active l’init du compteur.

je me demande si on ne compare pas du BCD avec du INT ?

Jy ai pensé a ce probleme le buffer DBW262 prend la bonne valeur en caractere.

et que ca soit directement dessous ca poserai probleme?

Mais si c'est ca pour le comparateur ok mais du coup quesqui expliquerai que le set du compteur rate le front montant ?
ca se produit de temps en temps une fois le compteur arrivé a la fin du comptage la ligne du dessous avec la bascule SR, ca genere un front montant sur le set etle compteur ne réagit pas.

[philou77]

Salut !

Ca ressemble a des problèmes de scrutation..
Par exemple :
une tempo xx évaluée plusieurs fois dans le cycle..
à un endroit elle peut être fausse et à un autre elle peut être vraie (si le temps de cycle est long)
Parade :
évaluer la tempo dans l'ob1 une seule fois et mettre un bit à la place
U T 5
= M0.0
Uiliser ce bit partout dans le programme et non plus la tempo !

Ton DBW260 est positionné par un pupitre, il peut se faire n'importe quand dans le cycle il me semble.
Le mieux est donc de faire
DBW260 <> DBW262
= Mx.x
utiliser Mx.x à la place de la comparaison actuelle !

Puis pour le transfert
un mx.x
spb=M001
DBW262 = DBW260
M001: NOP 0

Ps : le saut est nécessaire car les chargement et transfert se font indépendamment du RLG !!

cordialement