Arduino Laser beamshow

[plopoi]

Salut! je trouve le sujet de l'arduino pas mal intéressant . J'ai commencé à développer un petit DAC aussi mais à base de PIC18F (pour l'instant j'ai pas fait grand chose dessus) et j'ai vu un peu plus haut que tu voulais gérer de l'analogique? Je peux te filer mes plans si tu veux, j'utilise 5 DAC 12bits SPI avec sortie 0 à 5V, ils sont vraiment pas difficile à mettre en oeuvre et on peut les avoir en échantillon gratuits chez Microchip. Il s'agit de MCP4921 (12 bits, référence externe, SPI, rail-to-rail...). Le seul petit truc que je commence à me demander c'est si par la suite la SPI va permettre de travailler à 30 - 40kpps.

Si t'es intéressé n'hésites pas, j'ai un petit bout de code (en C) qui pourra peut-être te permettre de gagner un peu de temps sur la mise en oeuvre avec le passage de variable 12 bits à l'envoi de 2 trames SPI 8 bits

Yep ... je farfouille de l'analogique histoire de voir si on peut améliorer un peu les choses sur la base des premiers résultats assez sympathiques en TTL .
commande en PWM m'apparait rapidement être une impasse

Je te rejoins sur cette base technologique (SPI), cela me semble plutôt intéressant comme solution ...

J'attends qq samples MCP42100 & MCP4922 histoire de voir ce qui sera le plus simple a mettre en œuvre sur la base de mon prototype ... soit du pur DAC (4922) avec qq composants derrières (AOP + transistor) soit directement polariser un transistor de puissance via un "potar numérique" (42100)... Cette deuxième option me parait demander moins de composants périphériques au prix d'une perte de résolution (7bits vs 12bits), mais vu le cotés rudimentaire de mon scanner, cela ne m'apparait pas un gros handicap ...

Pour ton bout de code C je suis preneur

Question : Pourquoi être parti sur du 4921 alors que le 4922 t'offre directement deux sorties analogiques ?

[Dark-Hole]

Bonsoir, je viens de voir ton poste, je mets le code en ligne d'ici demain je l'ai pas sur moi.

Le choix du 4921 c'était juste au niveau du routage du circuit ^^, au lieu de faire un truc avec 3 DAC et 5AOP galère à router, j'ai préféré mettre 1 DAC/1 AOP, et en plus niveau esthétique c'est mieux ^^

Pour ce qui est de l'interface de puissance, personnellement je partirais sur DAC 12 bits + AOP, et après 2 petits convertisseurs (là ça dépend si tu commandes tes moteurs en tension ou en intensité). Enfin c'est une suggestion personnelle, l'autre me semble toute aussi valable

[Dark-Hole]

