dsDRO

  • Auteur de la discussion Auteur de la discussion MaX-MoD
  • Date de début Date de début
Salut,

Je suis en train de negocier une fraiseuse, et je commence a regarder pour mettre un dro.

Et je voit que les pieds a coulisse de 800mm coutent 249€!!!

Autant dire que c'est hors budget.

Et je me suis dit, pourquoi pas des roues codeuses (comme dans les servos)?

On peu arriver a une définitions de malade (2000/trs)

Sa coute vraimment moins chere, et c'est pas plus dur a installer.

Niveau electronique c'est un pic et un LCD..

Des avis?
 
à 250€ on a des règles en verre (chinoises toujours, mais quant même bien plus précises) en quadrature.

Par contre, la mesure absolue des pac n'est... pas si absolue.
Si ils perdent l'alimentation by-by la position, il revient à 0 quant il est rallumé.
en revanche avec un encodeur il y a généralement une entrée d'index, qui permet de retrouver l'origine machine avec une grande précision.

Le problème des encodeurs rotatifs, on doit passer par un fil, câble etc. pour transformer le mouvement rotatif en linéaire. et on glissera certainement tôt ou tard. autant dire que c'est un peu la roulette quant à la précision sur les cotes obtenues... à moins d'utiliser des vis à billes, mais c'est plus le même budget.

Mais c'est vrai que l'entrée quadrature est un bonheur à utiliser avec un dsPIC : Je n'ai toujours pas résolu ce pb d'interruptions. :???:
enfin plus ou moins. je devrais avoir la soluce bientôt.
 
Bonjour,

wika58, tu cherche toujours une feuille de calcul Excel vitesses de coupe ?
J'en avais fait une, mais je l'avais perdu suite à un crach de disque dur.
Je viens de retrouver une sauvegarde.
Il y a les vitesses de coupe pour différentes qualités d'acier - Fonte - Bronze - Laiton - Aluminium, pour des outils en HSS et en carbure.

Je peux le mettre sur le forum ou te l'envoyer par email si tu le désire.

Daniel
 
Merci pour le fichier. C'est exactement ce que je cherchais...

Maintenant, il faut que je trouve les formules et/ou abaques pour les vitesses d'avance (fraisage) !!!.... :???:

Pour l'adresse e-mail, je regarde...

A+

P.S: Salut Max-Mod, t'a pu régler les problèmes?
Où en es-tu avec le module interface dsDRO?
 
aujourd'hui, je remet mon rapport de stage.
lundi je passe l'oral et basta!

ces deux dernières semaines ça a été la course, et j'ai pas avancé d'un chouya :sad:
lundi aprèm je devrais être en vacances, et donc enfin avoir du temps^^
 
Bon, stage fini, en plein déménagement.

du coup, pas d'internet pdt 15j...

Si qq1 aurait un PAC avec interface 7BCD ou 2*24 à me prêter, ce serait cool, car ce WE je vais bosser sur dsDRO, on est proche du but. Mais mon PAC a une interface peu connue donc... pas facile pour tester les interfaces les plus courants!


Pour me contacter, y'aura plus que mon mail imode:

max.mousset [a t] imode.fr

voila A+
Max
 
J'en ai bien un mais c'est un peu loin ... :roll:
Tu vois que j'aurqis du t'en déposer un en mai quand j'étais dans le sud ... :lol:
Je blague car je ne sais même pas auel protocole ils ont... :oops:

A propos, quelle est la valeur du (des) condo à mettre en lieu et place de la pile dans le PAC quand il est alimenté par un système externe?

Merci.

:wink:
 
condo, j'ai mi un petit 10µF électrochimique, ok mais le top cc'est 2-10µF en tantale + 100nF en céram.

T'avais raison pour mai... :???:

Je vais voir ce qu'il y a ds les grds surfaces du sud, et sur ebay.

A+
 
Bien, après de déboires avec les interruptions, l'horloge à quartz etc. j'ai enfin pu arriver à quelque chose.

L'horloge retenue est l'oscillateur interne à 7.37MHz, avec PLL16x => ~30MIPS
Bizarrement, la transmission série de ne pâtit pas de son imprécision. Je testerai sur plusieurs PIC sur une plage de température plus grande, mais il ne devrait pas y avoir de soucis avec la précision du FRC.

J'ai réussi à capturer les données transmises par le PAC casto, je corrige mon prog pour l'afficher maintenant.
On se rapproche du but :-D
 
Super :!:

Bonne continuation...

Pour le PAC, tu en as trouvé un :?:
Comment savoir le protocole du PAC que l'on a?
Je t'en enverrai bien un mais si 4'est pas le bon protocole, c'est pas très utile... :roll:
 
wika58 a dit:
Pour le PAC, tu en as trouvé un :?:
Pas cherché encore...

wika58 a dit:
Comment savoir le protocole du PAC que l'on a?
Si tu as une bonne boule (de cristal) ce sera facile :lol:

sinon, il faut utiliser digitrace pour analyser le protocole du PAC.
On peut enregistrer l'évolution des signaux clock et data, vous me l'envoyez je me charge du reste.
Mais pour identifier quel est le protocole, et comment régler dsDRO, je vais voir ce qu'il est possible de faire. Possiblement une autodétection du protocole.


wika58 a dit:
Je t'en enverrai bien un mais si 4'est pas le bon protocole, c'est pas très utile... :roll:
Plus simple, je finis le prog et tu teste le tout.
Une fois le PCB routé, il n'y aura guère d'autre évolution qu'au niveau software. Si ça marche nickel, alors pas de problème, sinon en fonction du problème rencontré, je t'enverrai un correctif du firmware ou alors je testerai chez moi avec un PAC sélectionné.

Mais il faut d'abord finir le routage.
 
Je viens de perdre 4h à essayer de comprendre pourquoi ça fonctionne en mode "DEbUG" avec l'ICD2, mais pas en "RELEASE"...

Je commence à en avoir sacrément marre :mad:
Je ne trouve pas de documents décrivant la différence (config, etc.) entre ces deux modes, ça me parait pourtant essentiel...


Si par hasard vous connaissez le p...
 
Les temps de traitement ne sont pas les mêmes en debug.
Tu n'as pas besoin des mêmes délais d'attente, là où en release, tu peux en avoir besoin !
C'est évident quand on y a déjà été confronter ...
A l'époque où les micros-controleurs peinait à 4 mhz, c'était façile de passer outre , mais maintenant avec des micro très rapide, il faut par exemple attendre un chouilla avant de passer à autre chose lorsque on change d'état un registre de port ou un registre quelconque.
Fais l'essai avec un debug en mode série, c'est beaucoup plus rapide que le débug et tu peux voir plus facilement où se situe ton pb.
Je parle d'une liaison série simple avec seulement un TX à 115200 bauds, pour éviter au maxi l'occupation cpu.
 
Merci de ces infos, bien sûr le débug est pas temps réel mais c'est pas ça.
La configuration du PIC change entre ces deux modes, et dnoc, ça ne fonctionne pas pareil dutout!
 
Si tu le dis ...
N'empêche que j'ai eu exactement le pb et que je l'ai résolu de la manière que je t'ai expliquer. C'était pour un TI msp430f169, mais le principe est le même pour un microchip, d'après mes essais in situ.
 
Moi, j'ai aussi eu plusieurs fois le même problème sur PIC entre le debug et le stand alone, mais à chaque fois les causes étaient différentes.

- Cas 1 : Mon reset se faisait bien lorsqu'il était piloté par l'ICD2, mais pas quand le RJ11 du programmateur est débranché : défaut sur ma carte au niveau du MCLR

- Cas 2 : Ca marche en debug, pas en normal : le résonnateur n'oscille pas. Le bit de gain était en XT, le passage en HS a réglé le pb.

- Cas 3 : Une de mes PIN (RB6/RB7) était utilisée par mon application (clavier). En mode debug, la pin était occupée à communiquer, en mode standalone, le clavier ne marchait pas...normal, l'ICD2 restait branché...

- Cas 4 : Bug au niveau du silicium d'un PIC 18F8720 (par la suite reporté par un errata chez Microchip). Le PIC a été reçu en échantillon alors qu'il était produit depuis qq mois. Le µC tournait 9 fois sur 10 avec l'ICD2, et jamais en stand alone. La faute à des registres masqués utilisés en debug, qui empêchait le PC de pointer sur l'adresse 0x0000.

A partir du PIC 16F si je me souviens bien, des registres spécifiques au debugage insitu (points d'arrêts, registres tampons) ont été implémentés.

Slts
 
Bon, je sens que je vais encore me creuser les méninges quelques temps pour régler le pb :smt017

Je vais déjà commencer par tout re-vérifier...
 
Ah oui, j'oubliais, j'ai déjà dû changer d'ICD2...la panne...reprise par MCP via le distributeur rapidement (il était neuf, ce qui ne m'aidait pas à debugger, j'avais confiance en lui...).

Courage, intelligence, abnégation, et...sommeil te permettrons de lever les doutes petit jet d'ail !

Vais me coucher aussi, :jesors23:
 
C'est vrai que çà m'a pas traversé l'esprit ! Mais il est évident qu'il faut vérifier piste par piste le cheminement des signaux. Un oscilloscope est bien pratique pour çà !
Depuis que j'ai le mien, ca me change la vie !
Maintenant, je commence à lorgner du côté des analyseurs logiques à 10/16 voies et 100 Mhz ...
Car, c'est pareil pour les timings de bus ou dialogue, un oscillo sert pas à grand chose dans ce cas là ...
 

Sujets similaires

bfabou76
Réponses
15
Affichages
5 027
fauxjetons
fauxjetons
L
Réponses
25
Affichages
1 403
bricoleur13
B
B
Réponses
3
Affichages
2 828
Quentin1377
Quentin1377
P
Réponses
26
Affichages
8 203
Patrick1340
P
V
Réponses
2
Affichages
654
vibram
V
S
Réponses
5
Affichages
368
Saverio
S
J
Réponses
1
Affichages
330
J

Sujets similaires

Retour
Haut