InterpCNC en mieux, ca vous dirait ?

[Otatiaro]

Salut à tous,

Bon le remontage de ma machine arrive a grand pas, et toujours dans l'optique de faire mieux, une des plus grosses limitations que je vais avoir vient de la vitesse du noyau de Mach3.

En effet, mes futurs drivers acceptent 400KHz là ou Mach 3 peut sortir dans le meilleur des cas 10 fois moins (et encore ... c'est purement théorique).

La seule facon de briser cette limite est de déporter la gestion temps réel dans une carte éléctronique exterieure au PC.

Après quelques recherches, InterpCNC semble interessant, mais quelque peu limité par rapport a ce qui se fait maintenant.

Et pis comme le but c'est quand même de s'amuser, pourquoi ne pas concevoir et fabriquer sa propre carte !

Donc voilà je voulais savoir si ca pouvait interesser certains d'entre vous un projet comme ca, autant en tant qu'utilisateur qu'en tant que développeur / concepteur / programmeur / electronicien / etc ...

Parce que tout seul je pense qu'on sera tous morts et enterrés avant que j'ai fini

Faites moi savoir !

++

 

[Otatiaro]

Post réservé pour les specs fonctionnelles

Post réservé pour les specs fonctionnelles

Première ébauche des fonctions attendues :

-> 4 ou 5 axes
-> 20 ou 30KHz réel en interpolation linéaire
-> au moins 10KHz en interpolation linéaire / hélicoïdale
-> connection sur port USB 2.0
-> pour chaque axe, gestion des deux inters de limite, d'un inter de homing, d'un interrupteur d'erreur
-> gestion d'au moins 3 inters sur relay (pourquoi pas 8)
-> gestion d'un e-stop
-> possibilité de mettre a jour le firmware par le PC
-> une PWM de sortie de puissance
-> quelques GPIO
-> pourquoi ne pas reprendre le protocole déjà existant pour InterpCNC, ca permettrait d'être compatible avec les applications qui le gèrent déjà
-> etc ...

 

[Otatiaro]

Post réservé pour les specs techniques

Post réservé pour les specs techniques

 

[Otatiaro]

Post réservé pour les effectifs

Post réservé pour les effectifs

 

[armaris]

Pour info, j'ai développé un contrôleur 16 axes sur Ethernet - 4 mois de boulot à 3.

Parmis les options que l'on avait envisagé :
- DSP
- FPGA
- circuit spécialisé (solution retenue)

en FPGA, voir OpenCore et carte Mesa Electronic (ils ont un code gratuit sur leur site pour un contrôleur servo ou PaP avec retour codeur)

en CI spécialisé, nous avons choisis NPM (Nippon Pulse Motor), le 6045 gère 4 axes à 20 MHz sur des registres de 24 bit. il gère toutes les interpolations, S-curve, jerk, etc,... environ 100$ pièce.
Ce circuit est disponible en carte PCI avec driver Linux(en source)/Windows à environ 600€ chez ADLINK.
Regarde aussi du coté de chez Trinamic (allemand), le TMC428 + TMC239/246 est très sympa et pas cher.

Au final nous avions une solution µC 32 bit (ARM7/9) sous µC-linux qui gèrait la partie réseau + synchro réseau 1588 + 4x6045 pour les 16 axes.

 

[vres]

Pour info, j'ai développé un contrôleur 16 axes sur Ethernet - 4 mois de boulot à 3.

Parmis les options que l'on avait envisagé :
- DSP
- FPGA
- circuit spécialisé (solution retenue)

en FPGA, voir OpenCore et carte Mesa Electronic (ils ont un code gratuit sur leur site pour un contrôleur servo ou PaP avec retour codeur)

en CI spécialisé, nous avons choisis NPM (Nippon Pulse Motor), le 6045 gère 4 axes à 20 MHz sur des registres de 24 bit. il gère toutes les interpolations, S-curve, jerk, etc,... environ 100$ pièce.
Ce circuit est disponible en carte PCI avec driver Linux(en source)/Windows à environ 600€ chez ADLINK.
Regarde aussi du coté de chez Trinamic (allemand), le TMC428 + TMC239/246 est très sympa et pas cher.

Au final nous avions une solution µC 32 bit (ARM7/9) sous µC-linux qui gèrait la partie réseau + synchro réseau 1588 + 4x6045 pour les 16 axes.

Bonsoir à tous
Si je comprend bien le 6045 c'est comme Marie, c'est pas parque c'est déja fait qu'il ne faut rien faire.
Christian

 

[MaX-MoD]

ça c'est un projet intéressant

Je voulais aussi faire ma propre carte USB d'interpolation, mais après une rapide évaluation j'ai abandonné, ça m'aurait pris trop de temps tout seul.

Ma dernière idée était d'utiliser un PIC genre 18F4550 qui ne s'occuperait que d'émettre des impulsions, tandis qu'EMC (via une sorte de 'driver' ou je ne sais plus comment ils appellent ça) enverrait le flux des impulsion à la carte.

mon pifomètre me dit qu'avec cette solution, 100KHz ou plus est facilement envisageable, et le développement rapide.

Même principe avec un dsPIC et un chip ethernet, encore plus rapide (1MHz+)


J'ai vu plusieurs autres projets de genre sur cnczone, à base de FPGA généralement, c'est quant même complexe...

Il y a aussi d'autres solutions, comme les cartes à linux embarqué, on en trouve, si je me souviens bien, à 300MHz (600MHz?) pour moins de 100€

Si je comprend bien le 6045 c'est comme Marie, c'est pas parque c'est déja fait qu'il ne faut rien faire.

Bonne soirée
Max

 

[armaris]

Tout dépend de ce que l'on cherche (gain de temps/argent ou se faire plaisir en développant soit même).

Si besoin, j'ai un max de docs sur les différents CI contrôleurs (AMIS, Mesanet, ASM, Nova, NPM, trinamic, PMD, Toshiba) environ 117 Mo, je devrais pouvoir mettre ça sur un FTP.

Cela faisait parti du boulot de faire une petite étude de marché.

Je crois que Gecko fait le G-REX OEM autour de 150$

 

[Otatiaro]

Salut,

C'est sur qu'en passant par un FPGA et encore plus par un chip spécialisé, ca va beaucoup plus vite et les perfs sont largement au dessus.

Mais déjà mes drivers ne gereront pas au dessus de 400kHz, et en plus faut voir ce qu'il y a comme logiciel de contrôle derrière (et a quel prix ... j'ai déjà laché une license Mach3 ...).

