LinuxCNC tourne sur la carte BeagleBone Black

[douardda]

Re: Re : LinuxCNC tourne sur la carte BeagleBone Black

Je ne conaissais pas ces cartes qui ont l'air intéressant (ni le standard ouvert EDM). Par contre, pour le pilotage de machine a commande numérique le nombre de GPIO est assez limité (en tout cas exportés sur l'EDM). Et par rapport à la BeagleBone Black il n'y a rien qui aide au pilotage des IO temps réel, faut donc soit se contenter de vitesses très réduites, soit faut un FPGA. L'autre intérêt de la BBB aujourd'hui est que ça marche tel quel avec MachineKit.

David

 

[nopxor]

bonsoir,

il y a aussi les Udoo avec les mêmes processeurs freescale et la compatibilité arduino avec en plus un SAM3X8E ARM Cortex-M3 CPU. Les PRU sont l'intérêt de la Bbb car sinon c'est un peu léger apparemment au niveau processeur graphique. le cortex A9 est aussi un plus car les instructions sur les float sont 10 fois plus rapides qu'en A8. La TRE se fait attendre et sera sans doutes chère tout en étant très proche de la Bbb.

 

[hellmo]

Bonjour à tous,

Voilà, ça fait quelques temps que j'épluche tout ce que je trouve sur cette Beaglebone mais, vu la quille que je suis en informatique et électronique, j'avoue que je suis quelque peu largué...

J'ai un petit tour Emco C5 PC, des pas à pas nema 23 et des drivers Leadshine DM556. La broche quant à elle est équipée d'un variateur de fréquences.
Jusqu'à présent je n'ai vu que des montages avec des cartes qui embarquent des petits drivers 1,5/2A max sur des imprimantes 3D principalement.

A priori ça devrait aussi faire l'affaire dans mon cas si je câble les moteurs en série.
Mais j'ai déjà les drivers...puis sur le schéma qu'a posté Marc PELTIER, en page 3 de ce sujet, on voit des pins STEP/DIR sur la Beaglebone.
Et partout je lis que son intérêt principal ce sont ses 2 PRU, alors, pour en venir à ce qui me taraude :

Puis-je connecter (et faire fonctionner...) directement mes drivers aux pins STEP/DIR de la Beaglebone ??? Le variateur aux pins PWM, etc...? Le capteur photo sensible de la broche (ou un encodeur) peut-il aussi être connecté ?
Ce serait trop beau pour être vrai, mais dites-moi oui ! Dites-moi oui ! Que je fasse péter une Beaglebone et son écran tactile pour Noël (ou la Saint Nicolas même...) !

Cependant, j'ai aussi une tourelle auto qui va très certainement recevoir un pas à pas en nema 17 et qui nécessitera donc un driver supplémentaire...
Serait-il dans ce cas plus judicieux de partir direct sur un montage avec une RAMPS FD et des drivers Pololu ? Ou une autre solution ?

Ou alors je fais carrément fausse route et ferais mieux d'acheter un vrai PC avec une vraie carte d'interpolation ?

Quoi qu'il en soit, merci par avance si vous pouvez m'aider, parce que là je commence sérieusement à m'arracher les cheveux.
@+

 

[hellmo]

Bon, voilà sur quoi je viens de tomber...Beaglebone with no cape ?

 

[speedjf37]

Bonjour,


Attention la carte "Rosetta bone" est seulement un câblage de répartition des pins du beaglebone black.

Il n'y a pas d'adaptation des tension et les sorties sont en 3.3V sans protection.

Il me parait plus sur d'utiliser une carte cape DB25 qui converti les signaux en 5V et permet l'adaptation directe d'une breakboard

http://blog.machinekit.io/p/hardware-capes.html#Xylotex

Un kit complet:
http://xylotex.netfirms.com/OSCommerce/catalog/product_info.php?cPath=27&products_id=53


Un détail important sur la beaglebone black : la sortie vidéo est en HDMI (pas de VGA ou DVI),


Cordialement JF

 

[hellmo]

J'avais vu le kit de Xylotex mais ils n'envoient à priori pas en Europe.
http://xylotex.netfirms.com/OSCommerce/catalog/Int_Ship.php

