Et un projet de plus

[olive13]

Re salut :

Comme déjà dit après un bon bout de temps sans ma présence ici et le projet en pause, .... me re, de plus mon neveu est tombé
dans le laser pour des soirées et a trouvé mon projet ici .. lol. Du coups et bien il veut un prototype.

Voila donc un petit dépoussiérage de topic.
En ce qui concerne la conversion numérique à analogique actuel j'utilise un bon vieux réseau R2R qui prend pas mal de place !
j'ai donc trouvé des petit DAC 8 bits chez le chinois, mais qui ont la possibilités d’être montés en 16bits, ça devient intéressant !

Pour la source je pense prendre une petite source 50mW de notre ami ici car au moins pas de surprise sur la puissance et la possibilité de contact
si problème ..

Pour les galva / driver, vu que je ne sais pas trop et la je recherche vraiment du low cost, que donne les galva de 20kpps que l'on trouve sur ebay par exemple ?
Merci de vos réponses.

Bon année à vous tous
Yannick

Cool pour ton neveu
le PT-20K simple bobine est sans doute le meilleur compromis pour ton utilisation, mais tu seras vite limité en ecriture et en graphique....pour cette raison je te conseille du PT-30K double bobine qui reste l'un des meilleur rapport vitesse / prix, mais apres c'est une question de finances...

[xiantia]

he salut olive13, ça fait un petit moment.....

au niveau galva je n'est pas vraiment d’expérience, d'où ma question. Disons qu'au niveau graphique c'est pour
afficher 'Vive les marier' ce genre de truc en fait ...

Mais vue les vidéos que j'ai vu sur certain site avec du 20Kpps pour afficher "Good Luck" le rendu est vraiment très médiocre, tout clignote !
Je sais qu'il y 'a pas mal de choses à prendre en compte (logiciel, transfert, DAC, driver) mais vraiment la !!! puff null.

Si je prend l'exemple du "Good Luck" avec 20 points par lettre, ça nous fait 160 points à afficher , soit environ 8ms.
En comparaison avec du 25 images seconde sur une teloche, soit 40ms par image, la persistance rétinienne n'y vois que du feu ?

Peut être une donnée que je n'est pas pris en compte ?
Donc si on peut me dire qu'avec du 20 Kpps ça passe sans problème ce genre d’écriture , ... merci

le PT20 est au environ de 70€ , a combien on trouve le PT30 ?

bye
Yannick

[olive13]

Pour le 30k niveau tarif : Le double facile... mais rien a voir avec du 20k
Cela dit pour ecrire Good luck ça passe sans pb
Prends du vrai PT 20k @20°
Pas du pseudo 20 qui en realité ne depasse pas 15k car sur le net t'as vraiment tout et n'importe quoi

[julienlev]

sur les videos qui affichent good luck, ce qu'il faut prendre en compte c'est la carte de contrôle qui envoie l'image est elle très souvent limité vers 12/15kpps...

[xiantia]

Salut julienlev :

Oui les personnes sont toutes contentent de voir un effet graphique, alors que le montage ne fonctionne pas du tout comme cela devrait !
Bon donc pour faire mu muse et surtout ne pas prendre grand risque, car les drivers seront couplés à mon dac maison, des fois qu'une fausse manipe ...
les drivers à 20Kpps (20kpps à 20° comme dit dans les descriptions) doivent le faire.

Si des fois vous avez une paire de driver / galva d'occase .... même plus lent

Bye
Yannick

C'est bon de reprendre le topic
Merci Olivier pour le MP.

[julienlev]

sinon il existe des acnners 15kpps à 90e qui font 18kpps sur la mire ilda à +/-20°.
Il suffit de chercher scanner al15 sur google.

[xiantia]

Re a tous,

Aujourd’hui, c'est une autre question qui me fait écrire ceci :
Je suis toujours à la recherche de vitesse et de gagner du temps par ci par la.
Pour le DAC avec le PIC, je suis pratiquement au maximum de la vitesse (sauf changement du quartz). Par contre au niveau soft de contrôle je pense que je peut descendre l'occupation µP de l'ordinateur.
Voila donc, si vous pouvez me dire à combien est votre µP pendant un show :
- pourcentage,
- type de processeur (GHz et combien),
- si vous avez le rendu laser en même temps sur écran,
- le type de show (image ou juste des effets).