A savoir qu'au niveau SPI j'ai pour le moment été un peu déçu par mon PIC qui est limité à 12MIPS et 8bits (je sais pas si ça signifie la même chose chez Atmel mais sa a un rapport avec le nombre d'instructions par cycle) et donc je suis très limité au niveau de la vitesse de balayage (il me faut environ 0.5s pour générer un cercle avec résolution maximale). Je vais attendre cette semaine d en recevoir un qui tourne à 70MHz et 70MIPS et 16 bits pour voir si c'est mieux, sinon peut être envisager des DAC parallèles même si je ne pense pas que ce sera nécessaire

[plopoi]

A savoir qu'au niveau SPI j'ai pour le moment été un peu déçu par mon PIC qui est limité à 12MIPS et 8bits (je sais pas si ça signifie la même chose chez Atmel mais sa a un rapport avec le nombre d'instructions par cycle) et donc je suis très limité au niveau de la vitesse de balayage (il me faut environ 0.5s pour générer un cercle avec résolution maximale). Je vais attendre cette semaine d en recevoir un qui tourne à 70MHz et 70MIPS et 16 bits pour voir si c'est mieux, sinon peut être envisager des DAC parallèles même si je ne pense pas que ce sera nécessaire

Je ne pense pas que l'atmega soit aussi limité d'un point de vue du débit SPI ...En fait tes premiers résultats m’étonnent...

l'ATmega328 donné a 1MIPS/MHz et donc affiche une capacité de 16MIPS dans le cas de l'Arduino...
Christopher annonce un scan rate a 30Kpps pour son DAC sous base Arduino.
Vérification faite, il utilise un MCP4922 pour la gestion du scan donc, il y a peu être un truc qui pèche de ton cotés ?

Mes premiers essais laissent entrevoir que la gestion du SPI est d'une grande simplicité sur Arduino...
Regarde du cotés de cette librairie, cela pourrait t’intéresser pour ton dev sous base de PIC.


Pour ma part, et tu doit être dans le même cas, je pense continuer a bidouiller un moment, histoire de continuer à (ré)apprendre pas mal de chose (qu'elles sont loin mes études d’électronique ;- )
Avec mes premiers résultats encourageants j'ai aussi bien envie de pousser mon système open loop dans ses retranchements... (mon objectif premier reste de réaliser un petit beamshow avec un minimum d'investissement et un max de récup).

Néanmoins si je craque pour un jeu de galvos (pas évident vu mon budget du moment), je pense que je partirai sur la base de ce DAC OLSD, bien conçut à première vue, et développerai les outils dont j'aurais éventuellement besoin, ce qui ferait avancer le concept d'un proj laser Open Source ...

[plopoi]

Pour ce qui est de l'interface de puissance, personnellement je partirais sur DAC 12 bits + AOP, et après 2 petits convertisseurs (là ça dépend si tu commandes tes moteurs en tension ou en intensité). Enfin c'est une suggestion personnelle, l'autre me semble toute aussi valable

La solution d'utiliser des Digipots est de prime abord la solution la plus simple a mettre en œuvre en réalisant la gestion d'un "offset" (eviter un point creux en passant du repos a un état donné) logiciellement (au détriment d'une perte de résolution sur la conversion A/N, je sais c'est vraiment du bicolage ).

Sinon un passage par la case AOP est bien entendu la meilleure solution et donc avec cette option, un DAC sera quoi qu'il en soit plus judicieux... Ce serait donc a première vue DAC/AOP/transistor...

Par contre si tu peut m'aider à réveiller mes maigres restes de souvenir en électronique (et dire que j'ai poussé jusqu'au DEST après mon DEST ), quid des +/- d'une gestion et courant plutôt qu'en tension (ou l'inverse) ?

[Dark-Hole]

En effet, pour mon soucis de vitesse je pense plus à un problème de code qu'autre chose (mon compilateur est en version étudiante, et il me bloque certaine fonction : je ne parviens pas à utiliser la PLL pour faire tourner mon chip à 40MHz depuis un quartz 20MHz, et l'horloge de la SPI est bloquée sur "system clock divide by 4"... Il faudrait que j'essaie avec MPLAB C18...

une petite vidéo d'un losange avec un effet de rotation : https://www.youtube.com/watch?v=H80NFV9L3IA

Voici le code pour la figure de la vidéo :

Programme principal :

Code: Select all

#include <main.h>
#include <variable.c>
void main()
{
// paramètre du PIC enlevé (inutile pour l'Arduino et prend de la place)

   X=0;
   Y=2048;
   Rot=1;
   Rot2=8;
   a=0;
   b=0;
   c=0;
   
   WHILE (true)
   {
      WHILE (c == 0)
      {
         WHILE ((X <= 2048||Y >= 2048) &&a == 0&&b == 0)
         {
            X1 = ((0xFF00&X) / 256) + 0x70;
            X2 = (0x00FF&X);
            Y1 = ((0xFF00&Y) / 256) + 0x70;
            Y2 = (0x00FF&Y);
            output_low (PIN_D7);
            spi_write (X1);
            spi_write (X2);
            output_high (PIN_D7) ;
            output_low (PIN_B2);
            spi_write (Y1);
            spi_write (Y2);
            output_high (PIN_B2) ;
            X = X + Rot2;
            Y = Y + Rot;

            IF (X == 2048||Y == 4094)
            {
               a = 1;
               b = 0;
            }
         }

         WHILE ((X >= 2048||Y >= 2048) &&a == 1&&b == 0)
         {
            X1 = ((0xFF00&X) / 256) + 0x70;
            X2 = (0x00FF&X);
            Y1 = ((0xFF00&Y) / 256) + 0x70;
            Y2 = (0x00FF&Y);
            output_low (PIN_D7);
            spi_write (X1);
            spi_write (X2);
            output_high (PIN_D7);
            output_low (PIN_B2);
            spi_write (Y1);
            spi_write (Y2);
            output_high (PIN_B2) ;
            X = X + Rot2;
            Y = Y - Rot;

            IF (X == 4095||Y == 2048)
            {
               a = 1;
               b = 1;
            }
         }

         WHILE ((X <= 4095||Y <= 2048) &&a == 1&&b == 1)
         {
            X1 = ((0xFF00&X) / 256) + 0x70;
            X2 = (0x00FF&X);
            Y1 = ((0xFF00&Y) / 256) + 0x70;
            Y2 = (0x00FF&Y);
            output_low (PIN_D7);
            spi_write (X1);
            spi_write (X2);
            output_high (PIN_D7) ;
            output_low (PIN_B2);
            spi_write (Y1);
            spi_write (Y2);
            output_high (PIN_B2);
            X = X - Rot2;
            Y = Y - Rot;

            IF (X == 2048||Y == 0)
            {
               a = 0;
               b = 1;
            }
         }

         WHILE ((X <= 2048||Y >= 2048) &&a == 0&&b == 1)
         {
            X1 = ((0xFF00&X) / 256) + 0x70;
            X2 = (0x00FF&X);
            Y1 = ((0xFF00&Y) / 256) + 0x70;
            Y2 = (0x00FF&Y);
            output_low (PIN_D7);
            spi_write (X1);
            spi_write (X2);
            output_high (PIN_D7) ;
            output_low (PIN_B2);
            spi_write (Y1);
            spi_write (Y2);
            output_high (PIN_B2);
            X = X - Rot2;
            Y = Y + Rot;

            IF (X == 0||Y == 2048)
            {
               a = 0;
               b = 0;
               Rot = Rot + 1;

               IF (Rot == 16)
               {
                  c = 1;
               }
            }
         }
      }

      WHILE (c == 1)
      {
         WHILE ((X <= 2048||Y >= 2048) &&a == 0&&b == 0)
         {
            X1 = ((0xFF00&X) / 256) + 0x70;
            X2 = (0x00FF&X);
            Y1 = ((0xFF00&Y) / 256) + 0x70;
            Y2 = (0x00FF&Y);
            output_low (PIN_D7);
            spi_write (X1);
            spi_write (X2);
            output_high (PIN_D7) ;
            output_low (PIN_B2);
            spi_write (Y1);
            spi_write (Y2);
            output_high (PIN_B2) ;
            X = X + Rot2;
            Y = Y + Rot;

            IF (X == 2048||Y == 4094)
            {
               a = 1;
               b = 0;
            }
         }

         WHILE ((X >= 2048||Y >= 2048) &&a == 1&&b == 0)
         {
            X1 = ((0xFF00&X) / 256) + 0x70;
            X2 = (0x00FF&X);
            Y1 = ((0xFF00&Y) / 256) + 0x70;
            Y2 = (0x00FF&Y);
            output_low (PIN_D7);
            spi_write (X1);
            spi_write (X2);
            output_high (PIN_D7);
            output_low (PIN_B2);
            spi_write (Y1);
            spi_write (Y2);
            output_high (PIN_B2) ;
            X = X + Rot2;
            Y = Y - Rot;

            IF (X == 4095||Y == 2048)
            {
               a = 1;
               b = 1;
            }
         }

         WHILE ((X <= 4095||Y <= 2048) &&a == 1&&b == 1)
         {
            X1 = ((0xFF00&X) / 256) + 0x70;
            X2 = (0x00FF&X);
            Y1 = ((0xFF00&Y) / 256) + 0x70;
            Y2 = (0x00FF&Y);
            output_low (PIN_D7);
            spi_write (X1);
            spi_write (X2);
            output_high (PIN_D7) ;
            output_low (PIN_B2);
            spi_write (Y1);
            spi_write (Y2);
            output_high (PIN_B2);
            X = X - Rot2;
            Y = Y - Rot;

            IF (X == 2048||Y == 0)
            {
               a = 0;
               b = 1;
            }
         }

         WHILE ((X <= 2048||Y >= 2048) &&a == 0&&b == 1)
         {
            X1 = ((0xFF00&X) / 256) + 0x70;
            X2 = (0x00FF&X);
            Y1 = ((0xFF00&Y) / 256) + 0x70;
            Y2 = (0x00FF&Y);
            output_low (PIN_D7);
            spi_write (X1);
            spi_write (X2);
            output_high (PIN_D7) ;
            output_low (PIN_B2);
            spi_write (Y1);
            spi_write (Y2);
            output_high (PIN_B2);
            X = X - Rot2;
            Y = Y + Rot;

            IF (X == 0||Y == 2048)
            {
               a = 0;
               b = 0;
               Rot = Rot - 1;

               IF (Rot == 1)
               {
                  c = 0;
               }
            }
         }
      }
   }
}

variable.c :

Code: Select all

void variable ();

long X;
long Y;

int1 a;
int1 b;
int1 c;
int1 d;

int Rot;
int Rot2;
int X1;
int X2;
int Y1;
int Y2;

signed int Z;
signed long X3;
float X4;
signed long Y3;
float Y4;

[djbastien]

@Dark hole:
t'utilises quoi comme editeur/compilo?
mefies toi des fonctions toutes faites (spi_write() ), elles sont bien souvent pas du tout optimisées et tu ne sais pas ce qui se cache derrière!
le mieux est de se faire sa propre bibliothèque de fonctions pour vraiment tout maitriser.

sinon t'aimes bien les while ^^
chaque while correspond à 1 segment c'est ça?

[Dark-Hole]

Euh pour les broches j'ai pas pensé à remplacer, mais PIN_B2 est associée à /CS du DAC n°1 et PIN_D7 à /CS du DAC n°2

Pour la conversion tension/courant je pense que le plus simple c'est de reprendre un driver de diode en ajoutant une DIODE DE ROUE LIBRE pour protéger le transistor des surtensions dues aux bobines (c'est simple, c'est pas très cher et ça te permettra de régler le courant max et l'offset).

