Restauration scie MEBA 310 G CNC

  • Auteur de la discussion ingenieu59
  • Date de début
M

masseykubota

Compagnon
ingenieu59 a dit:
[attachment=0]branchement automate 3.doc[/attachment]

A bientôt.

Tu es sûr que l'automate délivre du 24V (les automates qui ont ça sont rares)? Ne faut il pas brancher cette borne 24V à une alim externe? Teste avec un voltmètre!

Le câblage du multitron est bizarre aussi : il y a deux sorties qui sont court-circuités non? A moins que ce ne soit une entrée pour un affichage?

A+
 
I

ingenieu59

Compagnon
Bonsoir,

tu l' as dit, c' est pas gagné .
J' ai corrigé le schéma pour utiliser l' alim du mitsu .
Concernant les encodeurs, je ne peux donner aucune information sur leur pas .
Je sais que pour l' angle, j' ai du faire des petites poulies pour que cela corresponde à la valeur du multitron .
Pour la remise à zéro, une fois en butée ( vérin à fond ) , il n' y a que très peu de différence , de l' ordre de 1 à 2 / 10 ème de mm d' erreur.
Le branchement du multitron est un casse tête .

Je confirme, Le mitsu délivre bien 24 V dc ( testé )

A bientôt.
 
I

ingenieu59

Compagnon
masseykubota a dit:
Voila

Dans ton dernier message tu sembles un peu ... déçu que cela te parait difficile! C'est normal ce que tu as entamé est déjà d'un petit niveau en automatisme!

Bon courage et tiens nous au courant de tes galères!

A+

Bonjour MK,

Merci pour tout le travail que tu as fait, je ne l' avais pas vu hier, nos messages se sont croisés .

Je suis novice en matière de ladder, mais en même temps, en tant qu' autodidacte , j' aime bien lire et apprendre . Mais , surtout, comprendre ce que je lis .

Je te tiens au courant de l' évolution .

A bientôt.
 
M

masseykubota

Compagnon
Bjr,

N'empêche tu as de quoi t'amuser! Tu t'es lancé dans un truc qu'est pas particulièrement simple.

Bon courage.

A+
 
I

ingenieu59

Compagnon
Bonjour tout le monde,

merci pour ton soutien MasseyKubota.

