Hello,

Je vais essayer de répondre plus ou moins dans l'ordre.

Concernant la réalisation d'une carte "générique" n'est pas l'idéale et je parle en connaissance de cause. Tu as toujours des problèmes, ca n'est pas comme tu veux, etc... Il y a des cartes de développement pour cela (ce que j'utilise pour développer avant de faire une version "final"). Ceci vaut aussi pour le nombre d'entrées analogiques, on veut piloter une machine CNC et non réaliser un multimètre numérique. Il faut toujours dissocier ce qui est utile du superflu et de ce qui sera vraiment utilisé.

Le meilleur moyen pour compléter ensuite les performances d'une telle carte est de prévoir un bus de dialogue (SPI, I2C, etc) pour ajouter facilement des cartes plus ou moins exotique, le tout en réalisant un mini protocole générique pour commander ce type de carte.

Tu as déjà réalisé un projet complet? Car dans le cahier des charges et les spécifications tu as tout qui est mis... . Je profite en même temps pour clarifier un point... L'acronyme CDC que j'ai utilisé signifie "cahier des charges" et n'a rien a voir avec l'USB, désolé pour la confusion.

Concernant le fait que tu n'a pas réalisé de CNC il y a en effet certains signe qui ne trompe pas... Typiquement tu veux absolument utiliser de FET et ton PIC. Je te le dis directement c'est une perte de temps et d'argent même si tu va payer des FET 2-3CHF pièces tu en aura pour finir pour 40CHF sans le reste et pour ne pas avoir de performance.
Egalement tu mets en avant le fait de réaliser ensuite un firmware qui utilisera toutes les sorties pour piloter 6 ou 8 axes... Il faut le programme qui le gère, mais ce n'est certainement pas le plus difficile à faire. Le plus dure sera la mécanique et c'est la que d'avoir faite une te permettrais de savoir que déjà une fraiseur 3axes pour tourner bien demande beaucoup de réglages et de compromis de rigidité/vitesse/précision/cout. L'ajout d'un 4ème axe n'est pas évidant, je n'ai pas encore pu le faire.
C'est la même chose pour une découpe fil chaud, mais en pire, car le but est d'avoir quelque chose de très léger avec le moins de frottement, donc peu de rigidité, vu qu'il n'y a presque pas de contacte pour découper ca fonctionne ainsi.
L'ajout d'un 5ème serait peut-etre bien, à voir si Jérôme est d'accord de le développer ou s'il décide de rester sur 4.

J'espère ne rien avoir oublié et apporter plus d'éléments afin de préciser pourquoi je suis retissant pour certaines de tes idées. Mais je reste ouvert à tes propositions et aussi remarques pour que l'on puisse penser au mieux le tout.

A+
Xavier

Salut

« Tu veux absolument utiliser de FET et ton PIC. » en fait je pensais plus au IC utilisé par la MM2001 qui n’est pas cher. Le but c’était de laisser l’option de faire du low cost. Mais en fait ce n’est pas forcement utile.

Est-ce que tu crois que les optocoupleurs sont utile ? Si oui il faudrait en mettre partout. Je pense que ce n’est pas forcement utile.

Pour les connecteurs des moteurs je pensais mettre
2 fils pour la commande du moteur (step/dir) PORTD et PORTB
I2C pour l’extension
Alim (GND, +5V)
On/Off pour couper l’alim des moteurs. ( en commun)
Sync

Je pense que sur les autres connecteurs (Chauffe, entrée analogique) ça serrait bien de mettre de l’I2C.

On pourrait aussi ajouter 2 ou 3 connecteurs I2C

Je propose ça.

Moteurs:
+5V
RD0, RD2, RD4, DR6, RB2 (step)
RD1, RD3, RD5, DR7, RB3 (dir)
GND
RB0 (I2C)
RB1 (I2C)
Sync
RE2 (On/Off)

Chaufe:
RC2
+5V
GND
RB0 (I2C)
RB1 (I2C)

Entrée TTL:
RB5
RB6
RB7
RA4
RA5
RE0
RC6
RC7
+5V
GND
RB0 (I2C)
RB1 (I2C)


Entrée analogique :
RE1
+5V
GND
RB0 (I2C)
RB1 (I2C)



Sortie TTL :
RB4
RC0
RC1
RE3
+5V
GND
RB0 (I2C)
RB1 (I2C)

I2C (3 fois):
+5V
GND
RB0 (I2C)
RB1 (I2C)

LCD:
RA0
RA1
RA2
RA3
+5V
GND


Quelques questions
1) Est-ce que tu es d’accord de faire une carte compatible avec mon firmware ?
2) Est-ce qu’on ajoute un connecteur ICSP ?
3) Je pense que ça serrais bien de faire un circuit simple face t’en pense quoi ?
4) qu’est ce que tu pense de la répartition des IO du pic ?
5) on pourrait ajouter des résistances pour des optocommutateurs pour les fins de course. T’en pense quoi ?