Le seul soucis est que tes galvas seront positionnés non pas en position milieu mais à une des positions extrèmes...

Pour ma part je vais utiliser un ampli de puissance monté en convertisseur U/I avec une petite interface qui permettra de fixer le galva en position milieue, mais je n'ai encore pas testé et je ne sais pas si ça marche bien et si l'ampli tiendra le coup...

[Dark-Hole]

@ djbastien : Mon compilo c'est CCS PIC, il est pas mal mais appriori j'ai atteint la limite avec, faudrait que je prenne le temps d'analyser la biblio de la SPI, mais merci pour l'info

En effet les whiles correspondent à chaque segment, mais il y a en plus une fonction qui permet de réduire/augmenter une des diagonales pour donner l'effet que ça tourne (c'est pas très évolué mais bon j ai fait ça en 10 minutes pour tester en XY)

[djbastien]

ok
j'avais CCS PIS aussi au début mais je le trouvais assez bizarre à utiliser avec les fonctions toutes faites.
Depuis je suis passé sur mikroC et c'est beaucoup mieux!
Tu as des fonctions toutes faites pour coder rapidement mais tu peux aussi accéder à tous les registres et faire ce que tu veux!
La version d'evaluation te limite seulement la taille du code à 1Ko.

[Dark-Hole]

