Tiens, si l'on parlait un peu de buffer ?

Aller en bas

Tiens, si l'on parlait un peu de buffer ? Empty Tiens, si l'on parlait un peu de buffer ?

Message par Bertrand Jeu 08 Juil 2010, 10:58

Pour faire un parcours continu avec une bonne dynamique de mouvement, il suffit que la carte enchaîne les vecteurs sans temps mort. S'il y a un délai perceptible entre deux vecteurs consécutif, ça veut dire que la machine s'immobilise pendant ce temps et donc le mouvement ou la série de mouvements qui précède doit mener à une décélération jusqu'en-dessous de la fréquence Start/Stop pour ne pas faire un arrêt brutal avec les conséquences que vous connaissez. On ne peut enchaîner deux vecteurs avec un ou plusieurs moteurs restant au-dessus de la fréquence Start/Stop que s'il n'y a pas une rupture de la continuité du mouvement.

D'où l'importance de la vitesse de transmission et de la gestion du buffer, éléments à mon sens parmi les plus importants pour les performances d'une carte CNC. Vous savez mon opinion sur les KHz - et en particulier les KHz de vitrine.

En théorie, il suffit que la carte ait toujours au moins un vecteur d'avance pour pouvoir enchaîner le mouvement courant et le suivant. Si la transmission était instantanée, par exemple avec une carte CNC sur le bus du PC, le buffer serait inutile (on suppose que la CPU du PC a une puissance de calcul suffisante pour enchaîner). En pratique, il faut transmettre les vecteurs le long d'un câble et c'est là que se trouve le goulet d'étranglement.

Pour la plupart des cartes CNC, un vecteur est composé de coordonnées et d'une vitesse de mouvement. Les coordonnées peuvent être linéaires, circulaires, NURBS ou patatoïdales, mais pour simplifier on va considérer qu'on est dans un monde exclusivement linéaire, même si ma nuque se raidit rien que d'y penser, ça a quand même un côté totalitaire. Vivent les courbes. Quoi qu'il en soit, les coordonnées peuvent être absolues (position à atteindre par rapport à un point zéro machine ou autre) ou relatives (déplacement depuis la position précédente). Elles peuvent être exprimées en incréments (micropas) ou en unités linéaires, millimètres ou autres, sur certains systèmes qui ont des capacités de traitement arithmétiques, par exemple les SM-Motion, RD-Lab, Isel-IMS6 et quelques autres. Travailler en unités linéaires n'offre pas beaucoup d'intérêt à mon avis, la force brute de calcul étant plutôt côté PC que côté CNC. Chacun son domaine.

La vitesse est quant à elle généralement indiquée en Hz sur l'axe majeur, i.e. celui qui va débiter le plus d'impulsions lors du déplacement pour le vecteur en question. Certains systèmes prennent une vitesse tangentielle et se débrouillent pour en recalculer les composantes axiales. Je cite tous ces cas pas forcément très courants parce que ça vous permettra de réaliser qu'il n'y a aucune norme et que c'est la jungle la plus complète, mais une jungle souvent créative et presque toujours instructive. Personnellement, j'adore ça, les développeurs de systèmes CNC sont de drôles de loustics même si certains virent parfois paranos.

Selon le langage de commande, on peut avoir à transmettre les coordonnées de tous les axes ou seulement les coordonnées qui vont changer au cours du mouvement, et la vitesse peut aussi n'être transmise que si elle a changé. Avec une vitesse correspondant à l'axe majeur, la valeur change quasiment à chaque vecteur, donc vouloir économiser de la bande passante là-dessus est une illusion. On n'est pas en G-code dont la composante F est une vitesse tangentielle donc variant peu. Par exemple, si vous faites un vecteur X+ à 0° à vitesse 10 mm/s puis un vecteur X+Y+ à 45° toujours à 10 mm/s, la vitesse transmise sera 10 mm/s puis 10/1.414=7 mm/s sur l'axe majeur (bien malin qui pourra dire lequel de X ou Y est majeur). La combinaison de 7 mm/s sur X et 7 mm/s sur Y donnera selon ce bon vieux Pythagore une vitesse de 10 mm/s sur notre hypoténuse à 45°. J'espère que vous suivez, même si je m'éloigne un peu du sujet.