A+

Cyrus

Salut,

Pourrais tu en dire un peu plus sur ce que fait ton firmware ? J'ai beau lire les quelques lignes postées sur ton site, je n'y comprends pas grand chose alors que je suis sur que dans ta tête c'est très clair... o

Salut Jérôme

Bon quand j'ai le temps je regarderais ce texte de plus près.
Alors en gros c’est un port //. Tu envois des donnée via l’USB au microcontrôleur et lui, une fois les données reçu les transmet sur les ports. Par exemple tu choisi d’envoyer les données sur le port D alors à chaque fois que le microcontrôleur reçoit un paquet il place les données tour à tour sur le port D. Le truc c’est que tu peux choisir le délai qu’il y a entre chaque changement de données. Donc par exemple tu configure le firmware pour travaillé à 100KHz et ensuite tu envois les données qui vont apparaître sur le port a une fréquence de 100KHz. Tu peux monter jusque à environ 400KHz

Il y a aussi d’autre fonction qui te permette de configurer le firmware. Je t’invite à lire la doc complète.

Est-ce que c’est plus claire maintenant ?

Cyrus

Si j'ai bien compris c'est une simple "passerelle" réceptionnant des données et les renvoyant sur une sortie du microcontroleur à un rythme configuré dans le firmware ?

Du coup, y'a t'il une buffer pour les données émises par le PC, un buffer pour les données envoyer aux PC ?

Si ce firmware reste très généraliste, ça veut dire que toute fonction spécifique à la découpe CNC est déporté sur le logiciel côté PC, c'est ça ?

Salut

« Si j'ai bien compris c'est une simple "passerelle" réceptionnant des données et les renvoyant sur une sortie du microcontrôleur à un rythme configuré dans le firmware ? » C’est très exactement ça !

Il y a un buffer de 12 paquets dans le microcontrôleur affin d'éviter les latences dû au changement de paquets ce qui permet de fonctionner sans interruption du flow de donnée. Coté PC ca dépend du driver.
Tout se fait du coté du PC. A mon avis le microcontrôleur n'est pas fait pour faire des chose compliqué. C'est grâce à un firmware ultrasimple que j'arrive à ces vitesses.

Est-ce que tout est clair ?

Cyrus

Hello,

Je vais répondre à tes différentes questions Cyrus et à toi de me dire ce que tu en penses.

L'option "low cost" avec des IC comme sur la MM2001 je pense que tu le trouve aussi inutile, donc on abandonne ceci et également tout pilotage d'étage de puissance ou l'on doit réaliser les séquences pour piloter les moteurs pas à pas autrement que avec les STEP/DIR.

Les optocoupleurs peuvent être utile, mais en tout cas pas la tout tu les as mis, ou du moins s'ils sont seulement la...

Pour quoi utiliser 2 ports du PIC pour commande les 4 moteurs, on peut mieux optimiser sur un seul port 8bits. Il faudra donc réfléchir au quel utiliser.

Je suis partant pour du I2C, il est un peu lent, mais simple à mettre en oeuvre et l'on peut facilement ajouter des cartes sans être limité en nombres. Je ne suis par contre pas du tout pour faire un module de chauffe qui se plug dessus, car ceci demande une carte, un microcontroleur, etc de plus. Il faut également prévoir un temps de développement supplémentaire et aussi tous les bug que ca va engendrer à cause des transmission, parasite, etc. Donc une perte de temps inutile, car on a assez de IO sur le PIC pour tout intégrer, y compris pour une entrée analogique et des entrée/sortie TTL.

Je ne voit pas à quoi sert le "SYNC", peux-tu m'éclaircir la dessus?

Concernant l'attribution des pattes du PIC, c'est inutile pour le moment, tu brule les étapes. On a pas encore spécifié exactement ce que l'on veut. Tu place la charrue avant les boeufs! De plus c'est pas vraiment lisible comme tu présentes le tout, c'est certainement très clair pour toi, mais pour moi qui te lit c'est un peu du chinois, même si je connais pas trop mal le domaine, enfin je l'espère .