OK merci, je vais tester ça alors
C18 a l'air pas mal aussi, et de toute façon quand je passerai au PIC24F, dsPIC33 ou même PIC32 je serai obligé d'abandonné CCS vu que j ai pas l'extension...

Sinon je pense qu'à l'avenir j'envisagerai aussi l'assembleur et le C mais sur MSP430 de chez Texas Instrument (j'en ai fait un peu, j'ai eu du mal à le prendre en main mais on peut vraiment faire plein de truc avec, et vu qu'à l'université je vais en manger pas mal autant que je m'y mette maintenant ^^).

Quoiqu'il en soit faut que je trouve une solution pour mon problème de vitesse

[plopoi]

Merci pour le bout de code c'est toujours instructif ... Et puis en XY ça fonctionne apparemment pas si mal pour du codé sur un coin de table

Pas de quoi se lancer dans de l'assembleur, même si dans certains cas le gain est effectivement meilleur pour certaines fonction toute faites (mais mal).
A défaut d’être compliqué dans le fond (mais fastidieux tout de même), ce qui est certains, c'est que ça ne simplifie pas la (re)lecture ...

...

Pour la conversion tension/courant je pense que le plus simple c'est de reprendre un driver de diode en ajoutant une DIODE DE ROUE LIBRE pour protéger le transistor des surtensions dues aux bobines (c'est simple, c'est pas très cher et ça te permettra de régler le courant max et l'offset).

Le seul soucis est que tes galvas seront positionnés non pas en position milieu mais à une des positions extrêmes...

L'idée du driver de diode est bonne, merci pour l'idée, cela ne m'était pas venu a l'esprit ...

Pour la diode de roue libre, si j'abandonne la gestion TTL a base d'ULN2008 (réseau de 8 darlinghton qui l’intègre déjà), t'inquiète, je n'y manquerai pas
La théorie des ondes, thecbychev ou le calcul d'une intégrale de fourrier sont loin, mais Il me reste encore des truc


Je te posais plus la question, pour toi, quel est l’intérêt de considérer une logique de commande en courant plutôt qu'en tension dans le cas d'un galvanomètre;
Ou assimilé dans mon cas, puisque j'utilise mes PAP (bipolaire) comme des galva.
Enfin, presque, cela me contraint a concevoir mes pattern suivant un mode oscillatoire, a l'opposé de la précision de positionnement de "vrais" galva avec une contre réaction.

Dans ce cas le centrage est forcé du fait qu'une des deux bobines est constamment alimentée.
En fait, tu m'apporte déjà un premier élément de réponse/réflexion, peut être sans le vouloir...

Puisque je suis déjà constamment en position extrême, dans mon état "0" actuel, si tu voit ou je veux en venir,
le fait de considérer la position de repos comme étant la seconde bobine aussi alimenté par défaut n'est pas inintéressante, crado tout plein dans le principe, mais a tester ...!

