Numérisation de mon tour BL200L-1 (BV20L)

[bipbip30]

je ne connais pas rufus mais tu devrais quand même essayé en ultra classique avec DVD parce ce que si il n'accepte pas l'image de LinuxCNC.org ça n'est pas rassurant.

pour les clé bootables j'utilise http://www.clubic.com/telecharger-fiche312272-linux-live-usb-creator.html

 

[coredump]

La gravure a été faite sur une cle USB avec le logiciel rufus 2.6.
Cette méthode a fonctionné avec l'image d'ubuntu classique, mais pas avec celle proposé sur LinuxCNC.org

Il faut que tu utilise l'image ISO de linuxCNC car elle est en i386 et pas celle d'ubuntu car c'est une image AMD64 (64 bits). Ton processeur est compatible i386 et AMD64, tout dépends ensuite du logiciel installé.
Essaye avec unetbootin pour créer ta clef a partir de l'iso linuxcnc.

 

[carlos78]

Comme il fait trop froid dans mon sous-sol, j'ai remonté le PC pour continuer mes essais.
Avec le seul iso LinuxCNC officiel proposé ça ne marche pas même en live.
Le seul choix du menu qui aboutisse à quelque chose c'est le mode live failsave (probablement un mode sans échec du live).
Avec ce mode j'ai pu enfin voir à quoi ressemble LinuxCNC avec Debian. Bonne surprise, le look est plutot sympa : Je retrouve un bureau très proche de l'Ubuntu avec l'ancien gnome classic qui permet de trouver facilement toutes les applications.
C'est beau, mais le hic est que dans ce mode je ne sais rien faire, même pas le latency test.
Dans tous les autres modes d'installation, y compris le live normal il y a plein d'erreurs qui s'affichent à l'écran dont une qui me parait fatale : "microcode AMP Cpu family Oxf not supported".

Carlos

 

[bipbip30]

tu as fait un dvd de boot ?

tu devrais lire cette page http://www.amd64.org/microcode.html et celle-ci https://wiki.debian.org/fr/Microcode

 

[coredump]

Non ca ce n'est pas un soucis. Tu dois avoir du materiel non supporté qui empèche un boot correct.

 

[carlos78]

Bonjour à tous,

Une bonne nouvelle : Mon ordinateur tourne enfin avec LinuxCNC et son temps de latence est vraiment très bon (moins de 3000 ns)

Gaston48, Coredump et Bipbip30 avaient raison le problème n'etait pas le processeur AMD64.

Mon problème reste et demeure toujours l'installation de la dernière version de LinuxCNC.
Pour comprendre si c'était LinuxCNC ou Debian qui posait problème, j'ai essayé l'installation de Debian tout seul et aucune des 2 versions proposées (8.2 i386, 8.2 AMD64) s'installe correctement.
Par contre, J'ai pu installer la dernière version Ubuntu 15.4 sans problème.
Pour aller plus loin avec Ubuntu, le problème est que l'équipe LinuxCNC a fait un grand nettoyage de toutes ses archives et qu'aujourd'hui il n'y a plus que la version Debian qui est proposée sur LinuxCNC.org. Avec Ubuntu c'est le désert total. Donc je suis bloqué.

Par chance, j'ai pu récupérer sur un autre PC un disque dur formaté avec Ubuntu lucid 10-04 + noyau linux 2.6.32-122-rtai + LinuxCNC 2.5 et là bingo !!!
Coup de bol, ma config PC (Carte mère Gigabyte GA K8-NF9 ultra, Processeur AMD Athlon(tm) 64 3500+, 1Go de mémoire, carte graphique Nvidia Geforce 6600 GT) va très bien avec cette version LinuxCNC.

Je ne sais toujours pas ce qui cloche avec Debian, mais j'aurais bientot l'occasion de l'essayer avec d'autres cartes graphiques PCI Express.

Je vais enfin pouvoir vérifier ce que m'apporte LinuxCNC avec l'exploitation des phases du codeur.

PS : pour mes essais j'utilise une clé USB et rufus 2.6 pour copier l'image ISO

Carlos

 

