Sonde tactile 3D

  • Auteur de la discussion Auteur de la discussion Bobismiles
  • Date de début Date de début
Au sujet de l'erreur qui se produit du fait que la valeur n'est exploitable qu'une fois l'axe arrêté, ça reste gérable à condition de palper à faible vitesse. La valeur de l'erreur dépend à la fois de la V de palpage et de la valeur d'accélération.

Pour info, avec une vitesse de palpage de 100 mm/min et une accélération réglée à 400 mm/s² , l'erreur est de 0.0035mm ... (décélération en 0.0042s)

Pour une même vitesse de palpage, plus l'accélération/freinage est importante, plus l'erreur est faible.

++
David
 
Il va te falloir te faire toutes les macros ... il y a du job ;

Oo shit, ralala ces cartes chinoises... si j'avais su j'aurai pris autre chose !

Merci pour tes lumières, je vais tester ca sur une comme tu me le conseilles


Ah je vais inverser ! je te dis si ca marche

Je vais regarder le post de Gerry.

Merci à tous les deux
 
Dernière édition:
Bon j'ai testé sur la macro M905 et ca marche ! Je vais être bon pour toutes les modifier

Lorsque je palpe, j'obtiens les coordonnées dans l'encadré "résult", c'est top !



Par contre quand je quitte l'addon et que je palpe la longueur d'outil en Z, ca ne marche plus Je dois entendre le relais qui claque quand je clique pour activer l'addon (ce que j'entends) et lorsque je le quitte aussi ?
@Squal112 est-ce qu'il faudrait éditer la macro exit quand je quitte l'addon avec une désactivation de la sortie ?

edit : lorsque j'active l'addon, j'ai la valeur du feed rate à 10000, ce qui est bien trop par rapport aux recommandations de l'auteur de l'addon et de @dh42 :


Je change cette valeur mais à chaque relance de l'addon elle se réinitialise à 10000.
Est-ce que je peux modifier cette valeur définitivement ? plutôt que de la changer à chaque fois ? C'est un coup a oublier de la changer
 
Dernière édition:
Oui normalement le bouton Quit désactive la sortie 3 car il est associé au code suivant :
Comme écrit plus haut, est-tu certain de ton cablage des palpeurs ?
Le Z outil sur la sortie NF du relais et le palpeur 3D sur la sortie NO.

Je change cette valeur mais à chaque relance de l'addon elle se réinitialise à 10000.
Est-ce que je peux modifier cette valeur définitivement ? plutôt que de la changer à chaque fois ? C'est un coup a oublier de la changer
C'est l'avance de travail (feedrate) qui est utilisée, donc soit tu l'a modifie manuellement avant de lancer l'assistant de palpage, soit tu insère une commande dans la macro du bouton :
! ATTENTION ! la variable FeedRate est en unités par secondes (soit mm/s), donc pour 300mm/min => 5mm/s
 
Pour les branchements, j'ai inversé comme tu m'avais conseillé lors de ton dernier message.


Le jaune va au palpeur 3d et le marron au palpeur longueur d'outil.

En fait je viens de m'apercevoir que je désactivé la sortie OUTPUT4... C'est bon c'est réglé avec le 3 et ca claque bien à chaque fois !

Mais maintenant lorsque je lance le palpeur 3D j'ai de nouveau le message diabolique :



J'ai vérifié, la macro est toujours la même que tout à l'heure et qui a fonctionné. J'y comprends rien. J'ai juste changé le sens des câbles (qui a résolu le claquement du relais) et l'output de la macro exit et plus rien ne marche
 
Message qui apparait quand tu lances l'assistant ? ou quand tu as lancé une commande de palpage (M905 par ex) ?
 
Dès que tu lances la commande, avant que ça commence à bouger ?

Le "tripped" veut dire "déclenché" ce qui pourrait signifier qu'un contact a été activé ou qu'une fausse détection a eu lieu, dans ce cas il faudrait vérifier la logique et le paramétrage en fonction du choix NC/NO.
 
Hello ! @pascalp
Je lance la commande, la tête amorce le palpage en se décalant sur la gauche puis descend et ça bloque.