Merci a tous
bon week.

[xiantia]

Petit retour sur le DAC à base de µP PIC.

A cette instant celui-ci fonctionne sur des convertisseurs 8 bits R2R (voir vidéo / photo), d’où un DAC 2*8 Bits qui tourne à 67Kpps en Ethernet.
N'ayant pas de convertisseur 16 bits, je me suis simulé sous MPLab la gestion de deux dac 8bits pour le galva X et de même pour le galva Y, (soit 4 dac 8bits)
Je pensé perdre énormément du fait que l'on double le nombre de données par point.
Et bien non je passe de 67kpps (2*8Bits) à 59Kpps (pour du 2*16bits)

De plus après avoir remis le nez dans le code assembleur du PIC, j'ai repéré quelques endroits on je peut gagner encore du temps !
Inutile de dire qu'a ce genre de vitesse la simple µs est importante.

Au passage gestion du blancking TTL 3 canaux ....

Bye
Yannick

[xiantia]

De plus après avoir remis le nez dans le code assembleur du PIC, j'ai repéré quelques endroits on je peut gagner encore du temps !
Inutile de dire qu'a ce genre de vitesse la simple µs est importante.

Voila petit samedi tranquille, code assembleur modifié et 9.8µs de gagnés.
Cela ne veut pas dire que le DAC va plus vite au niveau Kpps.
Mais que, de la réception de la trame réseaux à la lecture de la première donnés de cette trame, je gagne 9.8µs.

Cordialement
Yannick

[kl79]

je ne poste pas beaucoup sur ton projet, il faut bien avouer que je ne comprend pas grands choses ^^

MAIS je te lis quand même et je trouve super ce que tu es en train de faire. Fais tout de même attention a ne pas trop donner d'infos ( a priori c'est bon ) des "semi pro" auraient vite fait de te prendre ton idée et de la revendre.

[xiantia]

Merci Kl79,

y'a rien de vraiment compliqué au niveau point à afficher, on prend le point X/Y, on le transfert sur deux ports du µP (sorties numérique) et on le passe en analogique.

La où ca devient plus pointu c'est la liaison réseau Ethernet.

Bien que cela est faux on peut distinguer deux types de trames réseau :

1 - "Et qui connaît ce nom Dupon François (Ip : 192.168.1.2) ? car je ne connais pas son adresse physique (MAC : 12:19:CE:86:9E:89), je ne peut lui envoyer du courrier (paquet réseau)"
2 - "Maintenant que je connais ton adresse, je t’envoie du courrier (données) "

Dans l’envoi des données (2) on peut aussi distinguer 3 sous famille.

3 - "tu habites toujours à cette adresse ?" (ping)
4 - "je t’envoie du courrier mais je ne sais pas si tu vas le recevoir (UDP)"
5 - "je t’envoie du courrier en recommandé (TCP)"