[bipbip30]

bonjour carlos78,

ça c'est une bonne nouvelle même si le problème lié à Debian est incompréhensible et inquiétant.

ouah moins de 3000 ns, encore un petit effort et il fera des trucs avant que tu lui demande

 

[gaston48]

Bonjour,
Je confirme bien que le dernier microcode amd64 proposé dans debian n'est pas compatible avec les
anciennes cpu family 15. Si on fait $ less /proc/cpuinfo, il n'y a pas de ligne info microcode.
En revanche, il faudrait peut être mettre à jour ton Bios, ce que j'ai fait sur ma carte mère.

 

[bipbip30]

bonjour gaston48, tu n'aurais pas par hasard conservé une image iso de linuxcnc 2.5 ?

 

[carlos78]

@gaston48 : merci d'avoir regardé le problème. Il y a donc bien un problème de microcode.
J'ai effectivement la version bios F5 d'origine et j'ai bien vu sur le site Gigabyte qu'il y avait les versions F6 et F7B mais ça me fait un peu peur de flasher un bios car je ne l'est jamais fait.

@ Bipbip30 : 2ème coup de bol. J'ai retrouvé l'image iso utilisée. C'est l'image ubuntu-10.04-linuxcnc3-i386.iso
Je l'ai installée sur un 2ème disque dur et elle fonctionne parfaitement
Sa taille est d'environ 700Mo et je suis en train de la mettre en ligne sur dl.free.fr
C'est la 1ère fois que j'héberge un gros fichier. Si tout se passe bien je te donnerais le lien

 

[gaston48]

Je dois nécessairement avoir l'ancienne version quelque part mézou ?
mais entre temps j'avais graver celle-ci:
http://linuxcnc.org/iso/ubuntu-10.04-linuxcnc3-i386.iso
et l'installation live et les tests latency fonctionnent très bien (moins de 5000) sur
mon pc amd64, il me semble que j'avais fait une installation complète sans problème
avant de passer à debian.
En fait: ces 2 versions s'installent sans problèmes sur mon PC amd64 (bios à jour) malgré l'indice i386:
Debian Whezzy i386 RTAI
Ubuntu Lucid i386 RTAI

 

[gaston48]

Je précise que sous ubuntu lucid j'ai vérifié toujours avec $ less /proc/cpuinfo
et ubuntu n'installe pas non plus un microcode particulier.
Mise à jour du bios c'est très rapide et tu sauvegardes l'ancien de toute façon.
Jusqu'à maintenant je fais ça avec une disquette 3.5 sous une sorte de dos ?
me souviens plus ?

 

[carlos78]

Gaston48 : Tu as installé la même version que moi. Mon hébergement devient inutile grace a ton lien. Pour le bios, le PC n'a même plus de lecteur de disquette.
Comment fais-tu pour retrouver les anciennes versions sur Linuxcn.org ?

 

[gaston48]

avec google

http://linuxcnc.org/docs/2.5/html/common/Getting_EMC.html

J'ai rapidement regardé la doc de ta carte mère, tout est expliqué, tu as un backup du bios
qui est intégré et tu peux éventuellement mettre à jour sous Windows.
Sinon tu dois bien pouvoir récupérer un lecteur 31/2 et une disquette (il vaut mieux avoir ça sous la main quand on a encore de vieux pc). Tu formates la disquette bootable pour avoir un minimum de msdos, tu configures le clavier en azerty
(KEYB FR,,keyboard.sys dans autoexe.bat + keyboard.sys sur la disquette) et tu charges
l'utilitaire de flashage et le nouveau bios.
Je pense que ça vaut vraiment la peine de passer la plus vite possible à Debian car la 2.7.3
inclut le nouveau planificateur de trajectoire beaucoup plus rapide (le petit point faible / mach3).
Je préfère l'interface ubuntu par rapport à debian qui comporte des imperfections, c'est encore
un peu beta je trouve, on sent que "windows" n'est pas sa vocation. mais je préfère m’habituer le plus vite possible. C'est le coté microsoftisation, closed source, business pub, qui est reproché
à Ubuntu par les développeurs de linuxcnc .

 