Probotix de leur côté envoient en Europe...vais leur envoyer un mail pour voir.

Les drivers Leadshine sont équipés d'optocoupleurs, ça ne suffit pas à protéger la Beaglebone ?

Sur la fiche technique du driver il y a écrit : 4-5V when PUL-HIGH, 0-0.5V when PUL-LOW.
Quelle incidence a le fait que les sorties soient en 3,3V ? Pas possible de le convertir "simplement" ?

 

[Marc PELTIER]

@hellmo

Je confirme que la BBB peut tout faire aussi bien que n'importe quelle plate-forme. C'est de la pâte à modeler. Naturellement, le corollaire est qu'il faut savoir sculpter dans ladite pâte à modeler.

Par exemple, à propos des broches STEP DIR en direct sur les connecteurs de la carte :

Il faut comprendre que le BBB est beaucoup plus évoluée qu'une carte Arduino avec ses connecteurs normalisés, sur lesquels chaque broche a une fonction bien définie, et invariable. Sur la BBB, les 90 broches physiquement présentes sur les connecteurs sont en majorité multiplexées, c'est à dire que chaque broche peut adopter une demi-douzaine de fonctions différentes, en fonction d'une programmation préalable.

Le multiplexage est géré par un truc qui s'appelle DTO (Device Tree Overlay). Un DTO est une sorte de masque qui précise l'affectation de chaque broche physique. Toutes les fonctions des processeurs internes de la BBB ne peuvent pas être routées indifféremment sur n'importe quelle broche, il y a des contraintes, et certaines incompatibilités, par exemple avec la gestion de la sortie vidéo HDMI. Les broches qui nous sont utiles sont principalement celles qui peuvent être reliées aux deux PRU.

Le site ci-dessous, très bien fait, fournit une représentation interactive de chaque broche, et des contraintes associées. Il suffit de cliquer sur une broche, et l'on voit ce que cette broche peut faire, ainsi que les incompatibilités éventuelles :
http://eskimon.fr/beaglebone-black-gpio-interactive-map

Du côté logiciel, on a MachineKit, qu'il faut voir comme un descendant moderne de LinuxCNC, beaucoup plus ambitieux, avec son architecture décentralisée et multi plate-forme, dont les différents modules peuvent intéragir via un réseau, ou le Web. Traduction : on peut désormais piloter sa CNC depuis son smartphone, via le web s'il faut...

Donc, avec MachineKit tournant sur la BBB, on peut demander à cette dernière de faire mouliner ses petits PRU pour fabriquer des signaux STEP/DIR/EN, et les affecter, via DTO, à certaines broches, que l'on pourra alors baptiser sans vergogne "broches STEP/DIR/EN directes", pourquoi pas ? On peut donc brancher directement à ces broches des gros drivers en rack ou indirectement, via une carte comme la RAMPS-FD, des petits Pololus, c'est pareil.

Dans le cas des schémas que j'ai publiés, pour me simplifier la vie, j'avais adopté l'affectation de broches qui avait été créée pour la "cape" BeBoPr, d'où la présence de signaux STEP et DIR à certains endroits précis. Mais si l'on se sent capable de bidouiller MachineKit et sa couche HAL, on peut aussi bien apprendre le fonctionnement des DTO, ce n'est pas bien compliqué. Les signaux STEP, DIR et EN pourront alors être affectés à volonté partout où c'est possible.

La BBB peut gérer sans difficulté au moins six axes de moteurs PàP avec chacun les trois signaux STEP, DIR et EN. Les canaux STEP peuvent monter, actuellement, jusqu'à 60 kHz simultanément, mais les gourous de MachineKit disent que si quelqu'un se donnait la peine d'optimiser la programmation des PRU, on pourrait taquiner les 2 MHz, c'est à dire aussi bien que les cartes spécialisées à FPGA, genre MESA. Pas mal, pour un truc à 55 € !

 

[Marc PELTIER]

A propos de la compatibilité électrique et des protections :

La BBB fonctionne en 3,3V, les signaux logiques sortants sont donc de cette tension. J'ai alimenté avec des signaux STEP, DIR et EN à 3,3V différents petits drivers (Pololu, Toshiba TB5560) prévus en principe pour écouter du 0 à 5V, et alimentés en 5V, sans difficulté. En général, une tension de 3,3V est vue comme un "1" par une logique à 5V. Naturellement, je ne peux pas garantir que ce sera toujours vrai, il faut faire des essais, et au besoin, buffériser les signaux.