à l' heure actuelle, l' automate est entièrement branché . ( c' était chose facile!! )

Voici une photo de l' armoire électrique basse :

DSC02783.JPG


Reste à voir deux petites choses, le capteur pnp n' allume pas la led de l' automate. ( peut-être une inversion à faire ( le + va au - ) et inversement ) ou le capteur est HS
Et tous les voyants, s' allument quand j' actionne les boutons, mais, j' aimerai qu' ils soient éteints quand on est en mode auto ,( c' est juste un fil à déplacer ) sauf un , celui du départ cycle.
 
M

masseykubota

Compagnon
ingenieu59 a dit:
Reste à voir deux petites choses, le capteur pnp n' allume pas la led de l' automate. ( peut-être une inversion à faire ( le + va au - ) et inversement ) ou le capteur est HS
Et tous les voyants, s' allument quand j' actionne les boutons, mais, j' aimerai qu' ils soient éteints quand on est en mode auto ,( c' est juste un fil à déplacer ) sauf un , celui du départ cycle.
Bonjour,

Si j'ai bien compris ta carte d'entrée d'automate est une carte npn car tu as relié les boutons à la masse. Elle n'accepte donc que les capteurs npn...

d'où le problème du capteur.

Tu peux vérifier si ton capteur fonctionne en mettant un voltmètre entre la sortie et la masse.

A+
 
I

ingenieu59

Compagnon
Bonjour MK,

en effet, vu mon schèma électrique, il fallait un capteur NPN, que j' ai réussi à trouver dans toutes mes déposes .
Certains réagissaient ( led interne allumée ) mais pas à l' automate . D' autres, rien de rien. Donc, forcément HS.
Merci pour le petit tuyau , je les testerai à l' occasion.

Maintenant, tout est rentré dans l' ordre.

Je peux communiquer entre le PC et le FX2N.

Mais, il reste néanmoins un problème à résoudre . Pouvoir communiquer entre le PC et le terminal BEIJER E-610 . En voulant paramétrer les ports RS 232, RS 422 et RS 485, Il me marque "jumper not found" , or, en démontant la tôle de derrière, pour voir s' il y a des cavaliers, à priori , il manque une carte !!
Si quelqu' un pouvait m' en fournir une même d' occasion ( prix par MP ).

Reste la partie programmation à faire, mais si je ne peux pas utiliser le terminal, c' est rappé pour le moment , parcequ' il faut rentrer des variables .

A bientôt
 
R

rednexage

Compagnon
Salut,

Cela fait un moment que je suis ce post. Je permet de faire quelques remarques concernant la programmation de l'automate.

Je pense qu'il aurait été judicieux de passer par une étude GEMMA afin de figer le fonctionnement attendu de l'automate. Par ailleurs je pense qu'il est plus judicieux de gérer le mode "manuel" au moyen de l'automate plutôt que de le shunter (ne serais-ce que pour gérer d'éventuelles fonctions anticollision)

Concernant les G7, pourquoi avoir fait un gros grafcet GPN plutôt que de l'avoir répartis en G7 de tâche avec un GCH pour piloter le tout ? Ce qui serait à mon sens plus simple à traduire en ladder, et plus digeste à programmer et à débugger. Par ailleurs une telle hiérarchie permet d'optimiser au mieux le temps de cycle.

Enfin la traduction en ladder est à mon sens erronée. Je pense que cette programmation nous amènera à un SFC fugace. En effet qu'est ce qui empêche l'automate de sauter toutes le étapes du SFC lors d'un même tour de cycle ? Dans ta traduction pour peut que plusieurs réceptivités successives soit vraies, tu aura plusieurs étapes simultanément actives.
Cette programmation ne respecte pas les règles 2 et 3 du G7, à savoir " Le franchissement d'une transition se produit lorsque la ou les étapes immédiatement précédentes sont actives et que la réceptivité associée est vraie " et " le franchissement d'une transition active la ou les étapes immédiatement à la suite et désactive la ou les étapes immédiatement précédentes ".

De plus je ne vois pas ou est fais l'initialisation de tes sfc lors d'un démarrage à froid ou à chaud de l'automate. Un autre exemple me vient en tête, ton compteur, tel que programmé il va incrémenter à chaque tour de cycle automate ou tu sera à l'étape X200. Pour éviter ceci il faut incrémenter le compteur sur un front montant de l'étape X200.

Enfin pour ton détecteur PNP, tu peux t'en servir sur ta carte, il suffit de le relayer afin d'envoyer un signal négatif à ta carte d'E/S.

Attention aussi au codeur, il se peut que les valeurs soit erronées en entrée automate, ceci sera du à la fréquence de rafraichissement des E/S. Il faudrait calculer la fréquence max des impulsion envoyées par le codeur et connaître la valeur de filtrage de tes E/S à moins d'avoir une entrée de comptage rapide (comme sur le tsx17 de télémécanique) mais je ne vois aucune borne de raccordement pour la tresse de blindage.

Je pense avoir fait le tour pour ce soir.
 
I

ingenieu59

Compagnon
Bonjour et merci rednexage pour ton analyse .

Je me pose également la même question pour les encodeurs .
Alors, j' ai deux solutions :
la première consiste à faire un retour en arrière, c' est à dire mécanique ( avec Fdc règlables selon la longueur souhaitée ou selon l' angle souhaité ( avec 2 Fdc presque côte à côte pour la précision )).
La seconde consiste à mettre des compteurs rapides . Par conséquent, la programmation sera revue en incluant les blocs...

Si j' ai voulu la mettre en manuel, c' est pour éviter ce pourquoi elle a été jetée . Car si l' automate est en panne, je peux me servir de la machine à 100 % en manuel . En attendant la réparation .

A bientôt.
 
M

masseykubota

Compagnon
rednexage a dit:
Salut,

Cela fait un moment que je suis ce post. Je permet de faire quelques remarques concernant la programmation de l'automate.

Bonjour,

rednexage a dit:
Je pense qu'il aurait été judicieux de passer par une étude GEMMA afin de figer le fonctionnement attendu de l'automate. Par ailleurs je pense qu'il est plus judicieux de gérer le mode "manuel" au moyen de l'automate plutôt que de le shunter (ne serais-ce que pour gérer d'éventuelles fonctions anticollision)
C'est ce que je pense aussi, mais quel travail! C'est en fait le premier truc auquel j'ai pensé.

rednexage a dit:
Concernant les G7, pourquoi avoir fait un gros grafcet GPN plutôt que de l'avoir répartis en G7 de tâche avec un GCH pour piloter le tout ? Ce qui serait à mon sens plus simple à traduire en ladder, et plus digeste à programmer et à débugger. Par ailleurs une telle hiérarchie permet d'optimiser au mieux le temps de cycle.
Il y a un seul cycle de prévu, je suis d'accord qu'on arrive à la limite de la page... donc à la limite d'un seul (gros) grafcet.

rednexage a dit:
Enfin la traduction en ladder est à mon sens erronée. Je pense que cette programmation nous amènera à un SFC fugace. En effet qu'est ce qui empêche l'automate de sauter toutes le étapes du SFC lors d'un même tour de cycle ? Dans ta traduction pour peut que plusieurs réceptivités successives soit vraies, tu aura plusieurs étapes simultanément actives.
Pas si c'est rentré dans l'ordre que j'ai donné, mais c'est effectivement très délicat à mettre au point.

rednexage a dit:
Cette programmation ne respecte pas les règles 2 et 3 du G7, à savoir " Le franchissement d'une transition se produit lorsque la ou les étapes immédiatement précédentes sont actives et que la réceptivité associée est vraie " et " le franchissement d'une transition active la ou les étapes immédiatement à la suite et désactive la ou les étapes immédiatement précédentes ".
D'un point de vue externe si, il faut bien connaitre le cycle de l'automate pour cela. Acquisition entrées , calcul internes (c'est là qu'est le programme), mise à jour des sorties. C'est une technique peu connue.

rednexage a dit:
De plus je ne vois pas ou est fais l'initialisation de tes sfc lors d'un démarrage à froid ou à chaud de l'automate. Un autre exemple me vient en tête, ton compteur, tel que programmé il va incrémenter à chaque tour de cycle automate ou tu sera à l'étape X200. Pour éviter ceci il faut incrémenter le compteur sur un front montant de l'étape X200.
Il n'y a pas d'initialisation automatique ni à froid ni à chaud il faut le faire manuellement, ne connaissant pas l'automate j'ai choisi cette option. C'est dans" procédure de remise a zero des grafcets" que c'est fait.
A l'étape 200 il n'y a pas d'incrémentation il met la valeur 1 dans le compteur.
Par contre à l'étape 220 le compteur va décrémenter, et là c'est pareil ne connaissant pas l'automate, je ne sais pas si le phénomène de décrémentation va se produire ou bien si l'entrée compteur n'est active que sur front. Il faut faire l'essais.

rednexage a dit:
Enfin pour ton détecteur PNP, tu peux t'en servir sur ta carte, il suffit de le relayer afin d'envoyer un signal négatif à ta carte d'E/S.

C'est une autre solution avec un petit relais d'automatisme.

rednexage a dit:
Attention aussi au codeur, il se peut que les valeurs soit erronées en entrée automate, ceci sera du à la fréquence de rafraichissement des E/S. Il faudrait calculer la fréquence max des impulsion envoyées par le codeur et connaître la valeur de filtrage de tes E/S à moins d'avoir une entrée de comptage rapide (comme sur le tsx17 de télémécanique) mais je ne vois aucune borne de raccordement pour la tresse de blindage.
Cela devrait être bon compte tenu de la vitesse des vérins, on l'a déjà évoqué avec ingenieu59.

rednexage a dit:
Je pense avoir fait le tour pour ce soir.
Continues, il y a peut-être d'autres erreurs, j'étais un peu explosé quand j'ai eu fini (les yeux et le nombres de lignes)
Merci
A+
 
M

masseykubota

Compagnon
ingenieu59 a dit:
Bonjour MK,

Mais, il reste néanmoins un problème à résoudre . Pouvoir communiquer entre le PC et le terminal BEIJER E-610 . En voulant paramétrer les ports RS 232, RS 422 et RS 485, Il me marque "jumper not found" , or, en démontant la tôle de derrière, pour voir s' il y a des cavaliers, à priori , il manque une carte !!

A bientôt

Il n'y aurait pas un RJ 45 par hasard?

A+
 
R

rednexage

Compagnon
rednexage a dit:
Concernant les G7, pourquoi avoir fait un gros grafcet GPN plutôt que de l'avoir répartis en G7 de tâche avec un GCH pour piloter le tout ? Ce qui serait à mon sens plus simple à traduire en ladder, et plus digeste à programmer et à débugger. Par ailleurs une telle hiérarchie permet d'optimiser au mieux le temps de cycle.
masseykubota a dit:
Il y a un seul cycle de prévu, je suis d'accord qu'on arrive à la limite de la page... donc à la limite d'un seul (gros) grafcet.

Ce n'est pas une question de limite de page. Pour moi ce type de programmation est source d'erreur dans la retranscription en ladder. Et source d'énervement au débogage.


rednexage a dit:
Enfin la traduction en ladder est à mon sens erronée. Je pense que cette programmation nous amènera à un SFC fugace. En effet qu'est ce qui empêche l'automate de sauter toutes le étapes du SFC lors d'un même tour de cycle ? Dans ta traduction pour peut que plusieurs réceptivités successives soit vraies, tu aura plusieurs étapes simultanément actives.
masseykubota a dit:
Pas si c'est rentré dans l'ordre que j'ai donné, mais c'est effectivement très délicat à mettre au point.

La je ne suis pas d'accord avec toi ! Tu risque d'avoir de belles surprise. Pour la simple et bonne raison que tu ne tiens pas compte de l'état de tes étapes dans tes équation pour valider ou non l'étape suivante. Tu ne tiens compte que de la réceptivité associé à la transition. Ce qui fait que dans un même tour de cycle automate tu peux avoir plusieurs étapes actives. Exemple tu démarre ta bécane on est en X200. AU est à 1 tu appui sur DCY tu aura donc DCY = 1 en MIE pour 1 tour de cycle donc tu aura X210 à 1 (au passage j'ai l'impression qu'il y a un couac avec ton Au et ta divergence en Et cf. l'équation pour SET X201 différente de celle pour SET X210). Manque de pot comme l'état au tour de cycle n-1 de dcy était 0 pour l'automate tu as aussi P(DCY)=1 en MIE et de ce fait tu écrira X 211 = 1. Je ne te fais pas tout le pgm mais la c'est un exemple flagrant. Une fois arrivé à la scrutation de tes reset tu va RESET les étapes qui ont été activées inutilement, malheureusement là on ne respecte plus la règle 5 du G7 (Si, au cours du fonctionnement de l'automatisme, une même étape est en même temps désactivée et activée, elle reste active.). Encore malheureusement pour toi, l'automate, lui la respecte. Personnellement, par expérience quand je programme un SFC en Ladder je procède de la manière suivante, mon équation pour chaque étape ce compose ainsi ( etat des étapes immédiatement précédentes . équation de la réceptivité => Set état futur étape(s) immédiatement suivantes => Reset état futur étape(s) immédiatement précédentes) puis dans un page de programmation à part ou plus loin je recopie la valeur de l'état futur du sfc dans l'état réel. puis je fais une page d'affectation/assignation des E/S. Je ne pense pas que ce soit délicat à mettre au point si on a une certaine rigueur au départ.


rednexage a dit:
Cette programmation ne respecte pas les règles 2 et 3 du G7, à savoir " Le franchissement d'une transition se produit lorsque la ou les étapes immédiatement précédentes sont actives et que la réceptivité associée est vraie " et " le franchissement d'une transition active la ou les étapes immédiatement à la suite et désactive la ou les étapes immédiatement précédentes ".
masseykubota a dit:
D'un point de vue externe si, il faut bien connaitre le cycle de l'automate pour cela. Acquisition entrées , calcul internes (c'est là qu'est le programme), mise à jour des sorties. C'est une technique peu connue.

La tu confond scrutation et acquisition de E/S. Tout les API fonctionnement sur le schéma suivant SYSTEM => MIE => PGM => MIS. En ce qui concerne l'automate c'est très con il scrute chaque ligne de pgm à part de haut en bas et de gauche à droite. Attention notamment au divergences en ou en ladder dans une même ligne de code !

rednexage a dit:
De plus je ne vois pas ou est fais l'initialisation de tes sfc lors d'un démarrage à froid ou à chaud de l'automate. Un autre exemple me vient en tête, ton compteur, tel que programmé il va incrémenter à chaque tour de cycle automate ou tu sera à l'étape X200. Pour éviter ceci il faut incrémenter le compteur sur un front montant de l'étape X200.
masseykubota a dit:
Il n'y a pas d'initialisation automatique ni à froid ni à chaud il faut le faire manuellement, ne connaissant pas l'automate j'ai choisi cette option. C'est dans" procédure de remise a zero des grafcets" que c'est fait.
A l'étape 200 il n'y a pas d'incrémentation il met la valeur 1 dans le compteur.
Par contre à l'étape 220 le compteur va décrémenter, et là c'est pareil ne connaissant pas l'automate, je ne sais pas si le phénomène de décrémentation va se produire ou bien si l'entrée compteur n'est active que sur front. Il faut faire l'essais.

Autant pour moi pour X200, il faudrait savoir si notre amis compte utiliser un compteur tout fait ou travailler sur mot, mais en général le problème est le même. Il faut travailler sur front et non sur niveau, ne serais-ce que pour la propreté du programme. C'est comme les mnémoniques c'est plus agréable pour le suivant qui va tripatouiller dedans.


rednexage a dit:
Attention aussi au codeur, il se peut que les valeurs soit erronées en entrée automate, ceci sera du à la fréquence de rafraichissement des E/S. Il faudrait calculer la fréquence max des impulsion envoyées par le codeur et connaître la valeur de filtrage de tes E/S à moins d'avoir une entrée de comptage rapide (comme sur le tsx17 de télémécanique) mais je ne vois aucune borne de raccordement pour la tresse de blindage.
masseykubota a dit:
Cela devrait être bon compte tenu de la vitesse des vérins, on l'a déjà évoqué avec ingenieu59.
ingenieu59 a dit:
Je me pose également la même question pour les encodeurs .
Alors, j' ai deux solutions :
la première consiste à faire un retour en arrière, c' est à dire mécanique ( avec Fdc réglables selon la longueur souhaitée ou selon l' angle souhaité ( avec 2 Fdc presque côte à côte pour la précision )).
La seconde consiste à mettre des compteurs rapides . Par conséquent, la programmation sera revue en incluant les blocs....

On en reviens toujours au même soucis, il faudrait la doc de l'automate car impossible de passer de G7 à un SFC sans la doc. Il reste beaucoup de questions en suspends. Temps de filtrage de la carte d'entrées.
Pour répondre à ingénieu59 le problème n'est pas la programmation avec les blocs mais un problème matériel. Pour s'assurer du bon fonctionnement il faudrait connaître le temps de filtrage de ta carte, la fréquence de rotation de ton codeur et la résolution "réelle" de ce dernier.

J'espère que ma prose n'est pas trop indigeste à lire.
 
I

ingenieu59

Compagnon
Bonjour rednexage et masseykubota,

n' y connaissant rien en matière de ladder, je me fie à vos compétences afin d' y voir plus clair .
Concernant le compteur, je comptai sur le terminal pour le faire à l' aide d' un programme .

Aucun RJ45 présent sur ce type d' appareil, il y a une DB9 ( pour l' ordi ) et une DB 25 ( pour l' automate ) .

Voici la notice de l' automate :

Voir la pièce jointe Automate Mitsubishi.pdf

Pour les encodeurs, malheureusement, je n' ai aucune information . Car plus aucune référence n' est visible .

à bientôt.

PS: quelqu' un aurait-il un lien vers les compteurs ( nombre de pièces ) pour ce type d' application ?
parce que sur ebay j' en ai trouvé un mais :?:
 
B

Bbr

Compagnon
Bonjour Christophe,

Pour les codeurs tu peux déterminer la résolution minimale nécessaire d'après la précision de positionnement et le système d'entrainement mécanique. Les sorties A et B sont des sorties en quadrature qui permettent de déterminer le sens de déplacement mais aussi de multiplier par 4 le nombre d'impulsions par tour. Une fois cette estimation faite il suffit de regarder ce qui existe comme résolution standard pour des codeurs incrémentaux.
Si tu veux en savoir plus sur la partie électronique il va falloir des appareils de mesure adaptés et faire ces mesures avec les codeurs raccordés sur le multitron... :spamafote:

Pourquoi veux tu utiliser un compteur pour compter le nombre de pièce ?
Sur le schéma en allemand il y a 4 entrées utilisées pour coder le nombre de pièces à faire (0 à 9 avec un codage BCD) c'est à dire le nombre de cycle que doit faire la machine et vu la cadence je pense que l'automate est capable de compter ça (contrairement aux impulsions des codeurs).
D'ailleurs au lieu d'utiliser une 5 è entrée pour le mode manuel ils auraient pu utiliser les 4 entrées de façon plus subtile : nombre de pièces de 0 à 15 avec :
  • 0 = coupe continue sans comptage (arrêt quand il n'y a plus de matière).
  • 1 = une pièce, c'est aussi le mode manuel.
  • 2 à 15 comptage de pièces (sachant qu'il est difficile de couper 15 pièce de 500 dans une barre de 6 m par exemple).

Cordialement,
Bertrand
 
R

rednexage

Compagnon
Salut Bbr et ingenieu59,

ingenieu59 : merci pour la doc.

Bbr : le codeur n'a rien à voir avec le nombre de pièces à réaliser (tout au plus avec la longueur de ces pièces mais je n'ai pas étudié plus en détail le fonctionnement de cette machine). Effectivement on peut connaître la résolution du codeur en tournant très lentement (faire 1 tour) et incrémenter un compteur sur chaque front montant (ou descendant) sur la voie A ou B ou les deux pour comparer. L'automate pourra gérer le codeur du moment que fmax codeur < f filtrage carte. Le temps de réponse d'après la doc de l'automate est de 10 ms on partira donc sur cette valeur pour déterminer f filtrage carte. Soit f filtrage carte = 100 Hz.

Concernant le comptage du nombre de pièces je crois que notre amis souhaite utiliser un IHM. Mais il est tout à fait possible d'utiliser une roue codeuse sur 4 bits (si on considère un maxi de 15 pièces.

Si on souhaite couper une pièce, ce n'est pas forcement un mode manuel, à mon sens un mode manuel est de pouvoir utiliser chaque actionneur à part quand on le souhaite.
 
I

ingenieu59

Compagnon
Bonsoir,

Pour les encodeurs, j' avoue que c' est pas évident quand on ne connait rien sur eux à part que ce sont des HOHNER
absolu ( je pense ) et vieux ( c' est sûr ) . Relatif au matériel !!

Pour le compteur de pièces NPN, c' est dans la perspective de faire de petites pièces , et , si la solution du HMI est un échec .
Mais sur ebay, je ne comprends pas son appareil . Sur les photos de gauche on est en 22 V cc et sur les photos de droite, on est en 220 Vac .
Si le mitsu peut gérer sans problème, ce n' est que mieux .

Par contre, s' il fallait faire des mesures pour les encodeurs, il faudra me dire comment?
Je sais simplement que pour les angles, 1 tour équivalait à 200 ° sur le multitron avec une précision d' 1/10 ème de degré .
Ensuite, pour avoir la même correspondance avec le vernier, il a fallu faire des poulies avec un rapport multiplicateur ( 1 tour de pivot pour 3 à 4 tours d' encodeur , et usinée de 1/10 ème à la fois pour obtenir l' équivalence parfaite ) .

A bientôt
 
R

rednexage

Compagnon
Pour connaître le nombre de point du codeur, sans référence. Il faut compter le nombre (au moyen de l'automate) de front montant (par exemple) de la voie A (toujours par exemple) sur un tour de codeur. Il faut donc le faire tourner d'un tour (très lentement afin d'éviter de faire sauter le chien de garde si fcapteur > f filtrage).

Ton codeur (au vu de son câblage) est un codeur incrémental et non un codeur absolu ! S'il était absolu il ne pourrait indiquer que 2 bits ^2 soit 4 positions. Bonjour la précision !!!
 
B

Bbr

Compagnon
Bonsoir,

rednexage a dit:
Bbr : le codeur n'a rien à voir avec le nombre de pièces à réaliser (tout au plus avec la longueur de ces pièces mais je n'ai pas étudié plus en détail le fonctionnement de cette machine). Effectivement on peut connaître la résolution du codeur en tournant très lentement (faire 1 tour) et incrémenter un compteur sur chaque front montant (ou descendant) sur la voie A ou B ou les deux pour comparer. L'automate pourra gérer le codeur du moment que fmax codeur < f filtrage carte. Le temps de réponse d'après la doc de l'automate est de 10 ms on partira donc sur cette valeur pour déterminer f filtrage carte. Soit f filtrage carte = 100 Hz.

Je ne confonds pas les codeurs qui servent à mesurer les longueurs et les angles de coupe avec le nombre de pièces à couper. Ce que j'ai dit et je le répète car visiblement ça n'a pas été compris, c'est que l'automate n'est pas conçu pour traiter les infos des codeurs et encore moins pour comparer une consigne avec la valeur mesurée. Cette fonction est assurée par le multitron qui est une CN (ancienne certes, spécifique surement).

Pour résumer, d'après ce que j'ai compris du fonctionnement de cette scie, c'est que le multitron gère les codeurs et envoie des info TOR vers l'automate pour qu'il active les bons vérins dans le bon sens jusqu'à ce que le multitron obtienne une égalité entre la consigne et la mesure (pour la longueur et pour l'angle). L'automate quand à lui ne gère que des fonctions TOR (Tout Ou Rien) et probablement le comptage de pièce. :wink:

Ceci dit vous pouvez imaginer d'utiliser l'automate pour gérer le positionnement grâce aux codeurs mais ça n'est pas gagné et en plus il va falloir trouver une solution pour rentrer les longueurs et les angles... :roll:

Cordialement,
Bertrand
 
M

masseykubota

Compagnon
Bonjour,

Les vérins hydrauliques ont des déplacements lents : ça va peut-être passer!

A+
 
R

rednexage

Compagnon
Salut

Ce que je dos depuis le début l' automate peut tout à fait gérer un ou plusieurs codeurs à la condition express de vérifier les fréquences de commutation. Je ne dis rien de plus. Pour gérer un codeur par un automate il faut tout au plus quelques mots afin de déterminer la position réelle du mobile. Une fois la position du mobile déterminée on la compare à la consigne.

Au vu du câblage je ne vois pas commun le multitron enverrai des info tor a l' api.

Pour indiquer les angles et longueurs de pièces a l' api notre ami ingenieu59 souhaite utiliser un ihm. Reste a faire communiquer l' ihm et l' api ce qui ne semble pas gagné.
 
I

ingenieu59

Compagnon
Bonjour,

euh!!!!
désolé, c' est peut-être moi qui ai mal compris !!

le module de comptage, c' est un ajout à l' automate pour les encodeurs .

Un compteur, c' est un compteur à chiffres mécaniques ou digitaux ( visibles ) pour savoir où on en est des coupes . Etant relié à l' automate ( version NPN ) , celui-ci peut faire le décompte , comme cela, une fois arrivé au bon nombre, il peut s' arrêter .

Il existe plusieurs systèmes :

automate + compteur mécanique NPN
automate + multitron ( CN )
automate + HMI ( terminal graphique )

et moi, j' aurai, si tout va bien : automate + multitron + HMI beijer

A bientôt.

PS: LE MULTITRON DOIT ETRE CONSIDERE COMME HS car il ne donne plus d' infos sauf les visus
 
R

rednexage

Compagnon
Salut,

Quand je parle de compteur je parle de compteur interne à l'automate. Je ne vois pas l'intérêt de conserver le multitron si tu as un API et un IHM.

Par ailleurs que veux tu dire par un compteur NPN ?
 
I

ingenieu59

Compagnon
Re,

Le multitron, je le garde pour les visus en mode manuel . Si j' avais eu une visu plus petite, je l' aurai mise à la place .
En mode manuel, l' automate est éteint . Les encodeurs sont branchés en parallèle avec le multitron et l' automate . ( voir branchement N° 3 ) . C' est à dire qu' ils vont donner les infos respectivement dans le multitron et le mitsu .

Donc, s' il y a un problème sur les angles ou sur la longueur, il y a moyen d' arrêter la machine avant de devoir tout jeter à la poubelle ( les pièces coupées ) .

Concernant le compteur NPN ou PNP, j' ai vu ça sur un sîte de vente sur le net . C' est encore sur des vieilles machines, en cycle automatique , une fois le nombre de pièces atteintes, le compteur envoie l' info à l' automate pour lui signaler qu' il a atteint le nombre de pièces . Même branchement qu' un capteur inductif PNP ou NPN.
je ne peux pas mettre de lien, je ne sais pas comment faire .

A bientôt.
 
R

rednexage

Compagnon
J'avais oublié que tu souhaite conserver deux types de commandes.

Simplement on aurait pu mettre sur l'afficheur les valeurs d'angle réels et les longueurs de pièces. Envoyer les impulsions au multitron et à l'automate ce n'est pas ce qu'il y a de plus propre (attention je ne dis pas que cela ne marchera pas)

Concernant ton compteur je vois de quoi tu veux parler, une antiquité ! C'est le genre de chose qu'on utilise en logique câblée afin de s'affranchir d'un API. Le but d'un API est justement de limiter tout ces artifices, temporisation, compteur et autres régulateurs.

Blague à part j'espère ne pas être trop long dans ma prose.
 
I

ingenieu59

Compagnon
Re,

on est bien d' accord, c' est une antiquité!!! :-D

Le débat d' idées est lancé, vu qu' il n' y a pas de sujets sur la question .

Pour la prose, ça va, c' est plaisant à lire.
 
I

ingenieu59

Compagnon
Bonjour tout le monde !

hier, j' ai eu des échanges avec un réparateur qui m' a donné la démarche à suivre pour communiquer entre l' ordinateur et le terminal .
Et, ça marche!!!!
Ce que l' ancien proprio n' était pas capable de faire .

Je crois que la liaison est rétablie!!

Voyez plutôt :

DSC02786.JPG


"allo houston , ici la lune, me recevez-vous !!!"

"allo houston , ici la lune, me recevez-vous !!!"
 
M

masseykubota

Compagnon
ça progresse... ça progresse..

Notes bien comment tu as fait... Dans 15 jours ce sera déjà peut-être oublié!

A+
 
R

rednexage

Compagnon
Salut,

En voila une bonne nouvelle. Il ne reste plus qu'à faire communiquer l' api et l' ihm. Aurai tu la doc de ton ihm ??
 
R

rednexage

Compagnon
ingenieu59 a dit:
Bonjour rednexage,

L' API et l' HMI communiquent entre-eux sans problème, mais ils réclament leur programme respectif.


A bientôt.

Cela va de soi :wink:.
 
Haut