Cela pourrait éventuellement solutionner "à pas cher" des soucis de linéarité sur la bobine de commande sans gestion "d'offset" l'alim (au sens de maintenir par défaut un courant minimal d'excitation)

Pour rester avec des PAP ce serait beaucoup plus simple de faire comme dans certains scanner commerciaux d'entrée de gamme et contrôler des PAP en Microstepping.
Si je trouve le rendu a première vue brouillon, mais pas inintéressant, je m’interroge toutefois sur l'innocuité de certains pattern pour les yeux (présence de "points chaud", effet de "tir") ...

A lire, le reverse engenieering d'un proj de ce genre ici (très instructif): http://openschemes.com/2011/11/01/casa- ... nd-review/ .
pour le rendu il y a pas mal de vidéo, mais celle là est la plus intéréssante a mon sens http://www.youtube.com/watch?v=sEgkbgyMnhQ...


++

[Dark-Hole]

OK pour l'assembleur je prends note, j en ai jamais fait mais j ai vu a pas mal d'endroit que c'était plus rapide au niveau de l'exécution, après c'est sur pour relire le truc c'est une autre affaire

Pour ce qui est de commander la bobine en courant plutôt qu en tension c'est simple : le champ magnétique (l'élément principal qu'on recherche) dépend du nombre de spires de la bobine, du diamètre du fil... et du courant qui le traverse! (après si on veut vraiment pousser les calculs j'ai des formules super utiles dans un coin, avec l'effet de peau, etc. mais bon vu que c'est des bobines déja toute faite ça sera surement pas utile ici).

Pour le courant commence doucement et augmente peu à peu, avec un peu de chance il y a un point ou le rendement sera meilleur même si le courant n'est pas au max que la bobine peut supporter (je ne sais pas si c'est valable tout le temp mais j'avais fait le test avec une bobine de relais sans noyau et un aimant attaché à un ressort, arrivé à un certain point l'aimant ne bouge plus meme si on augmente le courant) comme ça ça évite de faire trop chauffer la bobine et le driver

Pour le point milieu c'est pas bête, mais j ai essayer de réfléchir un peu sur le moyen de faire et c'est plutot galère :

- pour avoir une tension qui varie de -2.5V à +2.5V à partir de 0-5V c'est facile, un offset de -2.5V.
- Pour le galvo, une bobine alimentée en permanence ou une barre de torsion, pas de problème non plus.
- par contre au niveau du programme, il faut fixer le point 0, et cela demande que les DAC soient à la tension demie-échelle au repos, qu'ils soient à pleine échelle pour un extrème et à 0 pour la position extrème opposée. c'est faisable mais faut ça ne simplifie pas les choses

[Dark-Hole]

Je viens de repenser à quelque chose : Le driver de diode c'est bien mais valable que si on reste en valeurs positive, donc pour la dernière partie de mon post précédent faudra trouver un autre driver

[plopoi]

Je viens de repenser à quelque chose : Le driver de diode c'est bien mais valable que si on reste en valeurs positive, donc pour la dernière partie de mon post précédent faudra trouver un autre driver

pas vraiment ... il suffit de se positionner a +2.5V et tu as un point milieu entre 0 et 5V ... CQFD

[Dark-Hole]

Ah oui aussi enfin ça n'empèche qu'il faut faire une petite modif au niveau du code, mais y a pas besoin de s'embêter avec un offset électronique, il suffit de le programmer en soft ^^

[plopoi]

C'est bien l'idée !

Cependant, dans le cas de PAP, la gestion d'un courant de "threshold" autour du point "0" reel (quand seulement la bobine de maintien est alimentée) serait un plus.
En effet il faut dépasser un de courant de seuil minimum pour pouvoir commencer actionner le miroir.

Je n'ai pas encore trop cherché sur les archives du forum, mais si une âme charitable possède déjà un plan de driver qui intègre cette fonction, je suis preneur ^^

[Dark-Hole]

Je vois à peu près ce que tu veux dire, enfin je crois

Pour le courant de point 0 vu que c'est un courant fixe c'est pas un problème, un petit générateur de courant règlable (on en trouve fait avec des régulateurs 78xx ou dans le même genre. ça peut convenir dans une certaine limite même si on peut faire mieux).

Pour le seuil à dépasser, je vais peut être compliquer le truc, mais il faudrait que les DACs envoient une impulsion avant d'envoyer la "vraie valeur" à chaque fois que les scans sont au point 0, en gardant les sources éteintes pendant ce temps... à moins qu un courant d'offset suffise, mais il risque de perturber le système car dans ce cas ça va être délicat à ajuster pour que le moteur bouge à chaque petite variation et qu'il revienne au point 0 lorsqu il est inactif...

Sinon on peut essayer de faire en sorte que la bobine de maintien soit pilotée par 2 courants :