Ce à quoi il faut faire très attention, c'est dans l'autre sens : tout signal logique entrant sur la BBB à 5V la grillera instantanément ! Et sur les entrées analogiques, c'est pire : 1,8V maximum.
Donc, être vigilant pour le câblage des fins de course et capteurs divers.

 

[hellmo]

Bonjour,

Tout d'abord un grand MERCI pour cette réponse.

C'est donc bien ce qu'il me semblait. A condition de respecter les tensions entrantes on peut se passer d'une carte d'interpolation.
Mais j'ai tout de même du mal à me faire à cette idée...c'est juste trop génial ce truc !
Ça prend pas de place, ça consomme presque rien, ça simplifie beaucoup de choses et c'est carrément pas cher comparé à un PC + carte + écran.

Un peu moins de 125 € chez Mouser avec une cape TFT 7" tactile, que demander de plus ?
Des cours de programmation par exemple...parce que c'est bien la seule chose qui me rebute encore et qui fait qu'au final j'ai tout de même repris un PC qui m'aura coûté près de 2 fois la somme mentionné ci-dessus... :(
J'ai jamais touché Linux, donc encore moins LinuxCNC et j'avais peur qu'en partant tout de même sur la BBB je mette 6 mois à réussir à faire bouger un axe.

Mais j'ai un autre truc sous le coude, qui lui ne bougera de toute façon pas avant au moins 6 mois, et auquel la BBB siérait (et siéra sans doute) encore mieux.
D'ici là j’espère m'être familiarisé avec l'environnement Linux, donc bon, je garde tout ça précieusement de côté et reviendrais par ici si ça fonctionne.

@++

 

[Marc PELTIER]

Attention à l'écran tactile 7" : c'est justement le genre de périphérique qui s'approprie et neutralise un gros paquet de broches d'entrée/sortie.
Je n'en ai pas l'expérience directe moi-même, mais je sais que c'est un souci pour les concepteurs de capes.
Il faut aussi avoir assez de résolution sur l'écran pour afficher les programmes d'interface utilisateur de MachineKit, comme AXIS par exemple.
Jusqu'à maintenant, j'ai toujours utilisé une télé avec entrée HDMI comme écran, à la résolution 1920x1080.

 

[hellmo]

Effectivement, je l'avais pas vu sous cet angle...dommage car c'est très séduisant.

 

[hellmo]

Salut tout le monde,

Voilà 1 mois que je vais de galère en galère avec mon nouveau PC, donc lundi soir après avoir longuement bavé sur le site de Mouser j'ai craqué et ai mis 2 Beaglebone dans le panier. On sait jamais dés fois que j'en cramerais une...

Je vais laisser le soin à mon frangin d'installer Linux et Machinekit, ce qui j'espère sera fait dans la semaine qui vient, puis on pourra vérifier si les drivers Leadshine acceptent le 3,3V. Mais, s'il s'avérait que ça fonctionne pas, est-ce qu'un convertisseur de niveau logique comme celui ci ferait l'affaire ? Il est précisé que ce convertisseur ne fonctionne pas avec des signaux analogiques, s'agissant de la commande des drivers je présume que c'est un signal numérique, mais est-ce bien le cas ?

Pour les fin de course je veillerais donc à les alimenter en 1,5V. En revanche pour ce qui est du capteur optique de broche, je doute qu'il fonctionne avec 1,5V. J'ai bien vu des convertisseurs analogique=>numérique mais j'ai aussi vu ceci commercialisé pour Arduino, ça tourne en 3,3V et le signal en sortie est numérique donc ça devrait aussi aller avec la BBB sans convertisseur ni autre. Par contre faut-il des optocoupleurs ou pas de risque avec ces tensions ?

@++

 

[speedjf37]

Bonsoir,

L'adaptateur cité est un convertisseur de niveau (tension) bidirectionnel.

Il ne délivrera probablement pas de courant pour alimenter les optos en entrée des drivers.

Il faut utiliser les même composants que sur les capes dédiées au BBB.

Cordialement JF

 

[hellmo]

Bonsoir à tous,

Je viens vous donner quelques nouvelles de ma beaglebone.

Primo l'installation de MachineKit. Mettre la carte micro SD (avec l'image de MachineKit) dans le lecteur, brancher la BBone par USB à un ordi, appuyer sur le minuscule bouton PWR, fumer une clope (facultatif)...c'est fini. Jamais rien vu d'aussi rapide.