On va considérer que le langage de commande est bien fichu - croyez que c'est loin d'être toujours le cas, on voit des perles - et donc ne transmet que ce qui est nécessaire, c'est à dire les coordonnées des axes qui bougent et la vitesse de l'axe qui bouge le plus. Service minimum, transmission a priori rapide.

Reste à savoir si le protocole est bien fichu - là encore, croyez que, etc. - et que ce protocole demande un minimum d'octets pour transmettre le maximum de données. Si le protocole est de type texte, c'est simple, pour un mouvement XY de 10000 incréments chacun à 1000 Hz, on va transmettre quelque chose comme LX10000Y10000V1000 (là, je cause InterpCNC-1) et ça nous fait 18 octets, plus le code <CR> en fin de télégramme, donc 19 au total. Selon la vitesse de transmission et le protocole bas-niveau du port, ça prend "un certain temps".

Si le protocole est de type binaire, on transmet en général des télégrammes plus brefs, surtout si le concepteur de la carte a été assez malin pour intégrer soit des données à taille variable, sur 8, 16, 24 ou 32 bits, soit un système de semi-compression. Je vais pas entrer dans les détails parce que ceux qui font des protocoles binaires n'aiment pas trop qu'on les expose sur le Net. Abstention donc. Je dirai juste qu'on arrive à transmettre beaucoup de données avec peu d'octets. Comme les impôts. Du moins en théorie. J'ajoute que les protocoles binaires peuvent être un véritable enfer à débugguer, puisqu'on ne voit pas grand-chose au monitoring. Mais quand ils sont bien fichus, et ça arrive tout de même, alors ça rentre dans le code comme Papa dans Maman.

Par-dessus le schéma peut venir se greffer un système de détection ou de correction d'erreurs de transmission. Rigolez si vous voulez, mais s'il manque seulement un zéro à la ligne du télégramme ci-dessus, vous pouvez mettre votre pièce à la poubelle. Donc mieux vaut que ça n'arrive pas trop souvent. Les psychopathes qui bossent sur les automates de production industrielle passent leur temps à inventer des couches de sécurisation qui alourdissent et de fait ralentissent la transmission, à grands renforts d'échos, de CRC, d'acquittements et autres joyeusetés. Mais au moins ils sont sûr qu'un télégramme envoyé à l'autre bout d'un câble de 50 cm arrivera intact ou qu'on sera prévenu si d'aventure un grand méchant loup a intercepté le petit chaperon rouge. D'où leur tendance à inventer par la même occasion des procédures de recollage de la transmission, voire des procédures de vérification du recollage, etc. Ca finit souvent en camisole chimique et chambre capitonnée.

A noter que les ports USB, qui n'ont pas vraiment été faits pour des modes conversationnels, ont un certain génie pour altérer les données transmises au moindre parasite faisant de l'auto-stop dans les environs, voire se mettre carrément en drapeau. Mais une fois encore, si le protocole est bien fichu, on recolle en douce la communication et ça passe inaperçu pour l'utilisateur. Oui, ça fait beaucoup de "si".

Tout ça pour dire qu'il faut en moyenne N millisecondes pour transmettre un vecteur, avec N pouvant énormément varier d'une carte CNC à l'autre. Si vous comparez d'une part un vecteur dans un langage benêt transmis par un port série à 19200 baud, et d'autre part un vecteur dans un langage malin transmis par un port USB avec optimisation de trame, ça peut varier de 0.1 milliseconde à 100 millisecondes. Eh oui, autant que ça.

Quoi qu'il en soit, et même avec un port Ethernet, l'instantanéité n'existe pas. Si la carte CNC n'est pas dans le PC, il y a un temps de transmission et il faut faire avec.

Ce qui nous mène au buffer.