- Phase 1 :
Le courant de la bobine de maintien est maximum.
La sortie du DAC est au point 0.

- Phase 2 :
Le courant de la bobine est réglé au seuil bas.
On s'apprète à envoyer un courant sur la bobine de scan.

-Phase 3 :
Le courant de maintien est toujours minimum.
On envoie le courant de scan.

- Phase 4 :
On rappel le miroir en position milieu en augmentant le courant de maintien.
Le DAC est de nouveau au point 0.

Dans ce cas le courant permet à la bobine de maintien d'ajuster la "force du ressort" (en gros on pourrait l'assimiler à une barre de torsion de coefficient réglable dans le temps)

Côté théorique c'est pas très compliqué, mais en pratique il y a pas mal d'inconvénients : le temps d'enchainement est plus long, donc on perd en vitesse de balayage, et techniquement il faut gérer tout ça, soit avec de l'électronique soit au niveau programmation.

Point de vue électronique, quelque chose dans le style porte logique ou comparateur entre /CS et SCK par exemple, qui permet d'anticiper le passage du DAC à une valeur ou au point 0, suivi d'une interface de puissance qui switch entre les deux courants de maintien fixés...

Point de vue programme, il faut libérer 2 sorties logiques qui remplaceront le comparateur ou la porte logique, en gardant l'interface...

[plopoi]

Oui j'ai aussi eu cette idée (plus ou moins) ...

Il me semblait toutefois plus facile de mettre en oeuvre d'autre solutions.

A ce stade de mes cogitations pour résumer les pistes suggérées plus haut :

- l'inversion du point "0" logique, dans ce cas en position de repos les deux bobines seraient alimentés au max.
Le probleme du "point creux" lors du passage de la position repos a un etat N disparait.
et le soucis risque de réapparaitre lorsque seule la bobine de centrage est alimenté.
Cela devrait toutefois devrait devenir beaucoup moins problématique puisque qu'alors les bobines seront normalement utilisé en mode oscillatoire pour animer un pattern.
L'inertie devrait compenser suffisamment ce point creux.

