Piloter GRBL avec un Arduino Esplora?

Bonjour,

Nouvel inscrit sur ce forum, je m’appelle Aymeric, 40 ans, ingénieur dans le nucléaire (je sais, c’est mal) et j’habite Lyon.

Je fais appel à vos connaissances car j’ai un soucis (j’en ai d’autres mais qui sont exposés sur un forum de proctologie).

Comme beaucoup, je me suis monté une petite CNC pilotée par le programme GRBL sur un Arduino UNO.
Comme certains parmi ces beaucoup, je cherche à m’affranchir d’un PC pour envoyer le G-Code à ma machine.
Mais apparemment comme personne, je cherche à utiliser un Arduino Esplora pour envoyer le G-Code vers l’Arduino UNO depuis une carte SD insérée à l’arrière de l’écran de l’Esplora.

Pour cela, je cherche à établir une communication série RxTx entre l’Esplora et l’UNO (comme le faisait mon PC et l’UNO) via les connecteurs TinkerKit disponibles sur la face supérieure de l’Esplora (port série émulé).

Et c’est là que ça coince.
En effet, quand l’Esplora envoit “$$”, GRBL répond le listing de tous les paramètres de la machine qui doit apparaître sur l’écran de l’Esplora. Malheureusement, j’ai beaucoup de caractères mal reçus et il faut que je baisse énormément la fréquence de la liaison série pour améliorer la réception (de 115200 à 2400 bds et ce n’est pas encore bon).

Pourtant ces connecteurs TinkerKit (ceux de gauche en orange car ceux de droite sont multiplexés) sont directement raccordés à l’ATMEGA32U4 de l’Esplora et utilisables en entrée et en sortie. De plus, la fréquence de l’Esplora est de 16Mhz comme l’UNO.

Voir ce descriptif de l’Esplora :

Bref, je n’arrive pas à récupérer et à afficher correctement ce que GRBL m’envoit.
Merci de votre aide.

Ci-dessous, l’ébauche de mon programme de communication de l’Esplora :

#include <Esplora.h>
#include <SPI.h>
#include <TFT.h>
#include <SoftwareSerial.h>

#define TAILLE_TEXTE 1
#define CHAR_MAX_PAR_LIGNE 24