Deuxio le choix du matos. J'avais donc déjà des drivers DM556 et des pas à pas nema 23. L'option drivers Pololu DRV8825 m'a beaucoup travaillé. J'en ai d'ailleurs commandé 2 mais j'ai laissé tombé parce que mon alim est un chouilla trop puissante, du moins la tension de sortie est trop élevée. Puis une fois que t'as le truc entre les mains, sincèrement, ça met plus trop en confiance, 2 x 1,6 cm c'est vraiment minuscule. Tout ça pour rien dire à part que je suis tout de même parti sur mes DM556 et j'ai aussi pris des convertisseurs de niveau au cas où. Donc un DM556 c'est ça :


Tertio le branchement/câblage. Tout d'abord oubliez l'adaptateur HDMI/VGA. Ca marche pas, l'image tremble, 15€ de perdu (m'enfin, je suis plus à ça près...). Me suis donc fendu d'une centaine d'euros de plus pour un nouvel écran. Mais ça on s'en balance aussi, hein. Non, (tout) ce qui est intéressant c'est AVEC ou SANS convertisseur de niveau ? Et bien pour ma part ce sera sans ! Et oui, Marc avait raison, ces fichus drivers fonctionnent sans problème avec un signal 3,3V !!! Perso j'ai pas réussi à charger la pré-configuration pour la BeBoPr, si j'ai bien compris elle est en conflit avec les pins HDMI et comme j'avais pas envie de me prendre le chou mais que surtout j'y capte que dalle j'ai pris celle pour la Cramps ( schéma dispo ici ). Donc, une fois les pins repérés sur la BBone, reste plus qu'à les brancher aux drivers, tout simplement. C'est tellement c*n que j'en rigole tout seul.

Donc pour conclure, LinuxCNC tourne sur la Beaglebone ET permet de se passer d'un PC ainsi que d'une carte d'interpolation ! C'est pas beau ça ? Moi en tout cas je suis conquis !

Bon, j'ai pas fini, faut maintenant que je pose mes capteurs et que je configure LinuxCNC correctement, entre autres...mais ce sera pour un autre jour.

@++

 

[fredcoach]

Merci pour ce retour d'expérience détaillé.

 

[Marc PELTIER]

Bravo Hellmo, ça fait plaisir !

Je signale que MachineKit peut désormais être également installé sur une configuration Linux Debian par package, comme n'importe quelle application, et que ça ne concerne donc pas que la BBB :
http://blog.machinekit.io/2014/12/holiday-packages.html

D'autre part les sources des images MachineKit pour BBB sont mises à jour automatiquement toutes les quinzaines :
http://blog.machinekit.io/2015/01/new-beaglebone-images-avaialble.html

Il y a aussi des adaptations pour Rasberry Pi V2 en cours, mais la BBB est beaucoup plus douée pour le temps réel que la "Raspi", et la différence de prix n'est pas très significative... Mais ceci montre que d'autres cartes seront éligibles, à terme.

MachineKit devient donc le successeur probable de LinuxCNC, et c'est très excitant, au vu des développements en cours.

Allez-y, il n'y a plus de raison d'attendre !

 

[gaston48]

Allez-y, il n'y a plus de raison d'attendre !

Bonjour,
J’ attends que ce soit aussi puissant qu’un PC avec système Mesa
qui pilote des axes servo (codeurs et PID gérés par linuxcnc).

 

[Marc PELTIER]

Ben si, MachineKit gère les servos, les encodeurs en quadrature, les boucles PID, les cartes à FPGA type MESA et autres, et tout ce que faisait LinuxCNC, puisque MachineKit, c'est LinuxCNC plus plus !

