[venom]

Bonjour à tous.

Ces palpitations donnent du fil a retordre dit donc






@++

[gwion]

Je pense que les arrêts inexpliqués du palpage quand on diminue la course Z sont justement provoqués par de fausses mesures.
C'est le même constat avec tous les logiciels, donc c'est lié au traitement par GRBL.

[paulfjujo]

bonjour,

Je pense que les arrêts inexpliqués du palpage quand on diminue la course Z sont justement provoqués par de fausses mesures.
C'est le même constat avec tous les logiciels, donc c'est lié au traitement par GRBL.

GRBL est un protocol de dialogue ..mais qui n'est pas excuté de la même maniere suivant :
le firmware GRBL implanté (et sa version) , dependant du processeur utilisé ATMEGA Arduino, ou ESP32 , ou Linux .....
et le Hardware correspondant.
version GRBL 1.1f ?
le parametrage complet CNC ...
le logiciel qui envoi les commandes GRBL (USG , bCNC, Candle , Flatcam, TS35 +Sdcard, linuxCNC, Yat terminal ....)
le driver NEMA TBxxxx qui interprete aussi les commandes
le logiciel qui genere les fichier Gerber à partir du dessin C.I.
le logiciel Flatcam pour le detourage des pistes
la tete qui est entre le clavier et la programmation

Bref, tout un tas d'acteurs dans ce scenario CNC ...
tres difficile de se prononcer sur une seule cause possible ....

vite, un aspro

[F6FCO]

dependant du processeur utilisé ATMEGA Arduino, ou ESP32 , ou Linux .....
le logiciel qui envoi les commandes GRBL (USG , bCNC, Candle , Flatcam, TS35 +Sdcard, linuxCNC, Yat terminal ....)

Pas LinuxCNC, il n'utilise pas GRBL et il gère lui-même l'envoi des impulsions TTL issues du gcode, soit via la DB25, soit par le GPIO du PI. Il remplace à lui tout seul le couple UGS+arduino (ou ESP32).
Comme je l'ai dit auparavant il n'a pas d'autolevel en natif mais il existe un plugin https://www.autoleveller.co.uk/downloads/ que j'ai utilisé pendant un temps et que j'avais abandonné parce qu'il n'était pas encore au point. Les versions ont évoluées depuis mais pas encore essayé.

le driver NEMA TBxxxx qui interprete aussi les commandes

Je ne pense pas, c'est pour vérifier cela que j'ai fait des essais en 1/16e de pas --> déplacements de 5 microns donc bien en dessous des erreurs relevées. Quand on arrive au toucher du PCB, 5microns au-dessus pas de contact, un pas de 5microns pour trouver le contact... et on a des erreurs de plusieurs centièmes ou dixièmes.... . Le problème n'est pas dans les déplacements des chariots.

le logiciel qui genere les fichier Gerber à partir du dessin C.I.
le logiciel Flatcam pour le detourage des pistes

Non plus car il n'entre pas en compte. Tu peux effectuer des palpages sans avoir chargé le gcode.

Une chose dont on n'a pas parlé c'est que ce n'est pas seulement le déplacement du chariot Z qui peut-être en cause, aussi le déplacement des chariots X et Y qui ne nous amènent pas vraiment au même point xyz à chaque suite de scans à la tolérance du micro-pas près. Même si je n'y crois pas trop vu qu'en 1/16e de pas comme dit plus haut c'est des déplacements de 5 microns, l'erreur est infime.
D'ailleurs mes nouveaux drivers permettent de faire du 1/32e de pas, je vais faire des essais dés que j'aurai réussi à faire entendre raison à mon arduino, ce qui donnera des déplacements de 2,5microns avec ma vis-mère au pas de 4mm/tour. Si l'erreur continue à être du domaine de plusieurs centièmes voir du dixième çà prouvera bien que c'est des erreurs de calcul dans GRBL. Il faudra vivre avec en attendant des versions ultérieures de GRBL.

la tete qui est entre le clavier et la programmation
vite, un aspro

Oui, et il faut arrêter de se

Depuis hier je me prend la tête avec le téléversement sur arduino, j'avais oublié ces joies . Mon GRBL s'est corrompu et j'essaie de téléverser de nouveau mais rien ne fonctionne correctement. Je n'arrive même pas à téléverser le BLINK, qu'elle misère ces arduinos.

avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0xe2

[gwion]

Pour l'Arduino le piège est d'avoir CURA lancé en même temps, emmerdements garantis.
Si ce n'est pas le cas, quand erreur de téléversement, voir le câble et un éventuel hub. Je sors justement d'en prendre avec les 2 cas. J'en utilise rarement, mais chaque fois c'est la misère.

Pour le palpage, même si l'on part du principe que le positionnement XY des points entre 2 séries ne soit pas rigoureusement identique, on va fatalement tomber très très près. A quelques centièmes de différence, il n'est pas possible d'avoir des écarts de mesure aussi importants.

A noter que ces écarts de mesure sont constatés sur diverses machines qui n'ont pas les mêmes contrôleurs.

[cyril13110]

Du coup si le palpages n'est pas bon dans grbl il va certainement falloir modifier les données de profondeur dans pcb to gcode pour tenter de ne pas plomber les pcb......
Tu en pense quoi jc?

[F6FCO]

Du coup si le palpages n'est pas bon dans grbl il va certainement falloir modifier les données de profondeur dans pcb to gcode pour tenter de ne pas plomber les pcb......
Tu en pense quoi jc?

Non, rien à changer dans PCB-GCODE, il n'est pas fautif sur ce coup-là, garde le tel quel.
J'en pense qu'on peut très bien se passer du palpage tant qu'il n'est pas fiable. Je vais revenir à la bonne vieille technique du toucher/papier.

A noter que ces écarts de mesure sont constatés sur diverses machines qui n'ont pas les mêmes contrôleurs.

Ce qui donne bien à penser que c'est GRBL le fautif.

Résolu pour le téléversement arduino, c'est W10 qui foutait la m**de. Tout s'est ensuite bien passé sur mon PC de programmation PIC qui est sous W7, prog FTDI et CH340 ok. Pourtant les drivers sont bien installés sous celui en W10, je le saurai pour la prochaine fois, perdre autant de temps pour çà, çà fout les boules. J'ai même rechargé tous les bootloaders
Du coup je me suis fait 4 NANO en rescue avec GRBL paramétré pour ma machine, je pourrai voir venir en cas de pépin, rien de plus énervant que la machine tombe en panne en plein projet. J'ai même réussi à installer GRBL avec une vieille IDE arduino 1.8.

-------------------------------------------------------------------------------------------

Ma fournée du jour en 1/32e de pas, déplacement de 2.5micron/pas dans mon cas.
Toujours le même process:
- Toucher probe initial et positionnement repos à 1mm au dessus du cuivre
- Surface palpée d'environ 3x4cm
- Séries de palpages consécutifs avec clear scan

Ca pourrait à la rigueur ne pas être si mal s'il n'y avait parfois des erreurs de carrément 9mm, vous imaginez les dégâts que çà pourrait causer .
A moins que je ne me gourre avec l'exposant E-4, et que çà ne fasse que 0.0009 ? j'ai l'esprit lent ce soir

EDIT: Après avoir relevé la tête du guidon, bu frais et l'esprit plus clair, oui c'est çà: 0.0009, donc pas si mal en 1/32e de pas finalement, on a diminué l'erreur.


scan1
1.0 15.0 0.013999999999995794
1.0 35.0 0.015999999999991132
1.0 45.0 -0.0020000000000024443
21.0 15.0 0.006999999999997897
21.0 35.0 -0.005000000000002558
21.0 45.0 -0.01300000000000523
35.0 15.0 0.024999999999991473
35.0 35.0 9.999999999976694E-4
35.0 45.0 -0.017000000000003013

scan2
1.0 15.0 0.011000000000002785
1.0 35.0 0.012000000000000455
1.0 45.0 0.0040000000000048885
21.0 15.0 0.01300000000000523
21.0 35.0 -0.001999999999995339
21.0 45.0 -0.009000000000000341
35.0 15.0 0.02400000000000091
35.0 35.0 0.0010000000000047748
35.0 45.0 -0.015999999999998238