SoftwareSerial mySerial(11, 3); // (RX, TX), apparemment seule 11 est autorisé pour Rx
//==================================================================
void setup() {
  EsploraTFT.begin();
  EsploraTFT.background(0, 0, 0);
  EsploraTFT.stroke(255, 255, 255);
  EsploraTFT.setTextSize(TAILLE_TEXTE);

  EsploraTFT.println("Reset GRBL...");

  mySerial.begin(2400); //2400 dans GRBL aussi
  EsploraTFT.print("Serial 2400bds...");
  while (!mySerial) {}
  EsploraTFT.println("ok");

  //mySerial.write('\030$X\015'); //syntaxe vu dans le programme de yurayerz sur Youtube à envoyer à GRBL pour établir la communication 
  mySerial.write('\030'); //Malheureusement, obligé de la découper en caractères unitaires pour que ça marche
  mySerial.write('

);
  mySerial.write(‘X’);
  mySerial.write(’\015’);

EsploraTFT.print(“Connexion to GRBL…”);
  recoit_affiche_message (CHAR_MAX_PAR_LIGNE); // doit recevoir “GRBL 0.9J […]”

// listing des paramètres GRBL
  EsploraTFT.println("$");
  mySerial.write(’


); //'$\015' ne marche pas
  mySerial.write('

);
  mySerial.write(’\015’); // code ASCII 13 en octale
  recoit_affiche_message(CHAR_MAX_PAR_LIGNE);
}
//==================================================================
void loop() {
}
//==================================================================
void recoit_affiche_message (int _CHAR_MAX_PAR_LIGNE) {
  while (!mySerial.available()) {}

int num_char = 0;
  char ch = “”;

while (mySerial.available()) {
    ch = mySerial.read();
    if (num_char <= (_CHAR_MAX_PAR_LIGNE - 1) and (ch >= ’ ')) {
      EsploraTFT.print(ch); // GRBL termine ses envois par CR (ASCII 13) puis LF (ASCII 10)
      num_char ++;
    }
    if (ch == ‘\012’) { //fin de phrase
      num_char = 0;
      EsploraTFT.println();
    }
  }
}

Bonjour et bienvenu au forum !

le hic c'est que l'uart matériel de l'avr est ici bêtement gâché au service du lcd, ce qui fait qu'on est limité par le recours au software serial
je suis quand-même étonné que cela ne fonctionne pas aux petites vitesses (l'as-tu essayé en dehors de la centrale ? :grin: )

Merci Trimarco pour ton accueil.

Tu as raison, faudrait que j'essaies loin des radiations :D...mais je suis comme Saint Thomas, je ne crois que ce que je vois...et la radioactivité, je ne l'ai jamais vu :wink:

Bonsoir
conflit.png

Le repiquage sur Rx/Tx côté Uno risque fort de perturber la liaison avec l'Esplora, Rx et TX n'étant pas disponibles.
En effet sur la carte UNO Rx et Tx sont déjà connectés au circuit d'interface Uart/USB
Conflit assuré donc dans ce ménage à trois : composant USB/Série + Mega 328 (UNO) + 32U4 (Esplora)

Quand on veut ajouter une liaison série à une carte Uno on le fait avec SoftwareSerial et sur des pins autres que Rx et TX......pas facile içi sans modifier le code de GRBL pour y ajouter une E/S série logicielle

perso : je remplacerait bien l'Esplora par un Raspberry Pi + écran LCD , la liaison avec la carte Uno se faisant par USB. Si GRBL sur carte Uno communique exclusivement par USB c'est par là qu'il faut passer.
La contrainte est sur la carte Uno, par la carte Esplora

conflit.png

:wink: et bienvenue,

La carte UNO as-elle besoin de lire quoi que ce soit en provenance du port USB ?

Bonsoir al1fch et merci de ton retour :wink:

Cette interférence est effectivement à étudier et malheureusement je n'ai pas les compétences pour bidouiller le programme GRBL.

Toutefois, les quelques exemples de montages GRBL Standalone que j'ai vu (sur Youtube par exemple) n'ont pas évoqué de modification du programme GRBL.

Je vais regarder ton montage avec un Raspberry, ça sera surement plus accessible pour moi :smiley:

Bonsoir supercc et merci :wink:

Dans mon montage, le port USB de l'Arduino UNO n'est plus exploité (plus de PC), tout passe (ou passerait) directement par ses bornes Rx/Tx.

Dans mon montage, le port USB de l’Arduino UNO n’est plus exploité (plus de PC), tout passe (ou passerait) directement par ses bornes Rx/Tx.

Oui mais sur la carte UNO un circuit intégré d’interfaçage USB reste connecté aux mêmes Rx et Tx (à travers des résistances de 1K Ohm)

Ceci dégrade les signaux échangés avec l’Esplora même en l’absence de connection à un PC
Cette dégradation est à mon avis l’explication du fait que l’information passe mal… même si parfois ça peut ‘tomber en marche’

Alors, sauf si j’ai loupé un truc, il est libre tu peux le réutiliser (plus de SoftwareSerial ;-)). Branchement directs des Rx/Tx (en croisant) des UART matériels des 2 cartes. PS : je ne connais pas la l’esplora mais je fait cela entre Uno et d1-mini.

Je ne vois pas ou il y aurait interférence ?

Cette dégradation est à mon avis l’explication du fait que l’information passe mal

AMHA, je pense que c’est uniquement du à l’usage de SoftwareSerial coté UNO.

Lorsque j’ai un pont nano <-> d1-mini je laisse même (ou pas) les câbles USB branchés. Alors je ne dis pas que la console reste utilisable hein ;-), mais câbles branchés ou pas les cartes échange à 115200 bauds :wink:

EDIT : je suis sous GNU/Linux mais je ne pense pas que cela soit différent sous Windows.

la liaison entre le 16u2 et le Mega328 , même atténuée par la présence de résistances de 1kOhm en série, est de mon point de vue de nature à influer sur les niveaux logiques des pins D0 et D1 (Rx et Tx) et produire parfois des pertes d'info