- Sinon il est aussi possible d'identifier le courant min pour assurer une excitation correcte de la bobine de commande et d'integrer ce delta dans gestion soft du DAC.
le point "0" correspondant alors a un niveau N sur la sortie du DAC (au détriment d'une perte de définition qui reste a définir)
Pour aller plus loin dans ce sens, on peut aussi imaginer programmer une séquence de commande particulière du scan lorsque l'on sort de cet état de repos.

- Enfin la solution qui est un compromis entre les deux, est d'utiliser le scan avec un point "0" correspondant a une valeur intermédiaire du DAC (centrage a 2.5V)

Dans tous les cas ces solutions ne demandent qu'a etre testées par différentes approches de la gestion logicielle du scanner.
Seule la position des miroirs sur l'axe et/ou des PAP l'un par rapport a l'autre est sera surement a retoucher.

j'attends de recevoir mes samples pour câbler et tester ces solutions.

Par contre une gestion plus électronique dans le sens de ce que tu as imaginé serait intéréssante pour passer intégrer un DAC standard dans le système.
Ce qui laisserait plus de liberté dans un upgrade vers des galvos en second temps.

En effet je regarde a réaliser le DAC de Favreau car il serait alors je pense assez simple de développer un lecteur de Trames ILDA pour l'arduino.
Ce qui me poserai soucis sur ce point est la réalisation du CI qui semble moins évidente que ce que je l'imaginais.

Enfin une autre option qui serait funky a tester pour la beauté du geste serait de passer les PAP en contre-réaction en leur ajoutant un contrôle de position ...

Bien entendu le plus simple serait de les remplacer par des galvo tout fait achetés et fonctionnels, mais c'est si c'est surement efficace, c'est aussi beaucoup moins fun

++ Plop

[Dark-Hole]

En ce qui concerne le point "0" je crois qu'il y a peut être encore une solution : utiliser la sortie analogique du DAC associé au moteur, et piloter la bobine de maintien avec un signal inversement proportionnel + un leger offset. En gros quand le DAC est à 0V, le courant dans la bobine de maintien est maximum, quand la tension du DAC augmente, le courant de maintien diminue, et lorsque le DAC sort son maximum, on a que le courant d'offset qui parcourt la bobine de maintien (pour quand même assurer une résistance mécanique minimum). ça me semble efficace et en plus simple à faire. Avec ça je pense qu'on a à peu près fait le tour des solutions, reste à voir ce qui sera le plus simple/plus efficace

Pour la détection de position, étant donné la vitesse de balayage, on peut opter pour un système dit "magnetic rotary sensor". C'est le système que je voulais utiliser pour mes scans, seulement le peu de capteurs que j ai trouvé ne montent pas à 30kHz, mais pour des pas à pas ça devrait passer.

Il y a moyen d'en avoir en échantillon gratuits ici : http://www.austriamicrosystems.com/Prod ... y-Encoders(déja commandé chez eux, très bons produits).
Regarde du coté de :
- AS5145 : Résolution de 12 bits, bande passante : 30.000 tr/min
- AS5134 : Résolution de 8-9 bits, bande passante : 82.000 tr/min

Il y a une sortie en PWM, on peut la filtrer et l'utiliser, mais le circuit de bouclage risque d'être assez complexe si tu veux une correction du genre Proportionnel Integral, Proportionnel Dérivé ou Proportionnel Intégral Dérivé (PID utilisé dans le schéma qu'on peut retrouvé sur le forum).

Voilà pour les infos que je peux te donner

[plopoi]

Arf des pistes intéressantes ... au moins pour le cotés sport cérébral de la réflexion ...

Sur le papier (enfin la video) le capteur que propose AMS est assez impressionnant
Pour le coup, avec un interfacage PWM on pourrait même envisager de gérer la contre réaction/asservissement encore une fois directement dans un code micro-controleur... (comme ici par exemple ).

Je serais curieux de savoir ce que d'autres membres du forum plutôt calés en électronique pensent de ces idées.
Enfin s'ils ont le courage de (re)lire l'ensemble des pavés que l'on a échangés depuis qq jours
Je soupçonne même que certains fan d'analogique peuvent être réticents devant une telle débauche de 0 et de 1

Ce qui est certains c'est qu'au final les perfs seront quoi qu'il en soit bien inférieures a celles d'un scanner a base de galva ...

Et puis certains ont déjà l'esprit bien occupé par des projets et réflexion plus ou moins hallucinant (laser au praséodyme, laser haute a tube haute puissance, TV mécanique, cam thermique, horloge atomique) une belle brochette de grands malades comme je les aiment

Plop

[Dark-Hole]

Oui ces capteurs sont intéressants, mais ce n'est pas ceux là les mieux... Honeywell en faisait des vraiment très bons... il y avait le HMC1501 et le HMC1512 qui est encore dispo mais aux US sur Newark.com, sinon le APS00B dispo sur Mouser, mais il faut en prendre minimum 33 pour avoir le fdp gratuit (ça représente une commande de 75€, ça fait 2,30€ le chip, mais c'est trop pour moi tout seul ) peut être une commande groupée?

En ce qui concerne ces chip, sortie analogique, bande passante de l'ordre du MHz (et non pas tr/min ou autre) ce qui est énorme, très grande résolution et boitier facile à souder... si d'autres membres pouvaient être intéressés ce serait génial car ça fait un super détecteur à moins de 5€ la paire, y a pas de soucis de luminosité, diodes différentes, mise en place...

Pour le PID numériquement c'est aussi une solution, j'ai l'AN quelque part mais j'ai encore pas pris le temps de la lire...

[blackbird]

Salut,

Bah, si vous faites une commande groupée je veux bien participer pour 10 pièces, je trouverai bien quand en faire avant la fin du monde !

A+

BlackBird

[Dark-Hole]

OK je prends note, je pense aussi en prendre 10 ^^ j'attends l'avis de plopoi et je crée le post dans la section appropriée

[plopoi]

Bah pour le APS00B va falloir me convaincre un peu d'autant que me concernant, a moins d'en griller bêtement plus de 50% je n'en aurait pas usage d'une dizaine ...

Plus globalement, mais cela tient surement à mon manque d'expérience sur ces composants,

Avec un peu de recul, j'ai des doutes sur les résultats que l'on peu attendre de ce type de capteur appliqués a un proto comme celui que je bidouille...
Notamment sur la bonne interaction de ces chip avec les PAP que j'utilise. (de part la faible ouverture angulaire des PAP et la taille surement modeste des aimants du rotor...)

Ces incertitudes me rendent vraiment hésitant a investir un vingtaine d'ecus que je pourrais surement dépenser ailleurs dans le proto ...

Dans un premier temps il me semble plus judicieux de valider ces points si j'arrive a dégotter qq samples chez AMS

[Dark-Hole]

Y a pas de problème, personnellement sa fait quelques temps que je dis qu'il m en faut donc je suis pas à ça près
Après justement l'intéret de ceux là (non pas que je cherche à en vendre, j ai pas d'action chez eux hein ) c'est qu'ils sont analogiques, alors que ceux de chez AMS sont numériques, donc ne détectent qu'une variation d'angle minimum. Or pour notre application on n'a pas besoin de 90° donc tu vas déjà perdre en résolution, et avec les PAP c'est encore pire, de l'ordre de 10 à 12° je pense Enfin effectivement c'est gratuit donc rien ne t'empêche de faire les tests
(Quand j ai fait les testes avec ceux là j ai utilisé du fil émaillé et je n'ai garder que les broches d'alim et PWM et coupé les autres, c'est plus simples à souder )

[plopoi]

Y a pas de problème, personnellement sa fait quelques temps que je dis qu'il m en faut donc je suis pas à ça près
Après justement l'intéret de ceux là (non pas que je cherche à en vendre, j ai pas d'action chez eux hein ) c'est qu'ils sont analogiques, alors que ceux de chez AMS sont numériques, donc ne détectent qu'une variation d'angle minimum. Or pour notre application on n'a pas besoin de 90° donc tu vas déjà perdre en résolution, et avec les PAP c'est encore pire, de l'ordre de 10 à 12° je pense Enfin effectivement c'est gratuit donc rien ne t'empêche de faire les tests
(Quand j ai fait les testes avec ceux là j ai utilisé du fil émaillé et je n'ai garder que les broches d'alim et PWM et coupé les autres, c'est plus simples à souder )

Les samples sont commandés ... je vais regarder ce que ça donne avec ça, ce sera toujours instructif ...

Par contre dixit les datasheet (pas toujours claires sur certains points) ... bien qu'analogique les APS00B ont une résolution angulaire annoncées a 0.05° ce qui est certes toujours mieux qu'AMS qui est a 0.089 (12 bits / 360°)


++ Plop

[Dark-Hole]

Tu as commandé les quels du coup?

[plopoi]

AS5145 ... c'est ce qui me semble offrir le meilleur compromis résolution/rapidité ...

[Dark-Hole]

Oui c'est ce que je pense aussi si ils sont aussi rapides que ce qu ils l'étaient y a un an tu devrais les recevoir d'ici la semaine prochaine

[plopoi]

Nickel ...

[mode Mylife ON]
ça m'évitera la tentation de tester ces composants avant d'avoir finit mes développement de négatif ... c'est que depuis que je me suis lancé la dedans j'ai accumulé pas mal de bobine de film qui attendent leur bain de D76 avec impatience [/mode Mylife]

[plopoi]

Négatifs développés et colis de AMS reçut ce matin par fedex ... c'est du service (très) rapide ...

Effectivement il va falloir s'amuser 2secondes pour souder ces composants correctement

Comme ont dit "yapuka" !

Si ça fonctionne, ça devrait aussi permettre au passage d'obtenir une image/idée de la réponse en fréquence des PAP utilisés comme galvo ...

[Dark-Hole]

tu habites à coté de la société c'est pas possible au moins en effet c'est du rapide!
Donc oui on attend tes résultats, peut-être que j'ai sous-estimé ces petites bêtes on verra ça (même si je ne m'attends pas à quelque chose d'exceptionnel au niveau de la résolution (je pense qu'aucun des chips que ce soit l'APS00B ou celui d'AMS n'arrivera au niveau de l'optique, malgré la simplicité de mise en place du magnétique , mais bon je crois que ce serait les premiers galvos qui ne soient pas optiques ou capacitif )