scan3
1.0 15.0 0.010000000000005116
1.0 35.0 0.01300000000000523
1.0 45.0 0.006000000000000227
21.0 15.0 0.01300000000000523
21.0 35.0 0.0010000000000047748
21.0 45.0 -0.007999999999995566
35.0 15.0 0.026000000000003354
35.0 35.0 0.0030000000000001137
35.0 45.0 -0.013999999999995794

scan4
1.0 15.0 0.010000000000005116
1.0 35.0 0.011000000000002785
1.0 45.0 -0.0030000000000001137
21.0 15.0 0.005000000000002558
21.0 35.0 -0.007999999999995566
21.0 45.0 -0.016999999999995907
35.0 15.0 0.015000000000000568
35.0 35.0 -0.006999999999997897
35.0 45.0 -0.02400000000000091

scan5
1.0 15.0 0.0020000000000024443
1.0 35.0 -0.003999999999997783
1.0 45.0 -0.009000000000000341
21.0 15.0 -0.003999999999997783
21.0 35.0 -0.016999999999995907
21.0 45.0 -0.02499999999999858
35.0 15.0 0.008000000000002672
35.0 35.0 -0.012999999999998124
35.0 45.0 -0.028999999999996362

scan6
1.0 15.0 0.0030000000000001137
1.0 35.0 -9.999999999976694E-4
1.0 45.0 -0.006000000000000227
21.0 15.0 0.0
21.0 35.0 -0.013999999999995794
21.0 45.0 -0.02499999999999858
35.0 15.0 0.014000000000002899
35.0 35.0 -0.007999999999995566
35.0 45.0 -0.021000000000000796

scan7
1.0 15.0 -0.003999999999997783
1.0 35.0 -0.001999999999995339
1.0 45.0 -0.00999999999999801
21.0 15.0 -9.999999999976694E-4
21.0 35.0 -0.013999999999995794
21.0 45.0 -0.015000000000000568
35.0 15.0 0.01300000000000523
35.0 35.0 -0.015000000000000568
35.0 45.0 -0.03999999999999915

scan8
1.0 15.0 -0.006000000000000227
1.0 35.0 -0.003999999999997783
1.0 45.0 -0.01099999999999568
21.0 15.0 -0.003999999999997783
21.0 35.0 -0.018000000000000682
21.0 45.0 -0.02400000000000091
35.0 15.0 0.008000000000002672
35.0 35.0 -0.013999999999995794
35.0 45.0 -0.030999999999998806

scan9
1.0 15.0 -0.009000000000000341
1.0 35.0 -0.006000000000000227
1.0 45.0 -0.015999999999998238
21.0 15.0 -0.009000000000000341
21.0 35.0 -0.021999999999998465
21.0 45.0 -0.03900000000000148
35.0 15.0 0.008000000000002672
35.0 35.0 -0.018000000000000682
35.0 45.0 -0.03399999999999892

scan10
1.0 15.0 -0.012000000000000455
1.0 35.0 -0.00999999999999801
1.0 45.0 -0.016999999999995907
21.0 15.0 -0.016999999999995907
21.0 35.0 -0.027000000000001023
21.0 45.0 -0.036000000000001364
35.0 15.0-9.999999999976694E-4
35.0 35.0 -0.021999999999998465
35.0 45.0 -0.03999999999999915

[cyril13110]

Non, rien à changer dans PCB-GCODE, il n'est pas fautif sur ce coup-là, garde le tel quel.
J'en pense qu'on peut très bien se passer du palpage tant qu'il n'est pas fiable. Je vais revenir à la bonne vieille technique du toucher/papier.


Ce qui donne bien à penser que c'est GRBL le fautif.

bonjour JC et bonjour à tous,

La technique du toucher/papier c'etais ce que tu avait decrit il y a longtemps?
dedescendre la pointe sur la carte et si le papier bouge plus c'est que c'est bon et on fait le point 0 de Z?
C'est bien ca?

daccords en gros GRBL n'est pas si au point que ca alors..
C'est etànnant alors que ca se deplois de partout chez les bricoleurs, ca fait quelques annnée maintenant que ca existe....a moins que ca soit une fonction laissé à l'abandon pour les concepteurs comme ca se fait souvent....

De mon coté la semaine prochaine je vais au magazin de bricolage, je vais prendre une planche de MDF la plus epaisse que je trouve et je vais faire le surfacage de la table au complet et du martyre entre 2 cours.
et au pire je tente de graver la carte commande moteur avec les fraises chinoises pour voir ce que ca donne.