Il ne perds rien (enfin j'espère ;-)) à tenter le coup :wink:

Coté UNO, j'exploite les bornes matérielles Rx/TX (et pas le port USB).

En revanche, coté Esplora, les bornes Rx/Tx sont déjà utilisées comme des entrées/sorties classiques par l'écran TFT dédié à l'Esplora. Je suis donc obligé d'émuler cette liaison sur l'Esplora.

J'avais déjà entendu parlé de mettre des résistances en série sur la liaison RxTx (mais avec des valeurs de 20k ohms). J'ai déjà tenté le coup sans succès mais je vais suivre ton conseil Al1fch et utiliser des résistances de 1k ohms :wink:

Coté UNO, j'exploite les bornes matérielles Rx/TX (et pas le port USB).

En revanche, coté Esplora, les bornes Rx/Tx sont déjà utilisées comme des entrées/sorties classiques par l'écran TFT dédié à l'Esplora. Je suis donc obligé d'émuler cette liaison sur l'Esplora.

C'est clair et pris en compte dans les réponses précedentes !

les résistances de 1K mentionnées sont celles déjà présentes sur la carte UNO pour relier les RX et TX du Mega328 et du second microncontrolleur 16u2 assurant l'interface avec l'USB, pas des résistances ajoutées entre UNo et Esplora.

Disons que je n'attends pas des miracles de l'utilisation de RX et TX sur une carte UNO vu le schéma de la carte.
Avec en plus un software serial (obligatoire vu le schéma de la carte Esplora) l'autre bout en plus ça me parait fragile comme liaison.

Alors, sauf si j'ai loupé un truc, il est libre tu peux le réutiliser

Coté UNO, j'exploite les bornes matérielles Rx/TX (et pas le port USB).

Bon et bien j'avais loupé un truc... désolé

Avec SoftwareSerial, ma petite expérience me fait privilégier la vitesse de 9600, mais il faudra vérifier les trames...

Il y a des alternatives à SoftwareSerial. Je ne connais pas NeoSWSerial mais avec AltSoftSerial même si dans certains cas c'était mieux que SoftwareSerial je perdais quand même des caractères... Toutes ces solutions logicielles ont leur limites et leur particularités, bien lire la doc, pas portable sur toutes les cartes (en tout cas de la même manière), ...)

Merci à vous pour toutes ces infos.

Je vais regarder les différentes alternatives à SoftwareSerial que tu mets dans ton lien supercc. En tout cas, je note de votre expérience que les ports émulés sont loin d'être sûrs.

Bonjour

Après une bonne nuit de repos je reviens (bémol !) sur ce que j'ai développé hier soir : ça vaut pour les infos dans les sens Esplora -> Uno, beaucoup moins dans l'autre sens , sens pour lequel le défaut de communication est rencontré.

Il faut chercher ailleurs !
Je suppose que l'environnement de GRBL est bruité. La liaison série Uno -> Esplora serait-elle parasitée ?
Un oscilloscope ou un analyseur logique seraient utiles içi pour comprendre ce qui se passe.

Est-il possible, en lever de doute, de tester la communication avec SoftSerial sur Esplora mais avec à l'autre bout un carte Arduino 'nue (sans matériel et logiciel GRBL) ?

Autre test : enlever le fil rouge (alimentation de l'Esplora par la carte Uno GRBL) pour alimenter séparément la carte Esplora

Bonjour Al1fch et merci.

Je n'ai pas d'oscilloscope ni d'analyseur logique sous la main mais je vais me procurer ça.

Il semble qu'en effet, le fait d'enlever le fil rouge améliore la qualité de la transmission (mais il reste des défauts).

Comme tu le conseil, je vais aussi programmer un arduino UNO pour qu'il m'envoie un message basique (alphabet par ex.) et je verrai bien si l'Esplora le récupère correctement.

En continuant mes essais, j'ai découvert d'autres bizarreries qui pourraient permettre d'expliquer tout ça (ex. quand je diminue le nombre de caractères max par ligne à afficher sur l'Esplora, il y a moins d'erreur. Est-ce que cela voudrait que c'est la routine d'affichage qui ralenti le système et fait qu'il n'arrive plus à suivre la transmission?). Je continue d'investiguer et je vous dirai.

Afficher la ligne une fois celle ci récupérée au lieu d'afficher caractère par caractère ?
Comme dans cet exemple : https://www.arduino.cc/en/Tutorial/EsploraTFTTemp

Un coup d'oeil aux fonctions de la librairie TFT permettrait peut être de mieux combiner réception et affichage et réduire l'engorgement'

Pour information le buffer de SoftSerial à une taille de 64 octets