Toutefois, l'ensemble étant encore beaucoup moins diffusé que LinuxCNC, il se peut que toutes configurations n'aient pas encore été reproduites sur MachineKit, mais comme on sait, il ne s'agit que d'écrire ou d'adapter quelques fichiers HAL et INI bien sentis...

En ce qui concerne MESA sur PC, ça tourne depuis un moment. Je suis plutôt branché BBB, mais je suis sûr d'avoir vu passer des commentaires en ce sens sur le blog de MachineKit.

 

[gaston48]

Le problème est que c’est Mesa qui doit s’intéresser à BBB, ses cartes ne s’interface que par bus PCI

 

[Marc PELTIER]

Gros malentendu : MachineKit, ce n'est pas que la BeagleBone Black ! L'application à la BBB n'est que la conséquence du fait que MachineKit n'est plus limité aux plates-formes Intel.

Je récapitule la situation :
Un groupe de développeurs a repris en main LinuxCNC, qui commençait à somnoler, pour le moderniser, avec deux objectifs principaux :

1 - Sortir de la limitation aux PC compatibles Intel X86, en permettant notamment la prise en compte des architectures ARM (dans un premier temps, car l'ambition est de gérer n'importe quelle architecture, au moins pour la partie qui n'a pas besoin d'être en temps réel)
2 - Décentraliser le logiciel, en permettant aux différents modules de tourner sur différentes machines (et sur des plates-formes différentes), avec éventuellement des liens réseau (y compris Web) entre les modules. La conséquence immédiate est que l'on peut implanter la partie "temps réel" sur une machine, et la commander depuis son smartphone, qui recevra en même temps un flux vidéo d'une caméra filmant la machine (c'est un exemple).

A cet effet, différentes interfaces utilisateur nouvelles sont en cours de développement, comme Cetus et Machineface :
http://blog.machinekit.io/2014/11/new-q ... faces.html

Ces interfaces tournent d'ores et déjà sous Windows, Mac, Linux, Androïd et iOS.
Le cahier des charges prévoit de gérer plusieurs dispositifs physiques collaborants (CNC, bras robots, convoyeurs, etc...) à partir d'une même interface.

MachineKit, c'est en fait la renaissance et la redéfinition de LinuxCNC, dont le code est restructuré dans un concept d'une part multi-plateforme, et d'autre part décentralisé.

Pour en revenir à la configuration PC et MESA, elle est bien entendu possible sur MachineKit : qui peut le plus peut le moins !

 

[hellmo]

Hello,

Grosse prise de tête cet après midi, 6 heures d'affilée à patauger dans les fichiers .hal et .ini...

Donc, pour la faire court, j'ai modifié CRAMPS.hal puis j'ai mixé et arrangé un peu les fichiers lathe.ini (de Axis) et CRAMPS.ini pour faire 2 fichiers que j'ai renommé EMCO.ini et EMCO.hal et placé dans un dossier EMCO.
Dans ce dossier j'ai également rajouté quelques fichiers aux quels il est fait référence dans les fichiers .ini et .hal (je sais pas si ça c'est utile ou non).
Puis j'ai mis ce dossier dans le dossier AXIS.
Quand je lance linuxcnc je choisi EMCO dans l’arborescence.
Résultat j'ai l'écran d'Axis et mes moteurs tournent avec le brochage de pins "CRAMPS".

Je suis trop content, je pensais sincèrement pas y arriver, hier soir quand j'ai commencé à fouiller dans les .hal et .ini j'étais vraiment désespéré tellement c'était incompréhensible. Et là, alors que j'y croyais plus du tout, à chaque modif que je faisais j'avais une autre erreur, tout à coup ça a marché, j'ai sans déconner halluciné !

Cela dit je suis pas certain d'avoir tout bien fait, mes moteurs tournent beaucoup moins vite que lorsque je charge une configuration CRAMPS classique et ils chauffent beaucoup plus. Et quand je dis beaucoup c'est vraiment beaucoup. La vitesse ça à priori je devrais pourvoir le régler dans le fichier .ini mais pour la température je sais pas à quoi est liée cette différence.

Mais bon, là j'ai eût mon compte, je verrais peut être ça demain...

@++

 

[gtt38]