[plopoi]

Oui pour la livraison je suis encore tout bluffé !

Pour le reste, il y reste encore un peu de chemin a faire pour déjà arriver a quelque chose de fonctionnel, et cela abstraction faite de toutes considérations liées aux performances ...

Sinon j'ai retenu ton idée et repris un driver de diode pour l'alim. Un mix de celui de CHRS33 (Very chouette travail soit dit en passant) et d'un montage similaire que l'on m'a passé arrangé avec ce que j'ai sous la main ... J'ai encore qq trucs a debugger mais cela semble prometteur. En plus ça devrait permettre de gérer le courant de threshold des Galvo-PAP .

Je vais donc voir ce que ça donne dans un premier temps en boucle ouverte et si j'arrive a faire fonctionner la détection magnétique, je me lance dans un test de PID gérée par l'Arduino.
C'est vrai que cotés soudure, sur ce composant, je sens que ça va être une petite partie de plaisir ^^

A plus tard de folles aventures bricolesques ...

Plop

[Dark-Hole]

Sa me tarde de voir les premiers résultats! et oui pour ce qui est de la soudure, si tu n'utilises que le PWM, casse les autres broches (sauf celles de l'alim biensur ^^) et ce que j ai fait hier c'est prendre un support DIL8 tulipe, collé l'AMS dessus, et souder les 3 fils sur 3 des broches du support, comme ça sa fait un petit composant facile à fixer sur plaque de test ou autre par contre le pistolet à colle c'est pas non plus une partie de plaisir, mais j avais rien d'autre sous la main et dans le doute j'étais certains que ce serait un bon isolant