On se rend compte qu'avec cette petite présentation, je doit (moi récepteur) passer mon temps à regarder ma boite aux lettres et regarder les demandes (1) et (3), et y répondre.
Pour la réception du courrier standard (4) , il faut juste que j’exécute les demandes ! (pas de réponse comme quoi j'ai bien reçu, mais je doit faire cela).

Du coups nous avons ici 3 types de lettre à interpréter. Nous humains nous le faisons tout les jours, mais pour un micro processeur c'est pas la même.
De plus, dans ce genre d'application on recherche la vitesse, c'est comme si nous étions devant la boite aux lettres, impatient de voir arriver le facteur, ouvrir avec
un temps record cette lettre et faire ce qui y est demandé (1) (3) ou (4), puis recommencer.

En conclusion : le plus dur ici, c'est d'apprendre au µP de "lire" la lettre aussi rapidement qu'il le peut, sinon la boite se remplie et déborde !

Dans la version précédente du DAC, je regardé si la lettre est de type (1) (c'est rare) puis du type (2) dans le dernier cas : la lettre contient le type (3)(rare aussi) puis (4), je perd donc du temps car c'est le type (2) et (4) qui nous intéresses dans cette application une simple inversion de test et voila.


Cool non ?

bye
Yannick

[julienlev]

merci pour d'avoir pris du temps pour nous expliquer tout ça, c'est vrai que je suis ton rpojet avec attention mais des fois je décroche un peu...
Après pour ta question sur l'utilisation processeur lors d'un rendu de show, je ne peux pas trop t'aider pour le moment mais je peux te dire que j'ai déjà fait tourner des shows sur eepc d'il y a 5ans qu ece soit avec he-lasercsan ou quickshow...
donc ça ne consomme pas énormément. Et par exemple sur he-laserscan il y a une option que te perme de couper complètement l'affichage de ton écran afin d'optimiser le rendement du pc sur le rendu laser.

[xiantia]

Et par exemple sur he-laserscan il y a une option que te perme de couper complètement l'affichage de ton écran afin d'optimiser le rendement du pc sur le rendu laser.

Voila ont parlent bien de la même chose, si on commence à afficher à l’écran plus au laser, le temps µP augment fortement, d'où l'option.
Te rappels tu la taille de la fenêtre de rendu, en gros le pourcentage, environ la moiter de l’écran, moins/plus ?

En ce qui me concerne je fait tourner les tests du DAC sur une vieux coucou a 1Ghz avec 500Mo de ram !
Sans le rendu je tourne a 10/20% µP a environ 30Kpps si j'active le rendu la paff 100%, sachant que la carte vidéo n'a pas d’accélération graphique non plus.

Pour les explications basics pas de problème, pis c'est toujours bon à savoir . Mais je vous réserves une explication sur la synchronisation ordinateur/DAC qui pour un premier test en réel fonctionne plutôt pas mal !
Merci

Bye
Yannick

[xiantia]

Salut les potos,

Comme dit précédemment, voila quelques explications sur les problèmes que l'ont rencontrent dans la synchronisation entre l'ordinateur qui envoi les données et le DAC.

Avant de rentrer dans le sujet, il me faut expliquer comment le DAC fonctionne actuellement.
Celui-ci passe sont temps à attendre des données, il ne fait aucune demande à l'ordinateur puisque cela pose d'autres problèmes :
- Ajouter une information réseau (DAC -> ordinateur) chiant à faire, la flemme !
- quel temps de récurrence ?
- augmentation de l'occupation réseau ?
- que ce passe t-il si la demande croise l'arriver des données ?
- ....


Le plus simple est un DAC qui attend ! Une sorte de DAC "open loop".

Le programme principal pourrait se présenter comme suite :

Code: Select all

DEBUT
    INITIALISATION GENERALE
    
    POUR TOUJOUR
    DEBUT
        TANT QUE (pas de donnée)
        ALORS
            // on boucle ici, tant que rien recu niveau reseau.
        FIN TANT QUE

        SI (données est du type : ARP)
        ALORS
            // gerer ARP, pas le sujet ici.
        FIN SI

        SI (données est du type : PING)
        ALORS
        // gerer PING, pas le sujet ici.
        FIN SI

        SI (données est du type : LASER)
        ALORS
            TANT QUE (donnée laser)
            ALORS
                // set galva X
                // set galva Y
            FIN TANT QUE // boucler
        FIN SI
    FIN 
FIN

Après ce blabla, le soft envoi des données LASER à inter-val régulier, prenons 1 seconde, c'est a dire que toute les secondes
l'ordinateur envoi 700 points LASER par exemple.

Première question : Le DAC reçoit-il réellement les données toutes les secondes ou ce temps est-il approximatif ?
- Après modification du DAC pour qu'il passe à 1 ou 0 une sortie X de µP pour voir ces créneaux à l'oscillo, j'ai ce type de chronogramme :

synchro.png

(1) le DAC attend
(2) j'ai des données
(3) traitement des données
(1') j'attend

A ma grand satisfaction ce temps est plutôt régulier, ici à 35ms (entre (1) et (1') )
De plus au niveau soft (ordinateur) il est facile de corriger une fluctuation , mais chute
comme me l'a suggérer une personne de ne pas trop en dire

Par contre on voit que le DAC passe pratiquement 1/3 de sont temps à attendre (le niveau 1 est 3 fois plus grand que le niveau 0, tronqué sur l'image), Pourquoi ?
- le DAC va trop vite à lire les données LASER, Il a fini de lire (donc envoyer les données aux galva)
bien avant la réception des 700 données suivantes, tout simplement.

Nota 1 : 35ms pour 700 points ça fait quoi en fait ? ben, 0.035 secondes / 700 pts = 0.00005 secondes pour 1 point, soit pour une secondes, 1/0.00005 = 20 000 points/seconde (20 Kpps).
Nota 2 : pourquoi 700 points ? et bien une trame réseaux fait en principe 1500 octets par défaut (MTU pour les puristes), donc 700 points sur 8 bits ca fait 1400 octets, reste
100 octets qui sont utilisés pour le réseaux proprement dit.
Cette valeur de 1500 est une limite, sinon les donnée sont coupées en plusieurs block. je me vois mal programmer le DAC pour qu'il "concatène" les block !!!
Nota 3 : Pourquoi 1/3 de sont temps ? simple, la les données sont à 20Kpps, comme le DAC a une vitesse de 67Kpps, ça fait pratiquement 1/3.
tout ce retrouve et j'aime ça !!


Bon ,nous avons un DAC qui va trop vite pour des données à 20Kpps, il faut le ralentir entre chaque point, d'où un nombre X d’itérations pour intercaler une tempo
afin qu'il lise pratiquement la dernière donnée LASER juste avant la réception des 700 points suivants. diminution de (1 ou 1').

problème:
- Si ont le ralenti trop, c'est pas bon, car le buffer de réception va arriver à saturation.
- Si ont le ralenti pas assé, il y aura un temps d'attente (1), qui en fait est pas si grave (une autre idée mais chute ...)

Voici pour rappel la courbe qui donne le nombre d’itération en fonction du Kpps (1/Kpps). (Ralentissement du DAC)

kpps-temps.png

(cette courbe est propre à mon type de DAC !)


Je termine pour ce soir ce mini "tuto" sur la synchronisation, il faut juste retenir que :

- le DAC va trop vite (en full vitesse il passe à 67Kpps, 2*8bits)
- il faut le ralentir en fonction du KPPS désiré (itération variable de la tempo)(paramétrable)
- diminuer au maximum le temps d'attente du DAC, (1). Se qui revient à le synchroniser.
- ...

et tout cela de façon dynamique, et oui si je veut du 30Kpps, il faut :
- recalculer le temps entre les "block" (trame) de 700 points (gestion soft ordinateur)
- ralentir le DAC, oui mais moins qu'a 20Kpps ! (encore gestion ou calcul au niveau ordinateur)

(Rappelez vous de ces deux derniers points pour ceux qui suivent)

Bye
Yannick

Ps : si du monde a suivit ? à 20Kpps j'ai un réseau a 42Kbyte/seconde, normal ?

[xiantia]

héhé vu le silence, j'ai du en perdre pas mal sur la route ....


Bye
Yannick

[kl79]

c'est tellement ça !

[xiantia]

Aller pas grave de ne pas suivre, le but c'est que ça marche !

Dans l'un de mes dernier post je disais que l'ordinateur avait des envois de trames plutôt
pas mal (intervale régulier), mais cela ne me suffit pas, car si on fait autre chose sur l'ordinateur ces temps devient vraiment irréguliers
a cause de l'utilisation d'un simple "timer" interne qui est très sensible à l'occupation µP ordinateur.

Voila ce que donne à 33 Kpps et que l'on redimensionne la fenêtre par exemple. 33Kpps jamais atteins en plus !
Que fait le DAC en interne ? et bien comme lui il est calé a 33Kpps, il à fini de lire la trame avant la réception de la prochaine, d'où une attente,
comme je n'est pas de blanking sur l'oscillo ça me fait un gros spot au milieu (remise a 0/0 des galva si pas de données) avec une intensité proportionnel
au temps d'attente. (Vu sur oscillo puisque le "moteur" actuel fonctionne avec un timer).

kpps-without-correction.jpeg

Après le codage d'un nouveau "moteur" qui corrige les défauts par l'ordinateur , voila toujours à 33Kpps se que ca doit donner ...

kpps-with-correction1.jpeg

Des que le system détecte que la vitesse a un gros problème (colonne 20), il corrige la trame suivante en l'envoyant avant le temps prévu, ce qui fait plus de donnée
(colonne 21), (idem colonne 22 / 23 et 33 / 34). C'est comme une sorte de balance qui s'auto équilibre pour que la "lecture" reste en moyen à 33Kpps.

Toutes les autres colonnes ont une correction, mais le system la compense largement à 33,020Kpps, du coup on ne vois rien.
Oui j'ai des points en plus (20pts) je sais pas pourquoi en fait ?
La le DAC fait un coups de spot sur les colonnes inférieurs à 33Kpps et qui reste tout de même supérieur de 32.85Kpps comparé au 32.35Kpps du graphique d'avant.

Reste à tester ce nouveau "moteur" sur le DAC maintenant pour voir le rendu oscillo ....
Bye
Yannick

[julienlev]

je ne sais pas si ça va t'aider dans ton developement mais sache que sur les dac standard quen il a fini d'afficher les infos qu'il a reçu et tant qu'il n'a pas reçu de nouvelles infos, au lieu d'attendre sans rien faire, il refait la derniere trame reçue.
voilà mon grain de sable a l'édifice!

[olive13]

Plus qu'a essayer en direct live donc

[xiantia]

Salut Julienlev,

Oui on me l'a déjà dit que les DAC retracés les dernières données si aucunes de nouvelles reçues, c'est peut-être toi d’ailleurs

Après test de la nouvelle monture et prise de temps a l'oscillo, ...
le DAC attend 40µs ! même pas un point Laser à 20kpps, donc ce faire chier à retracer un point ... de plus y'a rien à faire si ce n'est que le laisser la où il est

Par contre j'ai un temps de 500µs qui est pratiquement in-compressible (traitement de la trame réseaux)(de la réception à la première info Laser) , si ce n'est que de quelles 50µs tout au plus en modifiant le code assembleur du PIC.

Même si le nouveau "moteur" ne fait pas grand impression à première vue, celui-ci corrige tout de même la stabilité des informations,
par contre le réseau après c'est pas moi qui gère (autre trame réseaux en provenance du system d’exploration, temps du routeur , ... )
il y a donc des fluctuations ..

Je suis tout de même content du résultat, à force de gratter à droite et à gauche, ça fait un joli DAC lowcost, me tarde de lui coller un set de galva au Q pour voire se que ça donne ! si ça se trouve ces 500µs ne seront même pas visible !

Bye
Yannick

[xiantia]

Et bien moi je me dit bravo !!!

Comme je l'ai dit hier, j'ai codé un nouveau "moteur" de gestion du DAC, qui fonctionnait pas trop mal. Par contre je me suit dit qu'il y avait
bien beaucoup de calcul pour pas grand chose (et les résultats varie en fonction de la puissance de l'ordinateur).

Le nuit porte conseil, donc reprise ce matin du moteur, modification, plus simple .... et test sur des trames static (pas un shows, juste un cercle
qui émule les problèmes de synchronisation).

Les résultats sont au rendez vous, du coup, je lui ais fait lire un vrais show de 50Mo (Bad Apple pour ceux qui connaissent)
sur mon vieux coucou d'ordinateur (1Ghz / 500Mo ram) sans rendu écran pour l'instant et la

- image stable, (sur oscilloscope),
- pas de spot de partout, (juste le petit point au centre, invisible si blanking),
- 50Kpps sans problème,
- auto-configuration du DAC,
- moins de 1% processeur,
- réseaux stables à 60/61 Kbyte/seconde (pour du 30Kpps)

Donc congratulation pour le moteur ! reste le code assembleur à modifier pour gagner quelques µs ...

Bye
Yannick

[olive13]

Excellent .... hate de voir tourner ton petit DAC en live sur projo
Tiens au sujet de ta 1ere phrase...ça me rappele une époque des guignols que tu as du connaitre également et l'interessé disait: "Et bien je le note, et je m'en felicite"

[julienlev]

bien joué!
ça fait toujours plaisir quand on trouve des solutions qui fonctionnent!

[xiantia]

Merci à tous,

Moi aussi j'ai hâte de lui coller une paire de galva
Me reste tout de même quelques trucs à faire comme la sortie en +/- 5v du DAC pour attaquer les drivers.
Actuellement la sortie est en 0-5V avec un 0° à 2.5v.

Bye
Yannick

[xiantia]

Re,

comme je me rapproche de plus en plus sur la gestion des scanners (interface DAC / driver), je me suis mis à relire
la norme ILDA sur les formes des signaux à envoyer.

Pour les galva, soit le X- / X+, ok , signaux différentiels, c'est a dire que non référencé à la masse , avec +/-10v crête à crête, soit +/-5v par "fils"

Par contre pour le blanking / intensité, la il parle de 0 / +5v analogique et aussi différentiel ???
- Si je suis bien, cela veut dire que cette entrée est bien différentielle, avec une différence de potentiel allant de 0 à +5v mais jamais négative ?
- Intensité, c'est quoi ? elle est pas tout ou rien cette entrée ou alors elle influe sur les 3 sources ? Dans ce cas a quoi sert les RGB +/- ?

Merci de votre éclaircissement ...

Bye
Yannick

[olive13]

Bien vu pas de signaux symetriques en blanking juste 0/+5v
intensity blanking est du monochrome ou un melange des signaux R+G+B.Il peut piloter par exemple un DPSS, si tu utilises un projo en vert seulement

[julienlev]

sur le blanking il y a 2 choses: le signal ilda génér par le dac qui lui doit être symétrique, et le signal blanking appliqué à la source qui lui n'est plus symétrique grace a une carte de désymétrisation et varie donc entre 0 et 5v...
voilà une version française de la norme ilda, si ça peu aider:
http://laboutiquelaser.fr/fr/content/11-cablage-ilda

[xiantia]

Re,

Merci Julien pour ton information en ce qui concerne le blanking ..

Intensité: Signal symétrique +2.5/-2.5V analogique formé par la superposition des signaux R, V et B. Ce signal est régulièrement utilisé sur les lasers mono couleurs. Une différence de potentiel de +5V allume à fond la source et une et une différence de -5V éteint complètement la source. Les sources étant modulé en 0/5V il faut utiliser une carte de désymétrisation entre l'arrivée du signal ILDA et le blanking de la source.

Dans la norme ILDA qui date de 1999 on trouve :

This is intended for use by projectors which use an
intensity signal or scanner blanking. This is a unipolar
analog signal whose voltage range is 5V peak-to-peak
differential.
A differential voltage level of 0V indicates zero
intensity and that the beam is fully blanked. A
differential voltage level of +5V indicates full intensity
and that the beam is not blanked.
A differential voltage of +5V occurs if the normal
signal line has a voltage level of +5V with respect to
the voltage level of the inverted signal line. When
compared to the ground level of the differential driver,
the voltage level of the normal signal line shall be
+2.5V and the voltage level of the inverted signal shall
be -2.5V.

et dans la même de 2006 :

This is intended for use by projectors which use an intensity signal
scanner blanking. This is a unipolar analog signal whose voltage range
is between 0V and +5V differential.
A differential voltage level of 0V indicates zero intensity and that the
beam is fully blanked. A differential voltage level of +5V indicates full
intensity and that the beam is not blanked.

J'en conclu que la norme ILDA prévoit un signal différentiel comme pratiquement tout les autres.
Nous somme donc en présence d'un signal de 0 à 5V différentiel (jamais en négatif).
Soit du +/-2.5V par fil par rapport à la masse.

Ma question est donc close par le fait de l'explication de Julien

Les sources étant modulé en 0/5V il faut utiliser une carte de désymétrisation entre l'arrivée du signal ILDA et le blanking de la source.

Comme mon DAC sort directement 0 ou 5V ( TTL ) je peut donc attaquer directement le blanking de la source.
Ce qui est dommage, c'est que la norme ne précise pas la puissance (I) max utilisable par chaque sortie.

Bye
Yannick

[julienlev]

ben peut importe ce que peut fournir ton dac, la pluspart des entrées de sources sont directement sur un ampli op, du coup ça consomme rien...

[xiantia]

ben peut importe ce que peut fournir ton dac, la pluspart des entrées de sources sont directement sur un ampli op, du coup ça consomme rien...

Oui c’était bien mon idée, mais vaux mieux une confirmation des personnes qui utilisent / connaissent les drivers. Merci Julien

Bye
Yannick

[xiantia]

Salut,

Cette nuit j'ai eu une révélation .... non pas vu "Djésus"

Le DAC fonctionne, c'est prouvé, mais en fait si tout s'emboîtés normalement il ne devrait pas.
Pour faire simple :
- j’envoie des données par le réseau Ethernet (700pts toutes les 35ms, se qui donne 20Kpps)
- le DAC lit les points à intervalle régulier de 50µs (20kpps), il met donc aussi 35ms pour tout lire.

Hors le DAC à un temps de gestion des données avant la lecture effective, par exemple 400µs.
De ce fait le DAC se "décale" au fur et à mesure de 400µs. Il en résulte que le buffer de réception doit être plein
à un moment donné.

J'ai pris des mesures relativement précises en espionnant ce que fait le DAC.

chronogram.png

Sans rentrer dans le détail:
- Sur la voie A on observe des "top" de 40µs répété toutes les 35ms, qui sont les demandes de nouvelle donnée au module réseau.

- Sur la voie B, le niveau logique est à 1 pendant 325µs. Cela indique que le DAC est en train de décortiquer la trame réseau.
Le niveau passe à 0 (repere 2) lorsque le dac est certain que les données réseau sont du type LASER.

J'observe aussi un temps de 150µs avant l’envoi effective des données au galva. Pendant ce temps je lit juste 3 octets en mémoire réseau.
(Le nombre de points à lire, ainsi que le temps d'exposition d'un points).
Ce temps de 150µs me parait bien grand si je le compare aux 325µs de gestion où la il y pas mal de vérifications !

Après une modification j'ai passé ce temps à 100µs (50µs de gagné c'est toujours ça).

Enfin bon tout ces temps ajoutés (40+325+100=465µs) c'est pratiquement le temps de 10 points à 20kpps.
Le DAC devrait se décaler de 10 points à mesure du temps et arriver à saturation !

Pourquoi ce DAC fonctionne t-il alors ?

Pour compenser ce temps je devrais lire les points un peut plus rapidement. Cela veut dire que je ne doit pas lire les points toutes les 50µs (20Kpps)
mais, 465/700pts = 0.67µs, soit 50-0.67 = 49.33µs.

Je reprend espoirs, et oui, pratiquement 0.7µs d'erreur c'est vraiment pas grand chose, puis c'est aussi le temps de ma temporisation
qui ajoute 0.8µs par itération.

De plus il suffit que le réseau ai un décalage de 465µs au niveau envois des données pour que tout rentre dans l'ordre
(occupation µp ordinateur, occupation carte réseau ordinateur, traitement par le routeur, ...)

J'avais remarqué qu'avec le nouveau "moteur logiciel" de gestion, les temps était plus précis au niveau envois des données (35ms),
mais quelques fois le DAC planté, en voila la cause.

Aujourd’hui, je vais tester une chose, remplir le buffer de réception mais pas trop affin que le DAC ai toujours des choses à lires ....

Bye Yannick.

[julienlev]

bon comme d'hab je n'ai pas grand chose a ajouter a ton post, mais dans tous les cas je le suis avec interet!

[miikkkllll]

bon comme d'hab je n'ai pas grand chose a ajouter a ton post, mais dans tous les cas je le suis avec interet!

+1, j'ai l'impression de retourner en cours d'informatique industrielle, mais en beaucoup plus poussé ici. C'est très intéressant .

[xiantia]

Merci de votre intéressement ...

bon sinon l'histoire du buffer .... un échec ! Je m'en douté un peut en fait ... comme il n'y a pas de retour DAC -> ordinateur, je ne sais pas vraiment
à quel instance le buffer arrive à 80% par exemple. Du coups les données qui ne peuvent être en buffer sont simplement ignorées et perdues.
Le fait de faire un retour, me fait gérer une trame réseaux avec tout le temps de gestion au niveau du PIC

Je pense que je cherche peut-être un peut trop la perfection et que le spot du laser et de vrais driver /galva vont peut-être gommer les quelques imperfections restantes.

Bye
Yannick

[olive13]

Je pense aussi , mais je comprends bien car tu sembles perfectionniste..ce qui est un compliment bien entendu
Il faudrait voir sur un DAC comme un Easylase par exemple si celui çi gère du temps réel ou légerement différé avec un buffer également.
J'ai tjrs pensé qu'un buffer etait utile seulement si on apporte une correction sur la trame comme avec un Algorythme ou code de redondance cyclique largement utilisé en transmission de données, mais comme je suis très loin d'etre expert dans ce domaine, je m'intérroge.