Les mesures que tu as ont de sacré ecards, comme le controleur perdait la mesures et delirait totalement de maniere aleatoire

A moins que je ne me gourre avec l'exposant E-4, et que çà ne fasse que 0.0009 ? j'ai l'esprit lent ce soir

Haaaaaaa bein oui JC E-4 ca fait bien 0.0009 du coup ca parrait plus coherant d'un coup allé va un bon repos ca va te faire du bien

[paulfjujo]

scan6
1.0 15.0 0.0030000000000001137
1.0 35.0 -9.999999999976694E-4
1.0 45.0 -0.006000000000000227

Là, il y a vraiment un probleme , car normalement on fixe des limites de palpage dans UGS
et une mesure hors norme devrait declencher une alarme message en rouge "PROBE" cligotant
avec UGS ..et arret du palpage ...

ex:

UGS_Autoleveller_Z_limites.jpg

j'ai pas fait gaffe au E-4
y a un bug ?

valeur avec exponentielle ?
pourquoi alors tous ces digits ?
ce GRBL sait-il gerer cette variation de mode de notation ?

[F6FCO]

La technique du toucher/papier c'etais ce que tu avait decrit il y a longtemps?
dedescendre la pointe sur la carte et si le papier bouge plus c'est que c'est bon et on fait le point 0 de Z?
C'est bien ca?

Oui c'est çà, çà fonctionne très bien, j'utilise le papier jaune du scotch double-face.

daccords en gros GRBL n'est pas si au point que ca alors..

Seulement l'autolevel, le reste semble pas mal, on en reparlera après plus d'expérience. Habitué à LinuxCNC je découvre comme vous.

C'est etànnant alors que ca se deplois de partout chez les bricoleurs, ca fait quelques annnée maintenant que ca existe....a moins que ca soit une fonction laissé à l'abandon pour les concepteurs comme ca se fait souvent....

Peut-être pas tant que çà, la grande majorité des bricoleurs usinent du bois avec leurs cnc, quelques centièmes ne les dérangent pas. Et la plupart peut-être pas aussi pointilleux que nous, combien ont fait des séries de palpages successifs et se doutent de la chose ? Et rappelle-toi la vidéo que tu avais postée ou le mec creusait son pcb après avoir expliqué comment faire un autolevel...
Ici on coupe les mouches en 4.

De mon coté la semaine prochaine je vais au magazin de bricolage, je vais prendre une planche de MDF la plus epaisse que je trouve et je vais faire le surfacage de la table au complet et du martyre entre 2 cours.

Pas trop épais quand même, la course Z de ta cnc en sera réduite d'autant, du 8mm est le bon compromis.

Là, il y a vraiment un probleme , car normalement on fixe des limites de palpage dans UGS
et une mesure hors norme devrait declencher une alarme message en rouge "PROBE" cligotant
avec UGS ..et arret du palpage ...

Il n'y a pas eu d'alarme, j'étais juste à coté et je surveillais, 9 palpages par autolevel çà va assez vite.

valeur avec exponentielle ?
pourquoi alors tous ces digits ?
ce GRBL sait-il gerer cette variation de mode de notation ?

Ben oui, je me suis fait surprendre aussi, LinuxCNC qui est aussi utilisé dans l'industrie n'utilise que 3 chiffres après la virgule, pareil avec MACH3 et c'est bien suffisant.
Sans compter qu'avec tous ces chiffres après la virgule çà doit prendre un temps de calcul fou, GRBL gagnerait certainement en vitesse d'éxécution s'ils réduisaient leurs variables, mais je suppose qu'ils y a une bonne raison à cela.
Quand je pense comme on se prend le chou en asm PIC pour faire des divisions 16bits
Avec tous ces chiffres inutiles c'est plus difficile à lire pour faire des comparaisons entre tableaux.
Mais finalement on a bien réduit l'erreur en 1/32e de pas. Tu confirmeras mais je crois me rappeler que vos vis-mères font 2mm/tour, si c'est le cas vous devriez obtenir le même résultat en 1/16e de pas.

EDIT: il va falloir que je me calme sur la longueur de mes posts