Ce qui est étonnant c'est qu'avant ça marché et depuis que j'ai inversé les câbles du relais ça bug. Ma pauvre expérience en électronique ne m'aide pas des masses.

Edit: je viens de voir un post d'une personne qui a aussi des bugs avec le palpage sur une carte chinoise WIHXC.
Son dernier message est porteur d'espoir, il semblerait que le driver de la carte ait connu une Maj. Maj qui est mal référencée sur le site du fabriquant, et il faut farfouiller pour la trouver. La nouvelle version et celle que je dois avoir sur ma carte (je verifierai demain).

Un apercu de la relase note :


Je verrai demain ce que ca donne croisez les doigts !
 
Dernière édition:
Non en fait j'avais déjà la dernière version du driver.... faux espoir

J'ai retenté mais tjrs l'erreur.
C'est étrange que ca ait marché un moment et que la plus rien ne fonctionne.
 
C'est vraiment bizarre, mais difficile de comprendre exactement ce qui se passe sans pouvoir tester en vrai, de plus le programmeur n'a mis aucun commentaire dans son code, donc on ne sait pas exactement ce qu'il fait.

Sur la macro M905 par exemple:

On voit qu'il fait un test qui appel une sous-routine qui teste la position (SafeMoveXY et SafeMoveZ) et qui renvoi les messages d'erreur que tu as:


Les routines SafeMove.. sont les suivantes:


Le test en lui-même est ici


Abs(XHit - Xstart - X1) doit être inférieur à 0.01 .... mais à quoi cela correspond exactement, mystère !!! (Abs = valeur absolue)

Il y a le même test pour SafeMoveZ, avec la même tolérance de 0.01 sur la position en cours .. mais ça peut être 0.01mm ou 0.01" suivant l'unité choisie .. et si le programmeur est Américain, il y a des chances que ce soit des pouces ... essais de remplacer tous les 0.01 par 0.25 dans les 2 fonctions SafeMoveXY et SafeMoveZ. (fait une recherche avec 0.01 car il y en a plusieurs, y compris dans d'autre fonctions, comme les ProbeX et Y)

... c'est juste une idée, ça ne marchera peut être pas mieux, mais c'est possible que ce soit simplement une tolérance trop faible sur le positionnement de départ quand exprimée en mm .... mystère.

C'est le problème de bosser avec du code écrit par quelqu'un d'autre, pas facile de suivre sa pensée et de savoir ce qu'il teste exactement.

++
David
 
Merci pour ton retour.
Je vais tester de modifier les valeurs et croiser les doigts ^^
Quelle merde quand même

Je te tiens au jus demain après les tests !
Bonne soirée
 
Tu peux peut être aussi essayer de comprendre ce qui se passe en obtenant les valeurs des paramètres qui sont utilisés dans le test de la fonction SafeMoveXY

If (Abs(XHit - Xstart - X1) > 0.01) or (Abs(YHit - Ystart - Y1) > 0.01) Then .....
....

ce qui veux dire, en français:

Si la valeur absolue de XHit-Xstart-X1 et supérieure à 0.01 OU si la valeur absolue de YHit-Ystart-Y1 et supérieure à 0.01 alors on ne peut pas se déplacer en sécurité > message d'erreur.

apparemment le programmeur l'avais déjà prévu (lui aussi il a dut avoir quelques problèmes LOL) car il y ces 4 lignes qui sont mises en commentaire (le ' en début de ligne) donc désactivées juste avant que le test ne soit lancé et qui sont cencées afficher les valeurs en cours des variables.


