PAP vs SERVO

[el patenteu]

Ce post fait suite a une discussion entammé ailleur,alors poursuivont la ou ont en était......

Stan lorsque tu dis,le logiciel envoi un message d'erreur et la machine tombe aussitot a l'arret des que les tolérances en déplacement sont dépassées,alors ca veut dire
que tu perd quand meme la référence zero(point de départ) ou non?
Ce bout la me chicotte beaucoup et j'aimerais bien comprendre......
La machinne est face un obstacle,elle.....
- ''essai un certain temps'',puis s'arrete des que le temps d'essai est dépasser (j'en doute)
- Envoie du courant jusqu'a ce que la tension maximale soit atteinte et coupe (fort probable)
-Autre....

-Quels sont les avantages d'un servo vs un PAP avec encodeur??
-Un PaP avec encodeur comment fonctionne-t-il puisqu'il ne gere pas la tension en fonction de l'effort??....qu'est-ce qu'il l'arrete en cas de collision??

Merci de m'éclaircir!!
Fred

 

[stanloc]

Bonjour,
Fred, il faudrait que tu passes des généralités aux cas concrets car je ne peux te faire un cours sur les servomoteurs dont je suis par ailleurs totalement incapable.
A une question précise je vois si je peux répondre en fonction de ce que je sais.
Niveau établissements des besoins en matière de motorisation d'une cnc, c'est un problème à traiter dans son entier. Moi je suis pragmatique ; nous touchons là à un domaine de spécialistes et quelques questions/réponses sur un forum n'apporte pas la Connaissance. Donc dans ma façon de faire je privilégie à la construction le choix de produits au niveau guidages linéaires et vis à billes aussi performants que possible en fonction de ce que je peux payer et de cette façon j'ai des chances que mes moteurs pourront être de taille et de prix acceptable. Ensuite niveau performances je vois ce que la machine peut faire car je ne sais pas partir de données précises et faire les calculs nécessaires pour déterminer la taille des moteurs. Je suis un amateur et je me moque d'obtenir telle ou telle vitesse de déplacement sans usinage surtout que les parcours sont généralement petits et je doute que les vitesses entrées dans Mach3 soient jamais atteintes.
Je ne vois pas comment la machine puisse être face à un obstacle sauf si la fraise attaque l'étau auquel cas la pièce est probablement hors côte donc poubelle. En tout cas il faut reprendre la programmation de la pièce car il y a un bug et peut-être pourra t-on se recaler pour continuer l'usinage.
Je te répète, Fred, je ne peux te donner un avis sur ce que fera la machine en cas de mise en PANNE par le logiciel. Neuf fois sur dix c'est qu'on a été trop gourmand et qu'il faut modifier la config et donc on repart du début.
Dans l'industrie on utilise de la matière en bloc, une sorte de cire, pour usiner un proto avant de passer à l'usinage de la matière finale. Tant que la machine n'a pas montré en réel sur un usinage réel que tout se passe bien il y a un doute.
Les performances d'un servomoteur sont très supérieures à celles d'un PàP sur le plan accélération grâce à son couple instantané.
Stan

 

[OrOoX]

Pour faire un complément aux questions posées par El Patenteu d'après moi.

Stan lorsque tu dis,le logiciel envoi un message d'erreur et la machine tombe aussitot a l'arret des que les tolérances en déplacement sont dépassées,alors ca veut dire
que tu perd quand meme la référence zero(point de départ) ou non?

Il y a trois cas possibles qui change du tout au tout.

Dans le premier, on a un système stand-alone comme nos drivers que nous connaissons tous qui reçoivent des signaux DIR et STEP et qui agissent
en fonction de ceux-ci, il n'y a donc aucun retour d'information sur la position "prévue" à l'ordinateur. Le bas de gamme quoi.

Dans le second, toujours le même système stand-alone mais cette fois équipé d'un codeur qui renvoie des informations au driver, on entre dans le milieu
de gamme, le driver peut être configurable à l'aide de Jumper ou par interface dans le quel on peut définir un nombre d'erreur avant de couper le système.

Dans le troisième cas, on tape dans le haut de gamme avec du système industriel, on a un moteur équipé d'un codeur qui renvoie les informations à un Driver
qui possède un nombre important de réglage ET qui permet d'envoyer les informations de position à l'ordinateur et donc d'afficher des valeurs réel sur le DRO
et non des valeurs virtuels, dans ce cas le logiciel de pilotage va continuer de tenter d'atteindre les cordonnées jusqu'à la mise en sécurité du Driver.


Concernant la détection du problème, cela doit aussi bien utiliser une échelle de temps pour mesurer la distance parcourus par rapport à celle que cela aurait du
parcourir et donc utiliser les positions angulaires aussi.



Les avantages des PaP par rapport au servo ( brushless dans les deux cas ) ... Comment dire :

- Couple constant jusqu'à la vitesse recommandée ( 3000tr/min en moyenne )
- Accélération monstrueuse
- Absence des vibrations due aux "crans" des PaP

Et j'en passe

Un petit inconvénient à la con quand même, le sifflement due aux fréquences ...

 

[el patenteu]

J'aime bien les accélérations monstrueuses!!

Voulais tu plutot dire avantage des SERVOS VS PAP (tu as écris l'inverse)
Car les PAP n'atteigne pas 3000rpm et n'ont pas un couple constant,par contre ils sifflent eux aussi entres 2 pas.

Ouais en tant qu'obstacle Stan et bien n'importe quoi qui ferait en sorte que la machinne est dans l'incapacité de pouvoir se déplacer,bride comme tu le mentionnais,
passes trop profondes ,objet venant se coincé dans une crémaillere bref, dieu sait combien il peut y en avoir....
Car meme si il faut retourner a la programation la piece n'est pas fichu pour autant du moment qu'ont a pas perdu le point zero des 3 axes.

Ma question portait sur un pap équiper d'un encodeur Vs un vrai servo.
Mais rendu la je me demmande alors pourquoi voudrait-ont avoir un retour sur l'axe de rotation du moteur??
Si ont veut etre dans l'absolu alors pourquoi ne pas monter des regle numeriques sur le axes ?
Ont suppose un cas....
En plein usinnage un coupleur de vab se dessere,alors tout renvoi d'info devient inutil le dro compte des mesonges et bref la piece est foutu quand meme.
Je trouve un peu ''simplet'' de se fier sur un renvoi d'info appartir de l'axe du moteur,le moteur ne dira rien de plus que sa position a LUI et aucunnement
assurer que la MACHINNE est bel et bien rendu LA.
Un renvoi d'info appartir du moteur ne gerera aucunnement le jeu(backlash) alors que si l'info se fait appartir de la machinne (le long des rails)
meme avec un certain jeu dans les transmission ont s'en fou la machinne se ''corrige'' au fur et a mesure.
Probablement qu'il y a un certain tremps c'était hors de porté mais aujourd'hui ca doit etre moin lourd en mettre en oeuvre pour un amateur.

Au plaisir d'échanger....

Fred

 

[OrOoX]

En effet j'ai inversé ^^

Par contre quand je parle de sifflement sur les servos, c'est bien au dela des PaP ...

Car meme si il faut retourner a la programation la piece n'est pas fichu pour autant du moment qu'ont a pas perdu le point zero des 3 axes.

Je pense que tu diras pas la même chose si ta broche est aller tout droit au lieu d'aller à droite


En attendant tu a raison pour ton hypothèse, ça ne peut en effet pas couvrir ce genre d'avarie sauf en cas d'entrainement direct pour un axe rotatif.

Après l'idée des règles est bonne mais au final on rencontre de nouveaux problèmes, déjà il faut que les règles soient protégés des poussières et autres
et surtout si tu as un coupleur qui casse, ton moteur continuera à tourner, si tu as deux axes en mouvement, cela risque tout de même de massacrer la pièce.

La solution parfaite n'existe pas malheureusement

 

[stanloc]

Fred, dans la conception d'une CNC on a le point de départ avec les moteurs pas à pas. Beaucoup de gens s'en sont contentés d'autant mieux qu'ils n'ont pas trimé pour arriver à leurs fins. Ensuite tout est possible en théorie pour aller jusqu'au centre d'usinage utilisé dans l'industrie mais encore faut-il avoir et la compétence pour en faire un et l'argent pour le payer.
Si ta fraise est allée usiner une bride et que la machine a calé il y a une forte probabilité pour qu'elle ait perdu son origine machine et qu'il faut commencer par refaire l'OM pour reprendre ensuite l'usinage.
Stan

 

[el patenteu]

Je comprend de mieu en mieu les originnes vs les fin de courses.
Les fin de course ne sont que des coupeur de courant une fois la limite atteinte.
Alors que les origines sont la pour ''setter'' les limittes de la machinne,et ainsi une fois qu'elle touche a l'une extrémité et a l'autre peut se refaire un zero
précisement,ce qui n'est pas le cas si ont seulement une originne piece,comme je travail présentement.
De plus si ont entre un g-code dont les données dépasse les limiittes de la machinne automatiquement mach3 doit tomber en alerte et refuser meme de démarrer le programme.
Ca donc plusieurs avantages.
Alors maintenant a quoi servent les fin de course??
Si la machinne le sait qu'elle n'as pas d'affaire a aller plus loin que........?
Ce sont les meme sensor qui servent au ''homing'' et au fin de courses ou ce sont 2 systemes complet et indépendants?
Je pose ces questions car sur ma petite machinne il ny en a pas et c'est pas dramatique puisque ce sont de petits nema 23 en accouplement direct sur crémailleres.
Mais dans le cas d'une transmission par vab au pas de 2mm avec réduction et un nema 34 qui pousse alors la ca peut devenir problématique.

@+
Fred

 

[stanloc]

Bonjour,
Il y a deux situations bien distinctes, dans la vie : la première c'est quand tout va bien et la seconde c'est quand un grain de sable entre pour détruire le bon ordonnancement. Les fins de courses c'est pour la deuxième situation.
La qualité première d'un fin de course doit être sa fiabilité. La qualité première d'un contact de zéro machine c'est sa précision et sa répétabilité.
Stan

 

[OrOoX]

Alors maintenant a quoi servent les fin de course??
Si la machinne le sait qu'elle n'as pas d'affaire a aller plus loin que........?

Même si tu défini des limites logiciels comme il est possible de faire dans Mach3, le risque zéro n'existe pas.

Imagine que pour une certaine raison l'ordinateur envoi plus de pulsations qu'il devrait, cela va donc allonger la distance parcourus,
que va faire ta limite logiciel qui ne connais pas la valeur réel de déplacement ? Bah rien ... Et si pas de FDC, bah risque de casse