Voici la partie pour tes dernières questions.
Une carte compatible avec ton firmware, pourquoi par, mais il faudrait que je regarde plus en détaille, car comme te l'a déjà fait remarqué Jérôme on a du mal à comprendre vraiment son principe, utilité et fonctionnement.
L'idée du connecteur ISCP est bonne, à avoir si l'on dispose d'assez d'IO et de place sur la carte, mais je suis assez pour.
L'idéal est de le faire en simple face et avec des "grosses" pistes, mais vu ce que l'on désire intégrer et les dimension réduite qu'il faut pour ce type d'adaptateur c'est très difficile voir même impossible, donc on verra ce que l'on peut faire et comment. Il serait peut-etre même intéressant de sous-traiter pour faire des circuits pro, tout dépend du nombre de personne intéressé à cette version de l'adaptateur.
Pour la répartition des IO du PIC j'ai déjà donné mon avis... C'est beaucoup trop tôt!!! On verra ca plus tard.
La de nouveau tu brule les étape, qu'est ce qu'on s'en fou pour le moment de savoir si on va avoir une résistance la ou la... On verra une foi toutes les spécifications et cahier des charge fait. Il faut aussi que tu m'explique l'utilité de tes optocommutateurs pour des fin de courses...

A+
Xavier

Salut

« L'option "low cost" avec des IC comme sur la MM2001 je pense que tu le trouve aussi inutile, donc on abandonne ceci et également tout pilotage d'étage de puissance ou l'on doit réaliser les séquences pour piloter les moteurs pas à pas autrement que avec les STEP/DIR. » OK

« Les optocoupleurs peuvent être utile, mais en tout cas pas la tout tu les as mis, ou du moins s'ils sont seulement la... » ?????????????????????????????????

« Pour quoi utiliser 2 ports du PIC pour commande les 4 moteurs, on peut mieux optimiser sur un seul port 8bits. Il faudra donc réfléchir au quel utiliser. » En fait c’est toi qui parlais de 5 axes. Donc 4 moteurs sur le port D et le dernier sur le port B. Je les places là pour garantir la compatibilité avec mon firmware.

« Je suis partant pour du I2C, il est un peu lent, mais simple à mettre en œuvre et l'on peut facilement ajouter des cartes sans être limité en nombres. Je ne suis par contre pas du tout pour faire un module de chauffe qui se plug dessus, car ceci demande une carte, un microcontrôleur, etc. de plus. Il faut également prévoir un temps de développement supplémentaire et aussi tous les bugs que ca va engendrer à cause des transmissions, parasite, etc. Donc une perte de temps inutile, car on a assez de IO sur le PIC pour tout intégrer, y compris pour une entrée analogique et des entrée/sortie TTL.»
En fait il faut réfléchir à comment on veut gérer ça. Ce que je propose c’est de faire un connecteur avec I2C alim et le pin RC2 qui est relié au module PWM du 4550. Il n’y a donc pas de microcontrôleur en plus si l’on veut faire un module de chauffe basic mai il y a la possibilité de faire quelque chose de plus évolué si nécessaire du style on envoie la température cible par I2C et la carte se débrouille pour atteindre la température. Il faut aussi penser à la compatibilité avec les fraiseuses. Par exemple piloter un relais ou autre commande de puissance pour la broche.



« Je ne vois pas à quoi sert le "SYNC", peux-tu m'éclaircir la dessus? »
Moi non plus ! Mais je l’ai vu sur plusieurs étages de puissance. Je crois que c’est un pin à mettre en commun pour synchroniser les horloges des contrôleurs.


En fait j’ai mal lu son message qui proposait ça
# 8 entrées TTL (ou optocouplées)
# 1 entrée analogique 0/5V
# 10 sorties STEP/DIR (5axes)
# 4 sorties TTL
# 1 sortie PWM
# afficheur LCD (4*20)
J’ai cru que c’était le cahier des charges que tu proposais et je me suis basé la dessus. C’est vrai qu’il faut d’abord que l’on se décide sur ce que l’on veut mettre sur la carte. Pour moi ce qui est écrit la dessus c’est OK. Même si j’ai un peut de peine à voir l’utilité du LCD. De toute façon on à un pc allumé avec les milliers de pixels en couleurs alors pourquoi un LCD externe ?

Cyrus

Hello,

Les optocoupleurs ne serve à rien pour les signaux de fin de course qui seront 5V. Il sont utile que pour isoler galvaniquement le micro et PC de la partie puissance. Mais dans notre ca je pense que ceci sert à rien, c'est de composant inutile d'après moi.