La première affiche les valeurs de XHit, Xstart, X1 et Ftmp (ftmp=vitesse d'avance)
La 2ieme affiche les résultat du calcul qui sera utilié dans le test, à savoir XHit - Xstart - X1, celui qui ne doit par êtrte supérieur à 0.01 (ou -0.01)

Les 2 lignes suivantes font la même chose pour Y

Suivant l'écart que donnera le résultat de la soustraction XHit - Xstart - X1 et son équivalent en Y, on pourra se faire une idée de si le problème est liée à une tolérance trop faible (faible écart dans la soustraction), ou si les valeurs sont complètement dans les choux.(écart important) et que le problème est à chercher ailleur.

Pour réactiver ces lignes, enleve le ' en début de ligne et remplace le texte PushMSG par MsgBox, sans rien changer au reste ; ça t'ouvrira une fenetre avec les valeurs en question.

si ensuite tu veux les désactiver, remet simplement un ' en début de chaque ligne.

++
David
 
Comme l'a très bien fait David, si on décripte un peu la macro on se rend compte qu'il y a plusieurs causes possibles à ce message d'erreur.
La macro commence par mémoriser la position Z de départ (Zstart = GetDRO(2)
Puis passe en mode incrémental G91
Lance le palpage "G31 Z" & Z1
Récupère la position d'arrêt dans la variable système ZHit = GetVar(2002)

L'erreur apparait si ZHit ≠ Zstart + Z1 soit quant la sonde se déclenche avant la fin du mouvement prévu.
Ainsi les causes possibles sont :
- Sonde déjà active au départ (si contact fermé avant le G31)
- Parasites electriques/faux contact (masse commune mal faite, cable non blindé, ainsi la sonde déclenche quelques millisecondes)
- Contact réel plus tôt que prévu (mais c'est le fonctionnement voulu)
- Mauvaise gestion du mode absolu/incrémental (pas de retour en G90 dans la fonction, a voir si en ajoutant une ligne ça peut aider)
- Erreur de signe sur Z1 (Z1 et positif alors qu'on descends ou inversement, la comparaison sera fausse)
- Mauvais timing / buffer Mach3 (Mach3 peut parfois encore être en trian de bufferiser la commande, voir pour augmenter le Sleep(125) à 250)

Les lignes de codes avec l'apostrophe, sont effectivement la pour du debug et on peut leur associer les lignes suivantes pour aller plus loin :

Mais en réalité il faudrait juste corriger la ligne suivante :
If Abs(ZHit - Zstart - Z1) < 0.01 Then
Par
If Abs(ZHit - Zstart - Z1) > 0.1 Then
 
Merci à tous les deux pour vos réponses.

Je viens de tester le remplacement
If Abs(ZHit - Zstart - Z1) < 0.01 Then
Par
If Abs(ZHit - Zstart - Z1) > 0.1 Then
et toujours la même erreur de "Probe tripped during Z movement".

apparemment le programmeur l'avais déjà prévu (lui aussi il a dut avoir quelques problèmes LOL)
haha c'est rassurant :p
essais de remplacer tous les 0.01 par 0.25 dans les 2 fonctions SafeMoveXY et SafeMoveZ. (fait une recherche avec 0.01 car il y en a plusieurs, y compris dans d'autre fonctions, comme les ProbeX et Y)
J'ai modifié ces paramètres et ca fonctionne !

MAIS chose très étrange, lorsque je modifie dans les paramètres de l'addon la "Profondeur de recherche" du palpeur je n'ai pas d'erreur quand je suis en dessous de 2.5mm et si je mets 3mm ou plus je retrouve l'erreur du "probe tripped". (dernier paramètre du tableau ci dessous).



Alors est-ce que c'est vraiment la modif de David qui a marché ? ou depuis le début, cela provient de cette valeur que j'avais mis à 3 comme indiqué par le créateur du plugin et qui provoque l'erreur ?
C'est quand même bizarre mais ca expliquerait pourquoi d'un jour a l'autre ca marche ou pas car je change les paramètres pour tester. Des que je passe >2,5mm ca plante. Est-ce que tout ne viendrait pas de là tout simplement ?

Je vais renter et voir ce que ca donne, et peut être remettre à zéro la macro ? Bon ca plante quand je remets la macro d'origine. Tjrs la même erreur je repasse avec la macro custom.

La joie fut de courte durée, maintenant quand je me mets en jog mode avec des pas de 1mm, il n'y a plus que la direction X- et Y- qui fonctionnent et dès que je repasse en mode continu le déplacement fonctionne sur tous les axes. C'est à n'y rien comprendre. et ca replante. Je suis deeeeg. Ca palpe en X, puis ca se décale pour aller en Y et au moment de plonger paf ca plante. Je n'ai plus l'erreur du Z tripped mais maintenant c'est XY tripped...

Je me demande si remplacer la carte chinoise par un truc qui tient mieux la route, ne serait pas plus simple ? Là c'est un coup à la dégommer
Est-ce qu'il y a une ref sérieuse qui existe et qui me permettrait d'être tranquille pour la suite si je veux un peu bidouiller la CN ? et est-ce compliqué a configurer ?

Parce que la je ne vois pas quoi faire de plus.
 
Je me demande si remplacer la carte chinoise par un truc qui tient mieux la route, ne serait pas plus simple ?

Rien ne permet d'affirmer que le problème viens bien de la carte, même si des incompatibilités avec le palpage sont connues:

1) la non gestion des variables GetVar() qui oblige à lire la valeur dans la DRO

2) le non fonctionnement de la limite de palpage donnée. Si par exemple tu écris un G31 Z-3, la recherche doit se faire jusqu'à ce que l'on ai atteint Z = -3 ou que l'on ai déclenché le contact. Si l'on atteint la limite sans avoir touché le contact, le palpage doit s’arrêter ; avec les cartes Chinoises, ça ne semble pas fonctionner, le palpage continu indéfiniment.

3) la sortie de données ne fonctionne pas, donc impossible de se servir du palpage pour faire de la numérisation.

Il faudrait que tu trouves quelqu’un qui utilise cet addon avec une autre carte (non Chinoise) pour voir si ça fonctionne ...

Tu as tenté de poser la question sur son GitLab .. ?

Es tu bien sur que ce n'est pas ta bidouille pour utiliser à la fois un palpeur et la sonde 3D qui fout la m***


Sinon, autre option radicale, changes de carte et de soft, par exemple pour une carte AXBB-E et le soft UCCNC

UCCNC permet de gérer 2 palpeurs indépendants et il intègre des outils de palpage complets.

La carte AXBB-E fonctionne aussi bien avec Mach3 qu'avec UCCNC, donc tu peut même choisir le soft que tu utilise en fonction des besoins, ou de ton humeur !

UCCNC peux lire une config Mach3, donc assez rapide à configurer en important ton .xml de config machine.

carte seule

avec la licence UCCNC en plus

Ça fait donc le soft à 50€ HT ...







++
David
 
Dernière édition:
J'utilise cet addon, avec mon VERS PR sur une carte ESS + MB3 sans problèmes.
Et surtout j'utilise cela à travers un relais pour sélectionner palpeur outil (fixe sur table) ou palpeur 3D.

Le relais si câblé et utiliser correctement ne fait rien de plus que de permettre l'utilisation de l'un ou l'autre palpeur a la manière d'un aiguillage.
 
J'utilise cet addon, avec mon VERS PR sur une carte ESS + MB3 sans problèmes.

Ok, donc les macros son bonnes ...

@Bobismiles .. peux tu mettre ta macro M905 modifiée en PJ, que je regarde si tu n'as pas oublié une des modifs spécifiques pour la XHC ?

Sinon autre option, faire des macros plus simples qui te permettent simplement de palper en X- X+ Y- Y+ de manière indépendante. Dans les macros de l'addon, 80% du code ne sert qu'à savoir si il n'y a pas de risque de collision avec la pièce quand ça passe du palpage X au palpage Y , d’où l'usine à gaz .. et c'est ça qui coince. En palpant séparément X et Y et donc en repositionnant manuellement ton palpeur 3D du X au Y ça éviterait d'avoir tout ces tests ....

Les macros pourraient être intégrées aux boutons déjà existant de cet écran si tu ne veux pas créer des boutons perso.



Ou tu peux faire des boutons spécifiques avec MachScreen comme l'a fait Zarkann


L'avantage de faire ses propre macros, c'est que tu sais exactement comment ça marche LOL.

++
David
 
Dernière édition:
Hello, je passe en coup de vent, je regarde bien vos messages ce soir, mais voici la macro en PJ.

A tte !
 

Fichiers joints

Je n'arrive pas à la décompresser, tu peux la compresser avec Windows plutôt qu'avec 7zip ...

++
David
 
En Zip cela te va ?
Je n'arrive pas a uploader un .7z, l'extension n'est pas acceptée par le forum.
 

Fichiers joints

Re

Je n'arrive pas a uploader un .7z, l'extension n'est pas acceptée par le forum.

Ok, en fait c'est pas le format (.zip ou .rar) qui pose problème mais le soft utilisé pour faire la compression
la c'est OK, j'ai pu le décompresser

C'est bien la macro que tu utilises ???

On a dut mal se comprendre, tu as oublié de remplacer plein de GetVar !!! (10 en tout) et même les changements de résolution de 0.01 à 0.25 ne sont fait qu'a un seul endroit.


je t'ai corrigé le fichier, j'ai remplacé tous les GetVar(), mais par contre j'ai laissé la résolution à 0.01 car de toute façon ça ne pouvait pas marcher !

dans le test If (Abs(XHit - Xstart - X1) > 0.01) or (Abs(YHit - Ystart - Y1) > 0.01) Then .....
on utilise les variables XHit et YHit, or dans le début du code on a (ligne 104): XHit = GetVar(2000) ... donc vu que le GetVar ne marche pas avec les cartes chinoises, GetVar(2000) vaut toujours 0 et donc Xhit aussi .. alors qu'il devrait contenir la coordonnée du point de contact ... et c'est pareil pour YHit à la ligne 319 ...

essais avec cette nouvelle version

++
David
 

Fichiers joints

J'ai quelques vagues souvenirs concernant de problèmes de ce script avec certaines cartes. Primo, les GetVar 2000 et 2001 peuvent être imprécis et GetOEMDRO est recommandé à leur place. Secundo, certaines cartes ont du mal avec l'interpolation G31 Xn Yn et il faut séparer les deux en G31 Xn puis G31 Yn.

Je suis actuellement en vadrouille, et je ne retrouve pas le lien. Mais ça donne peut-être des pistes pour avancer ou retrouver le site qui en parle en détail.

@+
 
Bonjour à tous,

J'ai testé avec la macro modifié de @dh42. Quand je lance la macro sur ma pièce "test", ca fonctionne . Je peux enchainer la macro et tout roule.

MAIS, chose plus étonnante, lorsque je veux palper ma "vraie pièce" qui se situe environ 50mm plus bas que ma pièce test j'ai bien le palpeur qui se déplace en X- puis il plonge et s'arrête; plus rien ne se passe sur la CNC mais sur l'écran de l'addon j'ai la visu du X qui continue à avancer puis paf message d'erreur comme quoi il n'y a pas eu de contact en X.

Si dans la foulée je remonte palper ma pièce test (sans quitter l'addon) tout fonctionne bien.
Dés que je redescend palper ma pièce ca bug, le palpeur s'arrête et la visu mach3 continue d'avancer jusqu'à indiquer l'erreur de contact.

Mystère, pourquoi la différence de hauteur du Z influence sur la macro ?

Bon et maintenant ça plante même en haut. Raaaaaah !! J'ai l'impression que ce n'est pas stable.

@dh42: merci pour le fichier, effectivement j'ai bugué de mon coté, sorry.

@sans : Hello, merci pour ton retour, je vais creuser voir si je retrouve le lien, peut être une nouvelle piste
Sinon, autre option radicale, changes de carte et de soft, par exemple pour une carte AXBB-E et le soft UCCNC
Oui c'est radical mais peut être le plus simple que galérer à chaque fois que j'essaie d'upgrader la CN...

Oui pas bête, en plus je vais tout le temps palper le même angle. Si ca peut être une solution provisoire avant que je craque pour changer la carte ^^
Donc il faudrait que je modifie le code des deux boutons :


Quel code faudrait-il ? Est-ce que ca pourrait faire l'affaire ? :
(--- PALPAGE BORD BRUT EN X+ ---)
(--- Palpeur diamètre 2 mm ---)

#100 = 50 (distance max de recherche en mm)
#101 = 100 (vitesse de palpage mm/min)
#102 = 1 (rayon palpeur = 1 mm)

G21 (unités en mm)
G90 (positionnement absolu)

(Approche palpage)
G31 X#100 F#101

(Enregistrer position contact)
#103 = #2000

(Recul de sécurité)
G0 X[#103 - 5]

(Calcul du zéro pièce avec rayon du palpeur)
#104 = [#103 - #102]

(Définir le zéro X)
G92 X#102

(Se positionner sur le zéro pièce)
G0 X0

(--- FIN PALPAGE ---)
Code avec l'aide de l'IA et du guide mach3. On va voir si vous validez

Merci à tous et bonne aprem !
 
(Enregistrer position contact)
#103 = #2000

Ça par contre ça ne marchera pas, lire #2000 c'est comme un GetVar(2000) donc variable pas à jour du fait de la carte Chinoise.

Remplace par: #103 = GetOemDro(2000)

(Définir le zéro X)
G92 X#102

La j'ai un gros doute, #102 est censé contenir la valeur du rayon du palpeur, je pense que ce devrait plutôt être: G92 X#104

(Se positionner sur le zéro pièce)
G0 X0

Si tu retournes au Z=0 sans relever le Z, alors tu va rentrer dans la pièce de la valeur du rayon du palpeur ...

Il manque aussi l'attente de la fin du mouvement juste après le G31, ajoutes:

While IsMoving()
Wend

++
David
 
Le code corrigé :

(--- PALPAGE BORD BRUT EN X+ ---)
(--- Palpeur diamètre 2 mm → rayon = 1 mm ---)

#100 = 50 (distance max de palpage en mm)
#101 = 100 (vitesse de palpage mm/min)
#102 = 1 (rayon palpeur en mm)
#105 = 5 (recul de sécurité après contact)

G21 (unités en mm)
G90 (mode absolu)

(--- Approche palpage vers X+ ---)
G31 X#100 F#101
While IsMoving()
Wend

(--- Enregistrer position contact avec GetOEMDRO ---)
#103 = GetOEMDRO(2000)

(--- Calcul du zéro pièce avec compensation du rayon du palpeur ---)
#104 = [#103 - #102]

(--- Définir le zéro X ---)
G92 X#104

(--- Recul de sécurité pour dégager la pièce ---)
G0 X[#104 - #105]

(--- Palpage terminé, machine en sécurité ---)

Est-ce que ca va mieux ?

Je ne sais pas ce que ca vaut, mais Chatgpt me dit :


Est-ce un conseil judicieux de sa part ou il est a coté de la plaque ?
 
Oui, désolé, c'est bien GetOemDro(800) et pas 2000 ... oups !!

Maintenant il ne reste plus qu'à tester en vrai ... utilise un bloc de mousse au cas ou il y aurait un rentre dedans.

Par contre je ne suis pas convaincu par le G92 X#104 .... le G92 n'est pas persistant, le 0 ne sera valable que temporairement. (l'ancien 0 sera de retour dès la rencontre d'un M30)

remplace le plutôt par un:

SetOEMDRO(800,#104)

Qui écrit directement la valeur dans la DRO ... et qui reste persistent.

++
David
 
Je vais ressortir mon palpeur et ajouter les quelques fils qui manquent pour venir "jouer" avec vous.


Je me demande si la carte "mach3" pour cnc-3018 serait capable de la gérer correctement. Ce qui sans être une plaisanterie serait une bonne surprise.
 
Bien venu dans la partie LOL !!!

C'est quoi comme carte ? ... il y a de très fortes chances que le problème avec les GetVar soit le même ...

++
David
 
Re

Un autre problème rencontré (parfois) sur les XHC, c'est la pertes des coordonnées d'un programme à un autre (GCode) ... exemple après un palpage, le Z est mis à 0, ça marche sur un programme .. et quand tu relances une 2ieme fois le programme, le 0 est perdu. C'est arrivé sur une version USB ; après remplacement de la XHC USB par sa version Ethernet, le problème semble avoir disparu .. en tout cas le gars n'a pas redonné de nouvelles, donc ça doit marcher ... ou il a pété les plombs !!

C'est sur ce long sujet:

++
David
 

Sujets similaires

Réponses
4
Affichages
496
Youry
Y
J
Réponses
3
Affichages
231
D
B
Réponses
1
Affichages
737
laboureau
B
Réponses
18
Affichages
685
Benjypel
B
P
Réponses
65
Affichages
2 916
pat du80
P
M
Réponses
6
Affichages
460
Mathand
M
R
Réponses
16
Affichages
1 227
CLRAO
C
V
Réponses
13
Affichages
429
vibram
V

Sujets similaires