[bipbip30]

bonsoir, merci à vous 2 donc j'ai essayé et ... et ... c'est pire bon le bios est un M2N-NM-0403 de 2007 et la carte mère une Asus M2N-NM.

 

[carlos78]

Je commence à paramétrer LinuxCNC sur mon tour dans la froidure de mon sous-sol.

L'approche est très différente de celle de Mach3 car la configuration se fait via un utilitaire Stepconfig indépendant de l'environnement AXIS de LinuxCNC.
Stepconfig est confortable dans son utilisation. Il crée automatiquement dans un répertoire tous les fichiers de configuration d'une machine ainsi que son lanceur LinuxCNC. Le hic est que très rapidement on s'aperçoit qu'il faut bricoler ces fichiers à la main pour aller plus loin dans le paramétrage. Dès lors Stepconfig est hors jeu car il ne voit pas les modifications apportées aux fichiers.

Je suis en train de paramétrer les fins de course et les origines machine de mon tour et j'ai rencontré comme beaucoup les messages d'erreur de jointure.

Dans mes 1ers essais ça ne marchait pas parce que d'une part je n'avais pas saisi la logique du système, et que d'autre part j'essayais de mettre les 2 limites et les origines des 2 axes sur une seule entrée.

Je n'avais pas percuté que l'emplacement origine n'est pas le zéro machine mais la position ou se place la machine après avoir terminé la procédure de prise d'origine. Lorsqu'on a compris et qu'on affecte un seul axe par pin ça marche beaucoup mieux.

Exemple sur mon axe Z :
Emplacement origine : 150
Course de la table : 0 à 300
Position du contact orogine machine : 295
Vitesse de recherche origine : 5
Dégagement contact origine : opposée
Concrètement, la machine se déplace vers Z positif à 5mm/s vers la droite jusqu'au switch de limite, initialise le Z à 295, puis revient en arrière en vitesse rapide jusqu'à Z150.
J'ai fait le test sur X (avec d'autres valeurs) sur la même pin et ça marche également.

Si je n'arrive pas à utiliser une seul pin pour 2 axes, je serai obligé d'affecter une pin par axe. Ce ne sera pas un problème car je ne compte pas utiliser la phase B du codeur. Les 100 pulses par tour de la phase A suffiront largement.

Pour info, l'option toutes limites et toutes origines existe pourtant dans le paramétrage des pins. A suivre

Carlos

 

[gaston48]

Si je n'arrive pas à utiliser une seul pin pour 2 axes

bonjour,
C'est impossible dans la logique de Linuxcnc car, toute action sur une quelconque des limites, produit
un signal d’erreur et un AM, sauf si, pour un axe seulement et un seul, un switch limite est temporairement
dédié (donc actionné) pendant la phase de homing.
Si une seule pin pour tous les axes, le fait de l'actionner pour un homing sur Z produira un signal d’erreur sur X
et réciproquement.
....A moins de rajouter une logique dans .hal pour neutraliser tout signal de limite
tant qu'il y a un des axes en homing...

edit: Oui cela fonctionne, il faut rajouter des lignes dans le config.hal et vérifier si tout est
conforme de config.ini.

 

[carlos78]

Bonjour,

Finalement, bien que cette option soit proposée dans Stepconf, je n'ai pas réussi à faire fonctionner l'option "toutes les limites et toutes les origines" sur une seule broche.

Le paramétrage manuel doit être assez compliqué et je trouve bizarre que stepconf propose une alternative de cablage qu'il ne sait pas faire fonctionner.
Pour le fun, j'ai essayé manuellement et en vain des variantes en utilisant des paramètres non utilisés par Stepconf qui me paraissent nécessaires.
Je me suis fait au passage une petite frayeur avec une prise d'origine en 2 axes simultanés, et j'ai presque failli réussir la manip en inversant la séquence Stepconf de la prise d'origine. L'axe X choisi comme 1er axe passe mais je bute toujours sur l'inversion de l'axe Z.

Sur une seule broche on peut cependant avoir facilement toutes les limites ce qui à mon avis est le plus important.