Des gens un peu malins se sont dit à un moment : "il y a des mini-vecteurs qui sont exécutés en quelques millisecondes, et il y a de longs vecteurs qui sont exécutés en plusieurs secondes, donc il suffit que les vecteurs exécutés soient en moyenne moins rapides que la transmission". Qui dit moyenne dit stockage. Donc on transmet les vecteurs le plus vite possible et on croise les doigts pour qu'à aucun moment leur exécution ne rattrape la transmission. On croise les doigts, ou bien on essaie d'être encore plus malin : plus le buffer est gros, plus il peut prendre de l'avance donc plus il faudra du temps pour que le mouvement rattrape la transmission. Et plus il y aura de chances pour qu'un long vecteur donne du répit à la transmission, puisqu'un long vecteur est long à exécuter mais pas plus long à transmettre qu'un petit. Répit bien évidemment mis à profit pour pousser le plus grand nombre de copains dans le tuyau.

Et c'est là qu'on se heurte à la limite de taille. Si le buffer ne peut pas embarquer suffisamment de monde, on aura moins de chances d'avoir du répit. Dès que le buffer est plein, la transmission est obligée de s'arrêter puisque la carte ne peut plus rien recevoir ne sachant pas où le mettre. Quand la bête a l'estomac plein, faut attendre qu'elle digère un peu, et c'est du temps perdu pour la transmission puisque le port n'est pas utilisé alors que, peut-être, on sera à la bourre un peu plus loin. Donc plus le buffer est gros, moins il sera vite saturé, et donc plus on aura de l'avance pour ne pas se faire rattraper.

Evidemment, si vous faites un usinage de plusieurs centaines de milliers de micro-vecteurs exécutés à fond les ballons, ça finira bien par casser quelque part, même avec un énorme buffer. Mais on peut considérer que le cas est rare. Ceci dit, quand les KHz ne seront plus de mode, ça ne m'étonnerait pas que l'argument commercial suivant soit la taille du buffer, argument certes un peu moins stupide, mais jusqu'à un certain point seulement (ça peut devenir tout aussi idiot). Ce qui compte, c'est de transmettre vite. Et c'est même pas parce qu'on a un protocole USB, voire USB-2, pourtant réputés rapides en transmission "bulk", qu'on va forcément vite. Sauf dans les vitrines avec annonces en fluo, mais il est vrai qu'on achète aussi du rêve, et alors là ça peut se comprendre. Je recommande par conséquent à Eric d'annoncer que l'InterpCNC-2 utilise un protocole USB Warp-4 avec un buffer de 500 Pentaglups. Sûr que ça fera du buzz dans les forums et les heureux acquéreurs en tireront une légitime fierté. Mais hélas, Eric est un garçon sérieux et il se contentera d'annoncer que la carte peut recevoir - et traiter - quelque chose comme 4000 vecteurs par seconde. Là encore, de vrais vecteurs, pas des vecteurs de vitrine. Entre le bazar et la nécessité, il y a tant de poètes...

Mais remettons les pieds sur terre. Avec l'InterpCNC-1, malheureusement, vous n'avez pas un gros buffer et la vitesse de transmission n'atteint pas Warp-4. Donc vous ne pouvez pas stocker plus de quelque vecteurs et vous ne pouvez pas les transmettre plus vite que la musique, surtout s'il y a des triples croches dans la partition. Les cartes AxeMotion actuelles ont un buffer qui peut contenir 250 vecteurs, mais là encore Patrick est un garçon sérieux et il indique la valeur critique, c'est à dire avec 3 axes simultanés, bien qu'il soit rare d'interpoler 3 axes, même en 3D. Par contre, côté transmission, ça mitraille. Donc non je n'ai pas eu le même problème que vous en faisant le même essai, et non il ne m'appartient pas de vous dire si ça vaut la peine de changer de matos en l'état actuel des choses. Ca dépend si vous êtes pressé.

Je crois que j'ai à peu près tout dit, à part la façon dont on gère un buffer local, mais on va quand même pas entrer dans les détails techniques, ce serait déplacé ici.
Bertrand
Bertrand

Messages : 30
Date d'inscription : 29/07/2009
Age : 62
Localisation : Nice, France

http://www.galaad.net

Revenir en haut Aller en bas

Revenir en haut

- Sujets similaires

 
Permission de ce forum:
Vous ne pouvez pas répondre aux sujets dans ce forum