V
vres
Compagnon
Tu peux me faire une copie d'écran pour m'expliquer ?
j aies fouillé dans mon stock mais me reste qu une arduno mega , ca fonctionne ?
- j aies installé sur virtual box, nickel , mais je ne trouve pas la version plasma , or’j Aies vu un daily motion qui gérait un plasma avec thc
Merci
Pour info MultiCN n'arrive pas à la piloter, des messages très réquents "Machine ne répond plus" apparaissent et empêchent d'utiliser MultiCN.
Autre question, sur GRBLControl et pas mal d'autres logiciels aussi maintenant, ils mettent un genre d'auto level qu'ils appellent heightmap. Pour les PCB, sur plaque de cuivre pas toujours planes, c'est super.
Il n'y aurait moyen de faire un script ou autre pour avoir cela sur MultiCN ?
Autre question, sur GRBLControl et pas mal d'autres logiciels aussi maintenant, ils mettent un genre d'auto level qu'ils appellent heightmap. Pour les PCB, sur plaque de cuivre pas toujours planes, c'est super.
Il n'y aurait moyen de faire un script ou autre pour avoir cela sur MultiCN ?
Pour fonctionner à une vitesse correcte le port série est configuré a 115200 baud, ça passe peut-être mal avec ta carte
La connexions se fait, puis il il y a" la machine ne répond plus" ? On peut trouver cette carte facilement
heu là je retourne ??
Oui c'est une séquence de palpage paramétrable en abscisses et ordonnées afin de contrôler les écarts sur le Z. Après leur truc je ne sais pas comment ça marche, ils somment et font une correction du GCode apparemment. Bon y a pas mort d'homme non plus, les écarts se comptent en dixième, pas sûr que ce genre de machine est une précision au dixième non plus . Nan là je déconne, sinon j'essaie même pas le PCB dessus.MultiCN est capable de corriger une trajectoire en fonction d'un repérage caméra ou de faire de la THC sans boitier bizarre, donc je pense que c'est possible. Ça fonctionne avec un palpage ?
Mais je comprend ça très bien, c'était juste une question. Savoir si un utilisateur pouvait songer à cela avec du script par exemple. Ce n'était pas une demande à ta destination, tu en fais déjà beaucoup je trouve.Après c'est une version Demo et je n'ai pas beaucoup de temps disponible pour faire ce développement.
Avec MultiCN il n'y a rien d'écrit sur l'EEprom à part le logiciel.Mais il faut que je vérifie des choses, après avoir "Xloadé" le sketch MultiCN, puis rebelotte avec GRBL1.1, je me suis rendu compte que mes paramètres EEprom étaient les mêmes.
Mais je comprend ça très bien, c'était juste une question. Savoir si un utilisateur pouvait songer à cela avec du script par exemple. Ce n'était pas une demande à ta destination, tu en fais déjà beaucoup je trouve.
Avec MultiCN il n'y a rien d'écrit sur l'EEprom à part le logiciel.
Ce n'est pas fait en temps réel, les palpages se font avant de lancer l'usinage. D'ailleurs cela bloque tout autres interactions sur le logiciel, y compris le jog. C'est après la réalisation du heightmap qu'on peut vaider l'usage de celui-ci. Alors seulement les correctifs sont appliqués dans le GCode avant de lancer l'usinage.Pour faire une correction de trajectoire en temps réel
Wowww, merciJe vais quand même réfléchir a cette fonction dans les scripts, ça peut-être intéressant et pas trop compliqué.
Pour le palpage effectivement il vaut mieux le faire avant et c'est assez facile de le faire directement dans un script. Pour la correction pendant l'usinage, c'est plus simple a faire en temps réel.Ce n'est pas fait en temps réel, les palpages se font avant de lancer l'usinage. D'ailleurs cela bloque tout autres interactions sur le logiciel, y compris le jog. C'est après la réalisation du heightmap qu'on peut vaider l'usage de celui-ci. Alors seulement les correctifs sont appliqués dans le GCode avant de lancer l'usinage.
C'est pourquoi j'avais penser à du script pour le faire
Non pas du tout, si grbl vois arriver mes trames il doit être un peu perduJe pensais que c'est probablement pour ça que MultiCN n'arrivait pas à avoir une com. stable.
Je soupçonne fort que sans le sketch sur la carte arduino il a de sérieux soucis pour dialoguer avec, non ? Mais peut-être je me trompe.
Tu as peut-être raison, mais cela n'explique pas que MultiCN n'arrivait pas à avoir une com. stable si l'hex a bien été chargé sur la carte ?Non pas du tout, si grbl vois arriver mes trames il doit être un peu perdu
il s'avère que selon les fuses on peut très bien utiliser toute la mémoire Flash pour un programme, donc plus de place pour un bootloader. Je me demande si ils n'ont pas fait cela sur leur carte ?
Bonjour,Je n'ai pas trop chercher mais le role du bootloader c'est de lancer soit le programme soit le téléchargement.
Si ta n'a pas de bootloader un sketch Arduino ne pourra peut-être pas être lancer. Ca doit être effectivement un problème d'adresse de boot.
Une truc que je n'arrive pas, comment faire pour lancer un palpage à chaque début de plongé du z ? ou chaque début de contour.
De plus il y a une inversion dans la config du palpeur.
Ma carte fonctionne avec un STM32F4 et fait aussi l'asservissement des servomoteurs en+/-10V. Pour le firmware pour les STM32F1 j'ai du code a enlever et effectivement changer les Affectations de Pins en fonction des cartes. J'ai une NVUM qui attend et j'ai commandé une Bitsensor.
Ça doit être plus confortable avec une carte STM, pas bridé comme l'Arduino.
En l'arduino c'est une carte de démo même si ça fonctionne mieux que je pensai, on est quand même limité à 20KHz.
Voici ma carte elle utilise directement une carte Olimex, c'est plus simple. Je suis en train de refaire une carte plus compacte avec un carte chinoise beaucoup moins cher.
Pas la rouge qui est du commerce.C'est une carte faite maison ?
Quels avantages tu as dessus, WIFI, Ethernet ?