Pour le gecko, j'ai l'impression que le gros probleme c'est que pour le moment c'est pas vraiment terminé, et que peu de logiciels le supportent. Mais sinon c'est vrai que sur le papier c'est pas mal interessant.

Si le G-Rex était 100% supporté par Mach3, j'aurais même pas envie de me donner du mal a développer autre chose

@Max-Mod : j'aurais plutôt pris un dsPIC33 bien bourrin, un chip pour la conversion USB -> RS232, et une partie logicielle en C# (on se refait pas) sur windows (bah y'a mono ...) pour gérer tout ca.

Avec un PIC a 40 MIPS ... en gardant une centaine d'instructions par cycle, ca permet d'attendre les 400KHz tant espérés ... avec un 18F ca me parait plus compliqué (et pis niveau dev, m'en fous, j'ai un ICD2 et tout le bordel ...).

Le côté marrant c'est de développer le protocole, et l'interpolation elle-même (y'a des algo proprement hallucinants de simplification pour les interpolations linéaires et circulaires).

Mais bon comme toi, pas énormément de temps pour m'en occuper, et trop de boulot pour une seule personne.

Sinon prendre une carte sur base x86 avec Linux, ca me parait un peu ... bourrin ... et ne résoud pas le probleme de l'acces aux IO en temps réel (enfin c'est chiant a faire RTLinux).

Peut-etre une gumsticks, mais je suis pas sponsorisé par eux (merci microchip enfin ca sert d'avoir été pres du club robotique de supelec).

Je ne savais pas qu'il y avait des chips spécialisés, faut que j'aille voir ca ... si ces chips gèrent déjà l'interpolation avec de bonnes caracs, il ne reste plus qu'a faire la couche de comm et le logiciel PC (une intégration a Mach3 serait terrible, mais je doute que ce soit facilement réalisable, et de toute facon, j'ai déjà des p'tites idées sur la facon de manipuler le G-Code pour en extraire le meilleur, des choses comme ca.).

A 100$ pièce, si on en achete 4 ou 5, ca permettrais de faire un truc sympa dans les 180€ fini, avec des perfs bien au déjà d'un G-Rex ou assimilé.

Sinon y'a pas un 6045 mais qui ne monte pas a 20MHz, moins cher ? encore uen fois pour moi l'objectif c'est 400KHz (et je pense pour pas mal de monde, j'ai cru comprendre que mes futurs drivers étaient plutôt répendus ...).