En désespoir de cause, J'ai modifié le cablage et affecté une broche (2 limites et une origine) à chaque axe.
Ca marche très bien :


Le paramétrage (1 broche = 1 axe) n'est pas compliqué.
--> On voit que dans le processus il n'y a que la limite positive de chaque axe qui est testée. C'est l'opérateur qui doit s'assurer de l'adéquation de la 2ème limite avec la machine et les limites logicielles.
--> Il faut impérativement inverser manuellement le séquençage des axes défini par Stepconf car il met Z en 1er axe ce qui est dangereux sur un tour à cause de la poupée mobile qui risque bien d'être sur la trajectoire.
--> D'une façon générale, je trouve que la config tour de LinuxCNC n'est pas optimisée car on se retrouve également avec un paramétrage G17 (plan XY) pour une machine configurée XZ donc en G18.

La prochaine étape sera l'affichage de la vitesse de rotation de la broche.

Carlos

 

[gaston48]

Bonjour,
stepconf et pncconf sont plutôt conçus comme des générateurs de canevas des fichiers de config.
afin d'aider à leurs compréhensions. C'est un choix dans la notion "d'ouverture" de Linuxcnc.
Un wizard ne peux jamais s'adapter à tous les cas de figure, ils monopoliseraient un temps précieux pour leurs
mise à jour. Il faut donc passer le plus vite possible à l'édition directe de fichiers .ini et .hal.
C'est dans l’état d'esprit de linux aussi, on reste maître de tout, mais cela suppose de s'investir dans les détails.
Concernant le G18, dans le fichier ini, rubrique [RS274NGC] paramètre: RS274NGC_STARTUP_GCODE tu peux changer tous les gcode installés par défauts à l'initialisation.

http://linuxcnc.org/docs/2.5/html/config/ini_config.html

Sur une seule broche, il faut que tu publies les fichiers ini et hal ici pour que je les modifie.

 

[carlos78]

Salut Gaston48,
J'ai bien pensé à publier les fichiers ini et hal pour avoir de l'aide. Je suis persuadé que la solution tout-en-un sur une broche existe et que j'en étais pas loin.
Dans mes essais j'ai juste bricolé le fichier ini et je constate que c'est insuffisant.
Le hic pour poursuivre maintenant les essais est que dans l'état, ceux-ci ne pourraient pas se faire sans un retour au cablage précédent.
Pour le moment, je préfère avancer sur l'optimisation du paramétrage de LinuxCNC quitte à revenir plus tard sur ce sujet.

J'ai vérifié avec le scope la présence de l'index et de la phase A du codeur. C'est rasssurant mais je veux maintenant voir à l'écran la vitesse de la broche.

Carlos.

 

[gaston48]

Voilà l'info plus précise concernant le G18
http://linuxcnc.org/docs/2.5/html/config/lathe_config.html

Pourquoi un retour au câblage précédent ? tu vas libérer une pin d'entrée, elle restera en attente.
ou être affectée à la voie B.
Ensuite concernant un affichage custom complémentaire, je ne pense pas qu'on puisse se passer
d'une édition directe dans le fichier.hal pour "brancher" cette afficheur dans le hardware virtuel.
Pour résumer:
Tu crées un fichier en .xml, dans le répertoire de ta machine, afin d'afficher un widget dans axis,
que tu appelleras par exemple: broche.xml.
Dans le fichier .ini il faut paramétrer la ligne d'instruction qui va charger le fichier broche.xml
dans la rubrique:
[DISPLAY]
PYVCP = broche.xml
Par exemple un bargraph tiré d'une exemple dans la doc, le widget: "Bar"
A ce stade, si tu lances linuxcnc /axis, le bargraph va apparaître, mais il n'est pas encore branché dans hal.
mais on y a déjà intégré un nom de variable que tu as choisi: "spindle-speed"

Voir la pièce jointe broche.xml [div=none][arrow][/arrow][/div]

Pour transformer cette variable en signal actif dans .hal principal, il faut passer par un fichier .hal secondaire
qui va être lu après le fichier.hal principal. Il est chargé grâce à, cette foi, une ligne présente dans la rubrique
[HAL]
POSTGUI_HALFILE = mon_axis.hal