J'ai passé moi aussi des heures sur des fichiers ini et hal avant que cela ne fonctionne !
J'utilise un BB sur une Proxxon mf70 CNCisée depuis quasi un an avec une carte chinoise et des moteurs Nema 17 : une solution hyper economique. J'utilise un cape Xylotex qui marche super bien et qui ne coute pas cher, j'ai juste usé du fer a souder pour rediriger les pins vers la correspondance de la carte chinoise.
Un seul bémol la limitation de la génération de pas du BB (on est a des années lumieres de ma 5i25/7i76). Je fais 1 tour par mm sur ma proxxon ce qui limite ma vitesse selon le mode de micropas que j'utilise. j'ai descendre bas dans les micropas ce qui me permet d'obtenir un fonctionnement "smooth" et generant moins de bruits, je me retrouve donc avec une vitesse limitée a 5mm/s² mais ca me suffit amplement.
J'avoue que le BB a un gros avantage par rapport au port // : la qualitée des pas emis est bien meilleure avec moins de bruits parasites qu'un pc.
J'attends encore (un an après) la sortie d'un cape FPGA Xyllinx. Cela permettrais d'emettre des pas a 10Mhz d'une qualitée comparable au Mesa 5i25. Apparament Jeff de Xylotex a l'air d'avoir abandonner l'idée...
http://emc-users.narkive.com/n8xh30OM/beaglebone-fpga-with-linuxcnc

 

[Marc PELTIER]

5mm/s, ça me semble bien faible comme limite. Avec un pas de 1 mm, ça fait 5t/s, soit 5x200 = 1000 pas/s full step (moteurs 1,8°), et donc 16000 pas/s avec 16 micropas logiques par pas physique. BBB peut faire trois ou quatre fois mieux, avec les pilotes actuels.

Il doit y avoir un paramètre limitant dans les fichiers INI et HAL, par exemple BASE_PERIOD, MAX_VELOCITY, INPUT_SCALE, ou STEPGEN_MAXVEL.
Vérifier aussi que les durées des créneaux du signal STEP ne sont pas excessives (STEPLEN, STEPSPACE).

Il est certain qu'une carte MESA va beaucoup plus vite qu'une BBB pour générer les pas, mais l'écart pourrait se réduire. Dans le package MachineKit actuel, la programmation des PRU n'est pas vraiment optimisée. Aux dires de Charles Steinkuehler, avec optimisation on pourrait sans doute atteindre les 2 MHz. Toujours moins qu'une carte à FPGA, mais quand même très très bien, et beaucoup mieux que n'importe quel PC...

Ces PRU se programmaient difficilement, et il n'y avait pas beaucoup de documentation. Ça va sans doute changer :
http://hackaday.com/2015/02/16/library-upgrade-to-pru-gives-fast-io-on-beaglebone/

D'ores et déjà, il semble que l'on puisse monter à 300 kHz en diminuant la valeur de pru_period :
https://groups.google.com/forum/#!topic/machinekit/pIAq2Te69a4

 

[gtt38]