Par contre Max, je vois pas l'interet de l'ethernet par rapport a l'USB ... en USB tu as des chips qui t'émulent un port com a pas loin de 10Mbps, et les chip ethernet 100 base T sont plutôt rares (l'enc de microchip est un 10 base T, et leur futur 100 base T n'est pas prévu avant quelques mois de ce que je sais ...).

Fin bon y'a plusieurs solutions, faut choisir la bonne !

++

 

[Otatiaro]

http://nipponpulse.com/Default.aspx?Tab ... 2&langID=0

Bon bah y'a plus qu'a ...

@armaris : toute info sur ces chips est plus que bienvenue, ainsi que toute info sur la carte que tu as développée (y'a toujours de bonnes idées a reprendre ).

++

 

[MaX-MoD]

c'est carrément abordable ce chip.
(les quelques chips du genre que j'avais trouvés étaient à 50$/1000 pour 1 axe...)

mais en survolant la datasheet il semble que ça ne sorte que des phases pour un pap...

pour ce que j'imaginais comme interface simplifiée (signaux bruts, grande bande passante requise), soit un 18F qui permet ~1Mbps soit un 33F (évidemment ) avec une interface Eth (10Mbps c'est plus que suffisant^^) pas forcément plus compliqué au final qu'un chip USB/RS232 (dont la vitesse est bien plus limité si mes souvenirs sont bons)

Mais c'est sur qu'un câble Eth d' 1/2m ça fait un peu ridicule
l'USB est plus pratique: mois de composants, plus robuste, alim +5V dispo... mais y'a pas intérêt à devoir développer un driver perso
Pour y avoir gouté (enfin, entre aperçus) je le déconseille vivement

Alors qu'en Eth, la communication est bien plus simple.
Si tu as l'interpolateur sur le PIC, tu peux même ouvrir http://192.168.0.x sur ton explorateur internet, tu balances ton G-code dans une boite de texte et c'est parti.

Mais de l'interpolation sur un 18F^^
400KHz on oublie.

Perso je serais plutôt du genre à mettre EMC sur un PC d'occas ou sur une carte mère micro ITX avec pross embarqué.
Mais ce n'est pas le sujet

Max

 

[vres]

Bonjour
Au dela de 5000 pas/tour le micropas n'apporte plus grand chose.
Avec une vitesse de 1500tr/mn (c'est déja bien pour un PàP) ça donne 120kHz. il ne faut pas croire qu'avec 400kHz a 2000pas/rev le moteur va tourner à 12000tr/mn. La fréquence d'interpolation oui c'est bien, mais le plus important c'est La cinématique en amont. Pour info une fréquence de 40Khz avec une vis de 5mm c'est:
- Vitesse de 100mm/s
- 2000 pas/rev (1/10 de pas)
- 400 pas/mm.
Moi je trouve cela déja pas mal.
Le micropas n'améliore pas la précision mécanique, je pense même qu'il augmente l'hystérésis.

Christian

 

[Otatiaro]

Raaaahhh cette foutue conversion minutes / secondes ...

Bon ben dans mes besoins, j'ai un facteur 60 qui saute.

Au final, en prenant un micropas 16, ca me fait 200*16 = 3200 step / rev et avec une vis a bille de 5mm de pas ca fait 640 step / mm.

En tablant sur une vitesse de 50mm/s (extrapolation selon mes perfs actuels et le gain espéré en changeant les drivers et l'alim), ca fait 32KHz.

Bref avec Mach3 et son noyau a 40KHz, la boucle est bouclée.



Par contre si je passe en micropas 128, soit 25600 step / rev, pour atteindre les mêmes perfs, il faut pouvoir sortir 256KHz. Mais effectivement si le micropas n'apporte plus rien au delà de 5000 step / rev, l'interet est plutôt limité :(

Aux utilisateurs de EMC, quelle est la fréquence max de sortie ?

++

@Max : effectivement après survol de la datasheet, je ne vois aps de sortie step / dir sur le chip ... peut-etre pas le bon modèle alors

 

[vres]

Raaaahhh cette foutue conversion minutes / secondes ...


Au final, en prenant un micropas 16, ca me fait 200*16 = 3200 step / rev et avec une vis a bille de 5mm de pas ca fait 640 step / mm.

En tablant sur une vitesse de 50mm/s (extrapolation selon mes perfs actuels et le gain espéré en changeant les drivers et l'alim), ca fait 32KHz.

Bref avec Mach3 et son noyau a 40KHz, la boucle est bouclée.

Déja avec cette résolution la douceur du PàP est un pur régal.
Christian

 

[Otatiaro]

Raaaahhh cette foutue conversion minutes / secondes ...


Au final, en prenant un micropas 16, ca me fait 200*16 = 3200 step / rev et avec une vis a bille de 5mm de pas ca fait 640 step / mm.

En tablant sur une vitesse de 50mm/s (extrapolation selon mes perfs actuels et le gain espéré en changeant les drivers et l'alim), ca fait 32KHz.

Bref avec Mach3 et son noyau a 40KHz, la boucle est bouclée.

Déja avec cette résolution la douceur du PàP est un pur régal.
Christian

Bah de toute facon la carte d'interpolation, c'est pas pour tout de suite, d'abord remonter la machine, mettre le nouveau stepper, les nouveaux drivers, les nouvelles alims, la nouvelle broche, les vis a billes, etc etc ...

Bref c'est pas plus mal que ca tourne bien même sans

@armaris : un G-Rex pour 150$, c'est carrément interessant ! En plus le G-Rex fonctionne avec Mach3. Mais bon j'ai vu un post de FAQ sur le G-Rex, et ils préconisent de ne l'utiliser que dans quelques cas précis (très haute vitesse, pas de port //, plus de 4 axes, etc ...), m'enfin a 150$ ca peut faire un p'tit truc sympa en plus

++

 

[MaX-MoD]

G-REX @ 150$, en OEM?
Allez, commande groupée les gars! Otatiario et moi sommes intéressés, plus que 9998 personnes à trouver

Au fait, un bon driver de pap passe en mode plein pas ou demi pas à partir d'une certaine vitesse pour garder plus de couple.

Et quant à l'hystérésis sur un pas, il est faible et je crois qu'il n'augmente pas en micropas, par contre entre deux 1/2 pas le couple est plus faible.
Il faut ajouter à cela que le comportement d'un pax à pas en micropas n'est pas linéaire (j'essayerai de retrouver les courbes angle magnétique-position que j'avais vu chez un constructeur) et on ne peut vraiment plus considérer le micropas comme une réelle amélioration de la précision.
Du moment que ça ne vibre pas, c'est bon

Max

 

[armaris]

Comme le précise CNCSERV, le micropas c'est à consommer avec modération, ça ne résout pas tout.
Il y a un bon article de Geckodrive sur leur driver, à très basse vitesse, il fonctionne en micropas et en haute vitesse en pas complet.
Voir aussi trinamic, pour le TMC428 ils utilisent une carte de correction des µpas, ce qui permet d'améliorer la linéarité. J'avais été assez surpris de l'efficacité de cette approche (réduction de l'erreur par 3, c'est pas mal), j'ai testé mais finalement pas retenu.

MaxMOD à bien résumé l'avantage d'Ethernet (driver facile, etc...).
Je rajouterais que la transmission est différentielle en paires torsadées, donc c'est excellent en milieu bruité et en cadeau on a une isolation galvanique.
En plus quand on doit synchroniser des système entre-eux, le protocole 1588 permet de descendre à la µs, ce qui permet des systèmes temps-réel distribués ou évolutifs (si tu as une carte 4 axes et que tu veux un 5° axe, tu rajoutes un carte sur le switch et tout est automatiquement synchro - même référence de temps à la µs près, fini les codes IRIG etc...).

Pour le G-REX OEM, la doc a disparu du site (il l'appelait G101), j'ai joint ce que j'avais téléchargé à l'époque.
Perso, je suis pas chaud pour le G-REX (driver fermé et pas au point).

Si j'avais à développer une carte, je prendrais une système avec un OS, on gagne du temps et plutôt une base PC sous linux/EMC2, en rapport performance/prix/souplesse il y a pas mieux.
Les PIC c'est bien mais la mise au point est longue et quand on travaille au niveau cycle, l'édifice devient branlant dès que l'on rajoute on fonctionnalité pas prévue au départ.
Un PC, c'est quelques GFlops sous la main pour 150€.

Je vais vous communiquer toutes les infos sur la carte (la boite pour laquelle je travaillais m'a viré comme un malpropre et comme je n'ai pas de clause de confidentialité, tous ce qui est dans ma tête m'appartiens).
Par contre pas de documents ni de code.

 

[Otatiaro]

Salut,

Merci armaris pour tes conseils et informations !

Juste pour le plaisir de raler, un PC avec quelques GFlops pour 150€, c'est encore un peu tôt ... quelques centainres de MFlops je dis pas, mais pas plusieurs GFlops pour ce prix

Faire une carte avec Linux et EMC2 ... pour interfacer sur un PC, je vois pas tellement l'interet, autant utiliser EMC2 directement (ou alors j'ai loupé un bout.

Pour le trinamic, j'ai regardé, c'est vraiment sympa ... le seul défaut, mais de taille pour mes besoins qui arrivent bientôt, c'est qu'il ne gère que 3 axes. Vu que je devrais bientôt passer en 4 axes .... :(

Je connais pas le protocole 1588, faut que je zieute C'est un protocole hard ou soft ? Dispo sur du matos grand public ?

Pour synchroniser le mouvement de la machine sur deux cartes séparées, par contre, je ne pense pas que ce soit aussi simple, imaginons que tu définisse la limite de vitesse de tes axes X et Y a une valeur très faible, et tes axes Z et A sont très rapides.

Tu veux un mouvement qui fait bouger les 4 axes, avec une avance théorique supere élevée.

Automatiquement, ta carte qui gère les axes X, Y et Z va ralentir le mouvement pour ne pas surcharger les axes X et Y, mais ca, la carte qui gère l'axe A, n'en sait rien, et donc ira plus vite -> desynchro.

Maintenant c'est ce que je pense, je ne connais pas du tout ce genre de puces et leur gestion, p'tet que je dis une grosse connerie ... mais si c'est aussi simple que tu dis, ca permettrais de mettre deux TMC428 pour gérer jusqu'a 6 axes ?

Quid d'une interpolation circulaire sur deux axes gérés par deux cartes différentes ? (d'ailleurs j'ai rien vu a propos des interpolations circulaires, helicoidales, etc, c'est géré aussi j'imagine ?).

C'est clair que le protocole ethernet est sympa, mais moins facile a mettre en place qu'une puce de conversion USB / serie.

Sinon ca serait possible, d'après tes connaissances, de faire des cartes de contrôle 1 axe, et de les mettre sur le même bus ethernet ? comme ca la modularité est excellente, un module par axe, un module avec des IO pour tout le reste, un switch, et hop c'est parti ... on peut même coller le controleur 1 axe directement au cul du moteur, juste un cable ethernet et une prise alim a lui mettre ...

Et quid des logiciels qui vont lire le G-Code et balancer les infos au controleur de mouvement ? Il en existe des configurables, ou il faut forcément passer par du logiciel maison ?

++

 

[vres]

Au fait, un bon driver de pap passe en mode plein pas ou demi pas à partir d'une certaine vitesse pour garder plus de couple.


Max

Je pense que c'est un argument commercial. A partir d'un certaine fréquence, micropas ou pas, la forme du courant est quasi identique. J'ai fait il y a quelques temps un essai de moteur avec un oscillo sur un resistance shunt pour voir le courant dans le moteur. En fait déja a partir d'une fréquence assez basse on ne distingue plus les pas intermédiaires. J'ai toujours les videos sur mon PC si ça interresse.
J'ai fait un autre test de vitesse avec un PàP à vide, Avec les mêmes rampes, j'ai atteind 2500tr/mn en 400 pas/rev et 4800 tr/mn en 4000 pas/rev. (avec un mauvais driver ). Que faut-il en penser ?

Et quant à l'hystérésis sur un pas, il est faible et je crois qu'il n'augmente pas en micropas,
Max

Je ferai un test dés que possible pour en avoir le coeur net

Christian

 

[Otatiaro]

Yop,

Je regarde du côté du TMC428 ... interessante petite bête

Il semble possible d'en mettre un par axe, et en sortant du step/dir, d'atteindre 333KHz. On est pas loin des 400KHz qu'acceptent la plupart des bons drivers "grand public" du marché.

Niveau prix, ca fait une grosse dizaine d'euros le TMC428, et un euro pour les deux chips qui convertissent le SPI de sortie en STEP/DIR.

En mettant un PIC genre 18F USB2 devant, on pourrait mettre une sorte de "breakout board" USB qui pourrait driver plusieurs (8 max ? soyons fous) modules a base de TMC428.

Le PIC aurait juste a gérer le pooling USB, le transfert de données via 8 interfaces SPI (pour commander les TMC428, mais on peut multiplexer les 8 interfaces ...), et quelques IO supplémentaires.

Reste a savoir comment on peut synchroniser les TMC428 pour qu'ils bossent de concert, et pas chacun de son côté. Armaris ?

Finalement, la conception pourrait être bien plus simple que j'avais prévu ... mais ca ne résoud pas encore le problème du logiciel côté PC.

Si c'est vu du PC comme un port COM virtuel, pas de souci pour programmer un logiciel spécifique ... mais bon si on pouvait profiter d'une base existante ca ne serait pas plus mal (encore que même si j'aime bien Mach3, c'est technologiquement plus franchement au top ... on fait de si belles choses maintenant avec C#, .net et infragistics ...).

++

 

[Otatiaro]

4800 tr/mn en 4000 pas/rev. (avec un mauvais driver ).

Ca fait quand même même 320KHz de step ... pour un mauvais driver, je trouve qu'il s'en sort pas si mal ... si tu en as de trop je veux bien te débarasser

++

 

[armaris]

Merci armaris pour tes conseils et informations !

Y'a pas de quoi, c'est le but du forum partager expériences et connaissances.

Faire une carte avec Linux et EMC2 ... pour interfacer sur un PC, je vois pas tellement l'interet, autant utiliser EMC2 directement (ou alors j'ai loupé un bout.

exact, pour ma part j'ai EMC2 + 2 ports //, ça tiens 40 kHz sans problème sur un vieux Athlon 1.5 GHz.

Pour le trinamic, j'ai regardé, c'est vraiment sympa ... le seul défaut, mais de taille pour mes besoins qui arrivent bientôt, c'est qu'il ne gère que 3 axes. Vu que je devrais bientôt passer en 4 axes .... :(

passe à EMC2

Je connais pas le protocole 1588, faut que je zieute C'est un protocole hard ou soft ? Dispo sur du matos grand public ?

C'est un protocole TCP/IP et il y a des implémentation hard (XScale chez Intel) ou soft (le daemon linux est gratuit), sur Windows c'est payant (driver kernel à 1000$).
Ce sont des solutions industrielles.

Pour synchroniser le mouvement de la machine sur deux cartes séparées, par contre, je ne pense pas que ce soit aussi simple, imaginons que tu définisse la limite de vitesse de tes axes X et Y a une valeur très faible, et tes axes Z et A sont très rapides.

Tu veux un mouvement qui fait bouger les 4 axes, avec une avance théorique supere élevée.

Automatiquement, ta carte qui gère les axes X, Y et Z va ralentir le mouvement pour ne pas surcharger les axes X et Y, mais ca, la carte qui gère l'axe A, n'en sait rien, et donc ira plus vite -> desynchro.

Maintenant c'est ce que je pense, je ne connais pas du tout ce genre de puces et leur gestion, p'tet que je dis une grosse connerie ... mais si c'est aussi simple que tu dis, ca permettrais de mettre deux TMC428 pour gérer jusqu'a 6 axes ?

Quid d'une interpolation circulaire sur deux axes gérés par deux cartes différentes ? (d'ailleurs j'ai rien vu a propos des interpolations circulaires, helicoidales, etc, c'est géré aussi j'imagine ?).

Effectivement la synchro entre puce est problèmatique. La synchro circulaire (sur 6045 uniquement, pas chez trinamic) se fait uniquement au sein d'une puce. Pas d'hélicoïdale chez NPM.

Sinon ca serait possible, d'après tes connaissances, de faire des cartes de contrôle 1 axe, et de les mettre sur le même bus ethernet ? comme ca la modularité est excellente, un module par axe, un module avec des IO pour tout le reste, un switch, et hop c'est parti ... on peut même coller le controleur 1 axe directement au cul du moteur, juste un cable ethernet et une prise alim a lui mettre ...

Je travaille sur un projet de ce type en ce moment mais ça reste cher pour une voie. En plus j'ai rajouté le PoE (Power over Ethernet) pour simplifier le câblage. Dans mon cas, ce sont des axes de positionnement qui ne demande que peu de puissance (quelques Watt).
Il te faut toujours un contrôleur central (PC sous OS temps réel).

Et quid des logiciels qui vont lire le G-Code et balancer les infos au controleur de mouvement ? Il en existe des configurables, ou il faut forcément passer par du logiciel maison ?

Maison, mais c'est assez simple.

 

[Otatiaro]

Après un rapide coup d'oeil au protocole IEEE1588, ca ne semble pas intégré aux switch a 10€ qu'on trouve chez les chinois

 

[vres]

4800 tr/mn en 4000 pas/rev. (avec un mauvais driver ).

Ca fait quand même même 320KHz de step ... pour un mauvais driver, je trouve qu'il s'en sort pas si mal ... si tu en as de trop je veux bien te débarasser

++

Je n'ai que 160 kHz serai-je un menteur ?, je verifie

Ben oui c'etait seulement 2000pas/rev. . bon le resultat reste le même
Christian

 

[Otatiaro]

Yop Armaris !

Pour le trinamic, j'ai regardé, c'est vraiment sympa ... le seul défaut, mais de taille pour mes besoins qui arrivent bientôt, c'est qu'il ne gère que 3 axes. Vu que je devrais bientôt passer en 4 axes .... :(

passe à EMC2

4 Axes a 40KHz, Mach3 le gère normalement, donc a priori aucune raison de passer sous EMC2 (si j'avais pas déjà eu une license Mach3, ca aurait été différent).

Je connais pas le protocole 1588, faut que je zieute C'est un protocole hard ou soft ? Dispo sur du matos grand public ?

C'est un protocole TCP/IP et il y a des implémentation hard (XScale chez Intel) ou soft (le daemon linux est gratuit), sur Windows c'est payant (driver kernel à 1000$).
Ce sont des solutions industrielles.

Oui, vu.

Pour synchroniser le mouvement de la machine sur deux cartes séparées, par contre, je ne pense pas que ce soit aussi simple, imaginons que tu définisse la limite de vitesse de tes axes X et Y a une valeur très faible, et tes axes Z et A sont très rapides.

Tu veux un mouvement qui fait bouger les 4 axes, avec une avance théorique supere élevée.

Automatiquement, ta carte qui gère les axes X, Y et Z va ralentir le mouvement pour ne pas surcharger les axes X et Y, mais ca, la carte qui gère l'axe A, n'en sait rien, et donc ira plus vite -> desynchro.

Maintenant c'est ce que je pense, je ne connais pas du tout ce genre de puces et leur gestion, p'tet que je dis une grosse connerie ... mais si c'est aussi simple que tu dis, ca permettrais de mettre deux TMC428 pour gérer jusqu'a 6 axes ?

Quid d'une interpolation circulaire sur deux axes gérés par deux cartes différentes ? (d'ailleurs j'ai rien vu a propos des interpolations circulaires, helicoidales, etc, c'est géré aussi j'imagine ?).

Effectivement la synchro entre puce est problèmatique. La synchro circulaire (sur 6045 uniquement, pas chez trinamic) se fait uniquement au sein d'une puce. Pas d'hélicoïdale chez NPM.

Mmmmhhh ... si pas d'interpolation circulaire, on fait comment ? on décompose chaque cercle en bout de droite ??? :/

Sinon ca serait possible, d'après tes connaissances, de faire des cartes de contrôle 1 axe, et de les mettre sur le même bus ethernet ? comme ca la modularité est excellente, un module par axe, un module avec des IO pour tout le reste, un switch, et hop c'est parti ... on peut même coller le controleur 1 axe directement au cul du moteur, juste un cable ethernet et une prise alim a lui mettre ...

Je travaille sur un projet de ce type en ce moment mais ça reste cher pour une voie. En plus j'ai rajouté le PoE (Power over Ethernet) pour simplifier le câblage. Dans mon cas, ce sont des axes de positionnement qui ne demande que peu de puissance (quelques Watt).
Il te faut toujours un contrôleur central (PC sous OS temps réel).

Ha, donc en mettant un module par axe, on est obligé de refaire du temps réel pour les synchroniser ...

Et si le PIC gère la synchro entre les différents modules, ca simplifies pas mal, non ?

En tout cas, y'a aucun mécanisme de synchronisation inter-puce d'origine ?

Et quid des logiciels qui vont lire le G-Code et balancer les infos au controleur de mouvement ? Il en existe des configurables, ou il faut forcément passer par du logiciel maison ?

Maison, mais c'est assez simple.

Ok, pas forcément le plus simple, mais on est aussi là pour se faire plaisir

Mais ca veut dire mettre au point un protocole entre le PC et le PIC d'interface (toujours dans l'optique d'un module par axe et d'un PIC pour faire l'interface) ...

++

 

[armaris]

Il y a une ambiguité dans les discussions précédentes sur le contrôle temps-réel :
- avec les CI contrôleurs de moteurs pap (trinamic, NPM), la commande est déterministe, tu envois tes ordres au contrôleur qui gère les axes et les différentes interpolations en TR mais il n'y a aucun retour d'informations.
Les interpolations, ce ne sont que des combinaisons de lois linéaires ou autres entre axes (ECAM).
Même si tu mets un codeur, tu n'a qu'une info d'erreur (pas perdus et éventuellement glissement quand tu tournes trop vite) mais il n'y a pas de rattrapage en temps réel, la seule info que tu as c'est un signal d'erreur et tu sais que ta pièce est HS, c'est tout.
- avec EMC2, tu as un asservissement et le logiciel rajoute des pas pour atteindre la position/vitesse désirée (même sur des pas à pas).

je pense que la fréquence max. est un faux problème :
à haute vitesse le moteur ne suis pas d'où glissement et plus besoin de micropas donc la fmax est réduite.

J'ai fait un autre test de vitesse avec un PàP à vide, Avec les même rampes, j'ai atteind 2500tr/mn en 400 pas/rev et 4800 tr/mn en 4000 pas/rev. (avec un mauvais driver Wink ). Que faut-il en penser ?

C'est un glissement (perte de pas continue)
Si tu mets un codeur sur ton axe moteur, tu verrais ta perte de pas à partir d'une certaine vitesse.
Et tu vois aussi plein d'autre choses avec un codeur haute résolution (j'utilise un AEDA-3200 - 30000 pas/tr en 4x) : rebonds, non-linéarité, ...

 

[armaris]

Après un rapide coup d'oeil au protocole IEEE1588, ca ne semble pas intégré aux switch a 10€ qu'on trouve chez les chinois

En théorie, il faut des switchs spécifiques, en pratiques avec des switchs manageables 1Gbits, j'arrive à de très bonne performances (1 µs - switch dédié à la partie temps-réel).
Petit bémol, il faut 1h pour que la PLL se synchronise à 1µs. Après 1 min, on est à 150µs de synchro et 10µs à 5 min.

 

[vres]

Il y a une ambiguité dans les discussions précédentes sur le contrôle temps-réel :
C'est un glissement (perte de pas continue)
Si tu mets un codeur sur ton axe moteur, tu verrais ta perte de pas à partir d'une certaine vitesse.
Et tu vois aussi plein d'autre choses avec un codeur haute résolution (j'utilise un AEDA-3200 - 30000 pas/tr en 4x) : rebonds, non-linéarité, ...

Oh la! non non, pas de glissement, pas de perte de pas. Même apres plusieurs aller retour le moteur revient pile poil au même endroit. Pourtant 4800tr/mn c'est la vitesse limite aprés ca décroche. Personnellement je n'ai jamais contaté de glissement à haute vitesse, mais je ne depasse pas 1500tr/mm non plus en usage normal.

 

[armaris]

Le glissement dépend de la charge, effectivement à vide c'est difficile de perdre des pas.

 

[vres]

Le glissement dépend de la charge, effectivement à vide c'est diffici

Le glissement dépend de la charge, effectivement à vide c'est difficile de perdre des pas.

Si il y a glissement, le moteur se retrouve à contre-couple dés que le glissement depasse un pole, je ne pense pas que le moteur supporte ce couple en sens inverse en pleine vitesse. C'est le decrochage Immediat.
A basse vitesse on perd 4 pas et ça repart. Je pense que si il y a une perte de 1 ou 2 pas ou glissement a haute vitesse il faut plutot regarder au niveau du pilotage.
Lorsqu'un moteur pas à pas est equipe de codeur, le driver peut surveiller la position du moteur et commuter les phases pour avoir toujours le couple maximum et eviter le cas ci-dessus. Le systeme est proche du moteur brushless avec beaucoup plus de pôles. Le driver ECOSTEP 200 que je connais bien travaille ainsi.
Christian