(ici le mon_axis.txt à renommer en .hal)
Voir la pièce jointe mon_axis.txt [div=none][arrow][/arrow][/div][div=none][arrow][/arrow][/div][div=none][arrow][/arrow][/div][div=none][arrow][/arrow][/div][div=none][arrow][/arrow][/div][div=none][arrow][/arrow][/div][div=none][arrow][/arrow][/div]

hal dispose maintenant d'un signal "vitesse-broche" avec un format en flottant qu'il faudra
brancher avec la bonne correction en rpm sur la sortie encoder.0.velocity
du composant encoder: http://linuxcnc.org/docs/2.5/html/man/man9/encoder.9.html
qui doit être déjà chargé dans ton fichier hal principal.

Tu as un codeur de 100 Imp/tr on suppose que tu branches la voie B, ce qui nous fera 400 Imp/tr.
encoder.0.velocity nous donnera donc pour 1 tr/seconde : la valeur de 400 et il faudrait
afficher la valeur de 60 (tr/minute) donc multiplier 400 ou la sortie de encoder.0.velocity
par 0.15 (pas de division dans hal, que des multiplications et le calcul de l'inverse).

Donc pour tout brancher, il faut rentrer les lignes suivantes dans le fichier.hal principal.
(s'il y a déjà un mult2 chargé, il faudra rédiger autrement)

Voir la pièce jointe modi_hal.txt

 

[carlos78]

Salut Gaston48,

Merci pour ton aide.
Ce matin j'ai consulté les documentations LinuxCNC pour essayer de comprendre les explications.

Pour l'affichage de la vitesse de rotation de la broche j'ai crée 2 configurations différentes :

- la 1ère "tour_bl200_V3" est obtenue directement avec l'aide de stepconf.

[div=none][arrow][/arrow][/div]

--> je n'avais pas réussi la 1ère fois car il faut semble-t-il cliquer sur la case "display sample panel".

Cette configuration marche. On obtient ça :

[div=none][arrow][/arrow][/div]

- la 2ème "tour_bl200_V3 KO" est obtenue à partir de ce que j'ai compris. Elle ne fonctionne pas pour le moment.

Ci-joint un fichier avec les 2 versions et le fichier erreur de la version KO.
Voir la pièce jointe Archive.zip [div=none][arrow][/arrow][/div][div=none][arrow][/arrow][/div][div=none][arrow][/arrow][/div][div=none][arrow][/arrow][/div][div=none][arrow][/arrow][/div][div=none][arrow][/arrow][/div][div=none][arrow][/arrow][/div]

Carlos

 

[gaston48]

Bonjour Carlos
Pour la 2eme version,
encoder.0.velocity est deja branché à motion.spindle-speed-in pour le G96 avec
comme nom de signal: spindle-velocity.
Donc pour les lignes rajoutés, voilà la correction.

# net vitesse-codeur mult2.0.in1 <= encoder.0.velocity
net vitesse-codeur mult2.0.in1 <= spindle-velocity

Ensuite pour le calcul du rapport, voir l'influence de ce paramètre
setp encoder.0.position-scale 100.000000 mais ça ne doit jouer que
dans le cas d'un axe linéaire en mm

Sur ta première version l'ajustage du rapport est basé sur le composant scale
plus le passage dans un filtre passe-bas.
http://linuxcnc.org/docs/2.7/html/man/man9/scale.9.html
Moi j'ai choisi le composant mult2

Un autre détail mais qui n'a pas d'influence, dans custom_postgui.hal
inverser le flèche de ceci <= à cela => (l'afficheur de vitesse est un récepteur)

 

[carlos78]

Salut,

# net vitesse-codeur mult2.0.in1 <= encoder.0.velocity
net vitesse-codeur mult2.0.in1 <= spindle-velocity

erreur obtenue dans le fichier hal : "Pin ' spindle-velocity ' does not exist ".

 

[gaston48]

Bonjour,
Ah oui pardon, spindle-velocity est un signal maintenant, il n'a pas de Pin comme un composant
il doit être placé après net, donc la bonne ligne serait:

net spindle-velocity => mult2.0.in1

Un custompanel.xml avec la vitesse min= 0 et les couleurs paramétrées:
<pyvcp>
<label>
<text>"Vitesse de broche:"</text>
</label>
<bar>
<halpin>"spindle-speed"</halpin>
<min_>0</min_>
<max_>5000</max_>
<bgcolor>"grey"</bgcolor>
<fillcolor>"green"</fillcolor>
</bar>
</pyvcp>

Reste à récupérer une entrée du port// pour rentrer la voie B

 

[carlos78]

Salut Gaston48,

avec ta dernière modif, la 2ème solution avec mult2 marche mais la vitesse affichée n'est pas stable.
Elle s'affole en permanence : avec une vitesse théorique de 1950tr/mn, l'affichage donne 1800tr/mn, mais surtout on a une fluctuation incessante d'environ 200tr/mn.
La 1ère version avec un filtre pass-bas est plus stable. Elle affiche environ 1820 tr/mn avec une fluctuation de 2 à 3 tr/mn.

Carlos

 

[gaston48]

D'ou l'utilité du filtre passe-bas !

J'ai remarqué aussi ces fluctuations avec halmètre ou halscope sur un codeur de servo.
Ce qui m’inquiète un peu d'ailleurs car cela voudrait dire qu'on ne peut pas se servir
de cette info pour recréer un tachy initialement issue d'une petite dynamo.
Et pourtant il revendique un algorithme spécial avec très peu de bruit de quantification
par rapport une dérivée de la position.

Edit: ... finalement après vérification au scope, des pulses de codeur, cela semble bien être
des fluctuations de vitesse ! c'est étonnant de la part d'un servomoteur dont le rotor
a déjà une bonne inertie.

Il faut que tu règles, je pense, le paramètre d' encoder.N.position-scale pour tes filetages,
qui représente le nombre d'impulsions pour une avance de 1 mm de l'axe Z.

Pour ne pas avoir le fichier gcode emc à l'ouverture de linuxcnc, dans le fichier ini,
rubrique [DISPLAY] , tu rajoute la ligne: OPEN_FILE = 0

 

[carlos78]

1er filetage avec LinuxCNC : M26 x2.00
Comme j'ignorais totalement comment se comporterait le G76 version LinuxCNC, j'ai d'abord "gravé" le filetage sur quelques dizièmes de mm histoire de voir le résultat. J'ai relancé ensuite le même programme en modifiant uniquement la profondeur du filetage. Ceci explique pourquoi sur la video les 1ères passes n'enlèvent quasiment pas de matière.

Ici j'utilise uniquement la phase A et l'index du codeur. L
Le résultat est assez comparable à celui obtenu avec Mach3 qui n'utilise que l'index.

Carlos

 

[HURLUBERLU2]

Bonjour carlos78,

je viens de lire avec attention toute cette discussion un peu ancienne, certes, ainsi que les liens vers les conversions d'autres membres du forum. J'ai le même tour acimex bv200L, et je prévoie de le convertir CNC dans quelques temps.( en fait dès que j'aurais terminé la conversion cnc de ma fraiseuse, donc normalement milieu d'année prochaine)
vous proposez en page 3 les fichiers step de la CAO; êtes vous toujours ok pour les partager? dans quels logiciels ont-ils été créés( moi je suis en solidworks 2012 ).
concernant les pap, quels moteurs avez vous utilisé? nema 23,34? quel est leur puissance( ou réference )?
utilisez vous au final mach3 ou linuxcnc?

je pense que maintenant tout est fonctionnel depuis longtemps; quel est votre retour d'éxperience à l'utilisation depuis quelques années maintenant.

avez vous constaté des anomalies de fonctionnement?
cordialement.

 

[big bloc]

bonjour à tous , je n arrive pas à afficher la vitesse reelle , question ,peut-on mettre tout dans le HAL ? J utilise pour l'instant un simple capteur inductif, il s affiche dans le halscope mais rien dans axis , juste la vitesse en fonction du potar virtuel