Merci Marc je ne pensait pas qu'on pouvait encore "tuner" les sorties, 300khz c'est déjà vraiment pas mal alors si on arrive a 2 Mhz les Mesa auront peu d'avantages (je crois que la mienne limite a 10Mhz)
Concernant mon installe, je suis au 128eme de pas il me faut donc 25600 pas pour faire 1mm
donc 25600x5= 128khz
J'essayerai de monter progressivement plus haut pour trouver les limites du BB mais a 10mm/s² c'est sur ca ne passe pas (j'ai des erreurs)

 

[gtt38]

Apres essais il est possible d'attendre une valeure proche de 10mm/s² en utilisant ces parametres :

CONFIG=pru=0
num_stepgens=4
num_pwmgens=6
pru_period=2500

DIRSETUP = 5000
DIRHOLD = 5000
STEPLEN = 2501
STEPSPACE = 2501

Attention de ne pas mettre une periode PRU égale a la longueur d'un pas

J'ai testé et j'atteins bien 256 khz avec le BB (10mm/s²)

je sais que je peut atteindre 15mm/s² avec ma machine voir plus, j'attends donc avec impatience qu'on puisse atteindre les 2Mhz pour y arriver....

 

[hellmo]

Chez moi ça stagne à un peu plus de 64Khz pour l'instant. J'ai essayé de mettre CONFIG=pru=0, ça fonctionne mais j'ai un message "warning...pru=0" au lancement.
Mais c'est pas grave, j'ai pas l'intention de dépasser 4mm/s...

Ce qui me tracasse plus pour l'instant c'est l'asservissement à la broche.
J'ai trouvé cette page qui traite du sujet .
L'idée serait de modifier les 3 dernières lignes de la partie HAL comme ceci :

net spindle-phase-a encoder.0.phase-A <= bb_gpio.p8.in-10
net spindle-phase-b encoder.0.phase-B
net spindle-index encoder.0.phase-Z <= bb_gpio.p8.in-09

Donc les pins P8-09 et P8-10 sont celles qui étaient dédiées aux fins de course du Y dans le fichier CRAMPS.hal et dont je n'ai pas besoin.
Pour que ça accepte de se lancer il a fallut rajouter :

EMCMOT base_period_nsec=[EMCMOT]BASE_PERIOD

Je pense que je devrais encore rajouter :

setp bb_gpio.p8.in-10.invert 1
setp bb_gpio.p8.in-09.invert 1

Ca vous semble correcte ? LinuxCNC se lance et tout, y a pas de soucis, mais j'ai pas encore pu tester, broche et moteur étant démontés...

@++

 

[Marc PELTIER]

Je n'ai jamais encore configuré d'encodeur, mes conseils seront donc limités.

Il y a trois signaux à gérer pour un encodeur en quadrature complet :

• Phase A
  Phase B
  Index

Ici, il n'y a que deux déclarations de pin :

• bb_gpio.p8.in-09
  bb_gpio.p8.in-10

La phase B est ignorée, il s'agit donc d'une simple mesure de vitesse, mais on ne connait pas le sens de rotation. Ok pour une broche, sans doute...

 

[gtt38]

J'utilise un encodeur sur ma mesa 5i25/7i76 sur PC (tour). Aucune idée si ça fonctionne sur BB mais apparemment plusieurs ricains ont réussi le coup.
J'utilise une quadrature (phase A phase B et Index)
Tu peux aussi utiliser uniquement phase A et Index ça marche aussi voir même uniquement Index mais pour fileter en numérique c'est plus compliqué.
Le meilleur lien qui m'a servi de base a mon code sur mon tour c'est celui la :
http://7xcnc.com/hardware/encoder/
C'est un ricain qui a créé un encoder pour moins de 5$. J'ai largement amélioré le système en mettant une phase B en plus je me suis débrouillé a régler l'ensemble grâce a halscope.
Par contre sur BB il faut un code spécifique il me semble. Je n'arrive plus a retrouver le lien d'un gars qui a réalisé un encoder sur BB.

J'adore Linux, je n'y connais absolument rien en programmation et en Python, mais il est très très simple d'assembler les lignes de codes piqués a gauche et a droite pour réaliser un système 100% personnalisé.
J'avoue que c'est un peu compliqué au début et l'interface rebute mais quand on a compris le principe tout deviens limpide.

A tous je conseille la doc de linux CNC en FR et surtout le manuel de l’intégrateur ainsi que le manuel Hal qui permette de tout comprendre extrêmement rapidement. il deviens très facile ensuite de personnaliser les fichiers ini et hal.

 

[nopxor]

Bonjour,

J'ai trouvé une autre carte qui va permettre d'expérimenter MachineKit à moindre coûts.
La Snowball de Calao Systems, issue du projet Linaro.

2 fois les performances de la BBB, avec en plus une ribambelle de périphériques modernes et de GPIO.
Nova DualCore CortexA9 @ 1GHz, 1Go RAM, 8Go Flash => 35€ht.

 

[speedjf37]

Bonjour,

Bonjour,

J'ai trouvé une autre carte qui va permettre d'expérimenter MachineKit à moindre coûts.
La Snowball de Calao Systems, issue du projet Linaro.

2 fois les performances de la BBB, avec en plus une ribambelle de périphériques modernes et de GPIO.
Nova DualCore CortexA9 @ 1GHz, 1Go RAM, 8Go Flash => 35€ht.

Il y a détail qui me gène:
Not Recommended for New Designs

Cordialement JF