Le 5ème axe devrait être géré par Jedicut, sinon c'est inutile, donc vu que ca serait un axe secondaire, on pourrait imaginer le mettre sur le I2C, mais à voir si on a assez de patte de libre sur le PIC ont peut l'intégrer. Pour la découpe fil chaud, je verrais bien un plateau tournant sur la table ou alors un axe de rotation dans le sens de la longueur de la table.

Je comptais également utiliser le PWM pour la chauffe c'est plus propre, mais par contre je ne vois vraiment pas pourquoi le mettre sur l'I2C, la il faut que tu m'éclaire. Le truc de vouloir avoir une température réguler, c'est bien, mais dans la pratique c'est inutile, voir inutilisable, en effet le fils n'a pas la même température sur tout ca longueur, et dépends aussi du matériaux, de ca taille, etc... Donc ca ne servira à rien, mais comme on aura le I2C rien n'empêche que tu teste une foi. Mais il faudra également prévoir un mini-protocole simple pour le I2C et généraliste, mais ceci peut-etre implémenté par la suite.

Je suis d'accord avec la compatibilité avec une fraiseuse, mais il y a pas besoin d'avoir 36000 IO pour piloter des relais ou autres. Le jour ou tu auras construit ta CNC tu comprendra que ca n'est pas utile.
La broche pourra être pilotée par le même signal que celui de la chauffe...

Je suis OK pour le signal SYNC, c'est rien de plus de le mettre, le problème est qu'il faut vraiment comprendre à quoi il sert pour le programmer juste ou alors il faudra pouvoir le paramétrer depuis le PC et que ceci reste en EEPROM dans le PIC.

Ce que j'avais fait étais juste une petite mise en forme des fonctions, IO, etc, mais en tout cas pas un cahier des charges. La il faut y passer un peu plus de temps.
Ce qu'il faut faire, c'est le compléter et nommer toutes les fonctions, etc.
Exemple j'ai mis 8entrée TTL, donc on a
- 4 origine machine (OM)
- 1 fin de course
- 2 bouton (+ et - pour chauffe) (ceci est mieux que le variateur analogique, car si on passe de auto à man la chauffe on risque d'avoir des surprise vu que le pot aura une valeur différente que la consigne envoyé par le PC, ce qui n'est pas le cas avec des boutons.
- arrêt d'urgence
- sécurité capot (pour fraiseuse par exemple)
- aux

Donc la on se rend compte qu'il faut 10entrées pour gérer le tout :-s. Il faut donc revoir les fonctions, car dans un mode ou l'autre elles peuvent servir à rien (fraiseuse versus découpe fils chaud) ou alors trouver un moyen d'utiliser une entrée analogique avec un pot pour piloter le fils chauffant sans avoir de problème lors de passage en manuel ou auto.

Il y a encore pas mal de boulo pour mettre au points cet adaptateur, mais je crois que l'on part vraiment juste.

A+
Xavier

PS: Jérôme tu nous gère le 5ème et 6ème axes? X(

Salut,

Je pense que c’est bien que la carte gère le 5eme axe directement. On a tellement peut de puissance sur le microcontrôleur que gérer un autre moteur par I2C est difficile. Suivant comment le 5ème axe devra tourner avec les autres et l’on ne peut pas se permettre de perdre trop de temps dans les transmissions des données.


« Je comptais également utiliser le PWM pour la chauffe c'est plus propre, mais par contre je ne vois vraiment pas pourquoi le mettre sur l'I2C, la il faut que tu m'éclaire. » Je pensais juste faire un connecteur chauffe évolutif. Mais en fait si l’on ajoute des connecteurs I2C indépendant c’est bon

« Je suis OK pour le signal SYNC, c'est rien de plus de le mettre, le problème est qu'il faut vraiment comprendre à quoi il sert pour le programmer juste ou alors il faudra pouvoir le paramétrer depuis le PC et que ceci reste en EEPROM dans le PIC. »
Je crois qu’il faut juste les relier ensemble. Pas besoins de passer par le microcontrôleur mais il faut éclaircie cette affaire.

Je penche plus pour 5 OM si l’on a 5 axes
Est-ce que tu crois que c’est vraiment utile de mettre des boutons pour régler la chauffe ? C’est pas plus simple de tout faire depuis le PC en automatique?
L’arrêt d’urgence je ne le ferrais pas sur une IO mais plutôt sur le reset. Le pin de reset refait commencer le programme depuis le début quoi qu’il arrive. C’est pas le cas pour un pin. Par ex si l’on est bloqué à quelque part dans le programme.

Cyrus