je ne suis donc pas totalement fou, je n'avais pas la possibilité à l'origine
https://lujji.github.io/blog/stlink-clone-trace/
La suite dans quelque jours lorsque j'aurais recu le vrai ST link ou lorsque j'aurais trouvé qqun pour me faire la modif
https://lujji.github.io/blog/stlink-clone-trace/
La suite dans quelque jours lorsque j'aurais recu le vrai ST link ou lorsque j'aurais trouvé qqun pour me faire la modif
Sinon tu peux utiliser le ST-Link de ta carte Nucleo.
https://www.sevenwatt.com/main/picos-arm/picos-arm-lpc810-swd-jtag-with-nucleo-stm32/
https://www.sevenwatt.com/main/picos-arm/picos-arm-lpc810-swd-jtag-with-nucleo-stm32/
exact, j'ai essayé cet aprem, j'arrivais bien à envoyer le sketch mais impossible d'avoir le debug...
Je re tente demain... ca demande un peu de patience !!
Voici des copies d'écran de ma configuration avec une dicovery stm32f01.
Il n'y a pas de grosse différences.
Même pour programmer mes cartes Olimex, je me sert de STlink d'une carte discovery, sur la liaison SW, j'ai aussi NRST de câblé.
Pour tes problèmes de rapidité, c'est un peu normal tes fonctions run_ccw et Run_cw te bouffent des milliers de cycles.
De même au lien d'utiliser GPIO_WriteBit(GPIOA, GPIO_Pin_3, 0) tu peux utiliser GPIOA->BRR = GPIO_Pin_3 ou pour GPIO_WriteBit(GPIOA, GPIO_Pin_3, 1) GPIOA->BSRR = GPIO_Pin_3
C'est beaucoup plus rapide il n'y a pas d'appel de fonction.
Il n'y a pas de grosse différences.
Même pour programmer mes cartes Olimex, je me sert de STlink d'une carte discovery, sur la liaison SW, j'ai aussi NRST de câblé.
Pour tes problèmes de rapidité, c'est un peu normal tes fonctions run_ccw et Run_cw te bouffent des milliers de cycles.
De même au lien d'utiliser GPIO_WriteBit(GPIOA, GPIO_Pin_3, 0) tu peux utiliser GPIOA->BRR = GPIO_Pin_3 ou pour GPIO_WriteBit(GPIOA, GPIO_Pin_3, 1) GPIOA->BSRR = GPIO_Pin_3
C'est beaucoup plus rapide il n'y a pas d'appel de fonction.
Salut CNCSERV,
Pour les fonctions run_cw & CCW, je m'en sers uniquement au démarrage pour vérifier que mon moteur tourne correctement. Elles seront enlevée dans la version finale. je vais faire des tests sans pour voir l'incidence.
Ok je vais faire les changements pour le Writebit, je ne connaissais pas le BRR et BSRR, interessant.
Pour la config, j'ai aucun souci pour envoyer le sketch que ce soit avec le clone st link chinois ou avec le st link du nucleo mais c'est le trace/debug qui ne fonctionne pas. Et je vois qu'il n'est pas activé dans ta config.
J'ai commandé un vrai ST link v2, j'espere que je vais m'en sortir avec.
Hier j'ai recu mon keypad, j'ai donc activé (et tout fonctionne, c'est deja ca !) les ecrans de selection de pas et de longueur de filetage.
Je vais tester tes conseils d'ici ce weekend et je vais voir ce que ca donne
Mais j'ai besoin du debug pour comprendre ce qu'il se passe dans les variables car dans l'état actuel le stepper ne tourne que dans un sens et ne s'arrête jamais. A voir donc
edit:
config:
Noir sur le reset et gris sur PB3 pour le SWO
Les cases Reset and run et Download to flash sont cochées ou décochées selon mais cela ne change pas mon souci de debug (j'ai lu qu'on devait les décocher pour le debug)
Pour les fonctions run_cw & CCW, je m'en sers uniquement au démarrage pour vérifier que mon moteur tourne correctement. Elles seront enlevée dans la version finale. je vais faire des tests sans pour voir l'incidence.
Ok je vais faire les changements pour le Writebit, je ne connaissais pas le BRR et BSRR, interessant.
Pour la config, j'ai aucun souci pour envoyer le sketch que ce soit avec le clone st link chinois ou avec le st link du nucleo mais c'est le trace/debug qui ne fonctionne pas. Et je vois qu'il n'est pas activé dans ta config.
J'ai commandé un vrai ST link v2, j'espere que je vais m'en sortir avec.
Hier j'ai recu mon keypad, j'ai donc activé (et tout fonctionne, c'est deja ca !) les ecrans de selection de pas et de longueur de filetage.
Je vais tester tes conseils d'ici ce weekend et je vais voir ce que ca donne
Mais j'ai besoin du debug pour comprendre ce qu'il se passe dans les variables car dans l'état actuel le stepper ne tourne que dans un sens et ne s'arrête jamais. A voir donc
edit:
config:
Noir sur le reset et gris sur PB3 pour le SWO
Les cases Reset and run et Download to flash sont cochées ou décochées selon mais cela ne change pas mon souci de debug (j'ai lu qu'on devait les décocher pour le debug)
Dernière édition:
Dernière édition:
Oui oui, ca fait quelques heures que je passe la dessus et essayé pas mal de choses, je commence à me poser des questionsOui pourtant il fonctionne
Dans Output tu as bien Debug information de coché ?
Pourtant là j'ai une config qui se rapproche de ce que tout le monde semble avoir
Avec le St-link2 on peut effectuer deux opérations différentes :
1- Le débogage qui permet de visualiser tout les variables que tu définis ainsi que le déroulement de ton programme, et pour cela ton St-link « clone » fera très bien l’affaire.
2- Le trace qui permet l’accès à quelques fonctionnalités avancées comme le suivi des exceptions, les interruptions, les registres d’état et les périphériques hardware (USART, GPIO, SPI…) et plein d’autres choses sympa , et particulièrement le ITM qui est utilisé généralement pour rediriger le « printf() » . Pour activer le trace, l’utilisation du pin SWO ( PB3 ) est obligatoire mais malheureusement n’est pas disponible sur le connecteur du St-link « clone ».
Donc pour pouvoir activer le trace tu dois utiliser le st-link présent sur une carte Discovery ou Nucleo, ou si tu aime t’amuser avec la soudure CMS tu as l’option de souder un petit bout de fil sur le pin 31 (PA10) du stm32f103 présent sur le st-link, et pour des raisons pratiques, tu peux sacrifier une broche 5V sur le connecteur pour souder l’autre bout du fil.
1- Le débogage qui permet de visualiser tout les variables que tu définis ainsi que le déroulement de ton programme, et pour cela ton St-link « clone » fera très bien l’affaire.
2- Le trace qui permet l’accès à quelques fonctionnalités avancées comme le suivi des exceptions, les interruptions, les registres d’état et les périphériques hardware (USART, GPIO, SPI…) et plein d’autres choses sympa , et particulièrement le ITM qui est utilisé généralement pour rediriger le « printf() » . Pour activer le trace, l’utilisation du pin SWO ( PB3 ) est obligatoire mais malheureusement n’est pas disponible sur le connecteur du St-link « clone ».
Donc pour pouvoir activer le trace tu dois utiliser le st-link présent sur une carte Discovery ou Nucleo, ou si tu aime t’amuser avec la soudure CMS tu as l’option de souder un petit bout de fil sur le pin 31 (PA10) du stm32f103 présent sur le st-link, et pour des raisons pratiques, tu peux sacrifier une broche 5V sur le connecteur pour souder l’autre bout du fil.
Dernière édition:
Merci Saci, ça confirme ce que je pensais mais j'ai toujours l'erreur de no synchronisation et je ne sais pas d'où cela vient...
J'ai commandé un vrai st link je vais voir si cela résoud le problème mais je n'y crois pas trop. J'ai testé le SWV sur une fréquence d'horloge allant de 8 à 72Mhz par incrément de 8mhz et sans succès
J'ai commandé un vrai st link je vais voir si cela résoud le problème mais je n'y crois pas trop. J'ai testé le SWV sur une fréquence d'horloge allant de 8 à 72Mhz par incrément de 8mhz et sans succès
Ta vitesse SW est surement trop élevée, ces petits debugger ne sont pas très fiable, 1MHz c'est quasi leur limites.
Pour un outil plus sérieux il y a les JLink de Segger qui sont très bien. La version EDU est a 60€
Leur système RTT est mieux fait que le SWO (qui est supporté aussi) car ca ne tue pas le temps réel autant que le SWO qui est une horreur de ce coté.
Pour un outil plus sérieux il y a les JLink de Segger qui sont très bien. La version EDU est a 60€
Leur système RTT est mieux fait que le SWO (qui est supporté aussi) car ca ne tue pas le temps réel autant que le SWO qui est une horreur de ce coté.
Si tu utilises la carte Nucléo, Je t’invite à vérifier que les deux bridges SB12 et SB15 sont bien dessoudés. ( se trouvent sur le dos de la carte, voir photo )
Pour la vitesse, je ne peux pas dire si c’est un problème ou pas, de mon coté j’utilise exactement le même Clone à 1$ que le tien ( sur la photo un peu plus haut ) et ça fonctionne correctement à 4MHz même avec un noyau RTX exécutant 8 taches simultanément, après reste à discuter la fiabilité des composant sur ces clones !
Pour la vitesse, je ne peux pas dire si c’est un problème ou pas, de mon coté j’utilise exactement le même Clone à 1$ que le tien ( sur la photo un peu plus haut ) et ça fonctionne correctement à 4MHz même avec un noyau RTX exécutant 8 taches simultanément, après reste à discuter la fiabilité des composant sur ces clones !
J'ai le message en bas No syncronization
mais je viens de voir que j'ai bien le bridge de soudé entre SB12 et SB15...ce serait une piste
Je vais regardé car lorsque j'avais regardé le user manuel, j'ai pas vu que ceux ci devaient être dessoudés
Edit: OK c'est clairement indiqué pour le SB12
http://www.st.com/content/ccc/resou...df/jcr:content/translations/en.DM00105823.pdf page 18
pour le SB15 c'est moins évident. Je voulais juste vérifier avant de d'enlever un composant que je ne pourrai pas forcément remettre par la suite
Je viens de tester en les enlevant, pas plus de succès ;(
et lorsque je passe par le soft ST Link utility:
mais je viens de voir que j'ai bien le bridge de soudé entre SB12 et SB15...ce serait une piste
Je vais regardé car lorsque j'avais regardé le user manuel, j'ai pas vu que ceux ci devaient être dessoudés
Edit: OK c'est clairement indiqué pour le SB12
http://www.st.com/content/ccc/resou...df/jcr:content/translations/en.DM00105823.pdf page 18
pour le SB15 c'est moins évident. Je voulais juste vérifier avant de d'enlever un composant que je ne pourrai pas forcément remettre par la suite
Je viens de tester en les enlevant, pas plus de succès ;(
et lorsque je passe par le soft ST Link utility:
Dernière édition:
L'explication saci la peut-être donné :
En revanche l'évaluation des variables et les points d'arrêt doivent fonctionner, c'est déjà pas mal.
Edit: il semble que SWO soit le fil gris donc tu l'as visiblement branché
En revanche l'évaluation des variables et les points d'arrêt doivent fonctionner, c'est déjà pas mal.
Edit: il semble que SWO soit le fil gris donc tu l'as visiblement branché
Dernière édition:
Tous les essais que j'ai mis ici sont avec le ST link incorporé à mon STM32F411 donc pas de clone chinois.
je vois quelqu'un demain qui va se pencher sur le cas et me montrer les bases du debugger comme je ne suis pas habitué à cet objet
Par la meme occasion, j'essaierai le code avec les modifitcations que tu m'as suggerées
Voici le code:
Pour moi, c'est à la ligne 115 qu'on definit la valeur à 72Mhz
je vois quelqu'un demain qui va se pencher sur le cas et me montrer les bases du debugger comme je ne suis pas habitué à cet objet
Par la meme occasion, j'essaierai le code avec les modifitcations que tu m'as suggerées
Voici le code:
Pour moi, c'est à la ligne 115 qu'on definit la valeur à 72Mhz
Tout semble correcte, ton horloge système est à 72Mhz, le trace fonctionne correctement on utilisant ton fichier poster et le clone st-link.
fais encore une autre tentative avec le stlink de la carte Nucleo ( toute en gardant les deux bridges déssoudé ! ) et puis essai avec les deux fréquences 72Mhz puis 36Mhz.
fais encore une autre tentative avec le stlink de la carte Nucleo ( toute en gardant les deux bridges déssoudé ! ) et puis essai avec les deux fréquences 72Mhz puis 36Mhz.
j'insiste sur le fait que tout fonctionne bien pour l'envoi etc.
Le sketch de test:
mes branchements:
et ma config:
(essayé avec 72 et 36 comme conseillé)
j'avais vu un tuto ou il disait qu'il fallait changer la size du dernier printscreen, 2 ou 1, j'ai vu que tu as laissé 2. Là encore j'ai testé les 2, sans succes
Le sketch de test:
mes branchements:
et ma config:
(essayé avec 72 et 36 comme conseillé)
j'avais vu un tuto ou il disait qu'il fallait changer la size du dernier printscreen, 2 ou 1, j'ai vu que tu as laissé 2. Là encore j'ai testé les 2, sans succes
Alors, j'ai créé un autre projet pour tester ton code posté, et là tout fonctionne correctement.
une piste à creuser : avec un multimètre, vérifier que la liaison est bien établie entre le PB3 ( broche 38 ) du STM32F103 sur la carte de test, et le PA10 ( broche 31 ) du STM32F103 sur le St-link.
une piste à creuser : avec un multimètre, vérifier que la liaison est bien établie entre le PB3 ( broche 38 ) du STM32F103 sur la carte de test, et le PA10 ( broche 31 ) du STM32F103 sur le St-link.
Je ne comprend pas, normalement la visualisation des variables et les points d'arrêt doivent largement suffirent pour déboguer ton programme.
Je ne sais pas trop ce que les infos dans Debug viewer vont t'apporter de plus
Pour ton application il faudrait une routine à 50kHz minimum pour avoir un résultat satisfaisant. Tu ne vas pas écrire une ligne a chaque fois !
Je ne sais pas trop ce que les infos dans Debug viewer vont t'apporter de plus
Pour ton application il faudrait une routine à 50kHz minimum pour avoir un résultat satisfaisant. Tu ne vas pas écrire une ligne a chaque fois !
Dernière édition:
Bonsoir,
je me suis bien plongé dedans aujourd'hui, on m'a filé un coup de main pour le trace: mon STm32 chinois n'était pas bien soudé, et le PB3 n'était donc pas relié. Je ne sais pas si cela était visible au multimetre mais l'oscillo de la personne qui m'a aidé l'a bien détecté.
Le debug et le trace fonctionne parfaitement apres changement du board et modification du pin 1 du CN4 car je n'avais pas compris qu'il fallait 1 alim et VCC, j'avais juste mis l'alim...
Concernant le projet en lui meme, j'ai un peu avancé mais de maniere pas tres scolaire. j'ai passé 2h a essayé de trouver la frequence du APB1 et je n'ai pas réussi. Du coup j'ai trouvé des exemples sur internet et j'ai adapté les valeurs en essayant de trouve run juste milieu entre l'amperage, la vitesse etc. Sauriez-vous me dire comment je trouve cette frequence? j'ai vu les histoires de divide clock etc. je n'ai pas trouvé la valeur du prescaler, je sais juste que j'ai un SYSCLK à 72Mhz.
J'aimerais être plus ua point la dessus car je pense que cela influe sur le souci que je vous présente dessous en video.
J'ai rajouté un if dans le cas ou le codeur ne bouge pas. je ne sais pas si c'est une bonne méthode car cela augmente le temps de traitement mais j'avais des problemes de stabilité à l'arret. C'est soit ca, soit des "&&" dans les deux autres conditions.
Ensuite j'ai essayé de rentrer les bons parametres d'avance, step etc.
Je ne suis pas loin du but mais je dois encore ajouter des conditions lorsque je pilote mes moteurs à savoir respecter la longueur du filetage et ne pas depasser les fins de course car je n'ai pas mis de capteur, un jour qui sait. Mais avant les capteurs; j'aimerais deja prévoir ca au niveau software.
je ne me fais pas trop de souci sur ca, il faut juste que je me mette dessus une fois que le moteur sera parfaitement piloté.
Donc voici une video qui montre mon probleme. Je pense que la cause est la frequence interruption mais je ne serais pas surpris que d'autres erreurs n'arrangent rien.
Les symptomes: lorsque je tourne le codeur "rapidement" dans un sens ou l'autre, le moteur tourne "rapidement" dans un sens ou l'autre mais il y a toujours quelques pas de décalage avant le changement de sens. lorsque je tourne le codeur lentement, là le décalage est nettement plus important, presque 1 tour. Sans compter que le mouvement n'est pas fluide à basse vitesse mais pas sur que je puisse remedier à cela.
Voici le code mis à jour:
je me suis bien plongé dedans aujourd'hui, on m'a filé un coup de main pour le trace: mon STm32 chinois n'était pas bien soudé, et le PB3 n'était donc pas relié. Je ne sais pas si cela était visible au multimetre mais l'oscillo de la personne qui m'a aidé l'a bien détecté.
Le debug et le trace fonctionne parfaitement apres changement du board et modification du pin 1 du CN4 car je n'avais pas compris qu'il fallait 1 alim et VCC, j'avais juste mis l'alim...
Concernant le projet en lui meme, j'ai un peu avancé mais de maniere pas tres scolaire. j'ai passé 2h a essayé de trouver la frequence du APB1 et je n'ai pas réussi. Du coup j'ai trouvé des exemples sur internet et j'ai adapté les valeurs en essayant de trouve run juste milieu entre l'amperage, la vitesse etc. Sauriez-vous me dire comment je trouve cette frequence? j'ai vu les histoires de divide clock etc. je n'ai pas trouvé la valeur du prescaler, je sais juste que j'ai un SYSCLK à 72Mhz.
J'aimerais être plus ua point la dessus car je pense que cela influe sur le souci que je vous présente dessous en video.
J'ai rajouté un if dans le cas ou le codeur ne bouge pas. je ne sais pas si c'est une bonne méthode car cela augmente le temps de traitement mais j'avais des problemes de stabilité à l'arret. C'est soit ca, soit des "&&" dans les deux autres conditions.
Ensuite j'ai essayé de rentrer les bons parametres d'avance, step etc.
Je ne suis pas loin du but mais je dois encore ajouter des conditions lorsque je pilote mes moteurs à savoir respecter la longueur du filetage et ne pas depasser les fins de course car je n'ai pas mis de capteur, un jour qui sait
. Mais avant les capteurs; j'aimerais deja prévoir ca au niveau software.je ne me fais pas trop de souci sur ca, il faut juste que je me mette dessus une fois que le moteur sera parfaitement piloté.
Donc voici une video qui montre mon probleme. Je pense que la cause est la frequence interruption mais je ne serais pas surpris que d'autres erreurs n'arrangent rien.
Les symptomes: lorsque je tourne le codeur "rapidement" dans un sens ou l'autre, le moteur tourne "rapidement" dans un sens ou l'autre mais il y a toujours quelques pas de décalage avant le changement de sens. lorsque je tourne le codeur lentement, là le décalage est nettement plus important, presque 1 tour. Sans compter que le mouvement n'est pas fluide à basse vitesse mais pas sur que je puisse remedier à cela.
Voici le code mis à jour:
C'est pas trop mal, reste a affiner.
Il faudrait que t'arrive a mesurer la frequence d'interruption et la durée de de la fonction. Il n'y a pas beaucoup de flottants mais quand je t'ai donné le code je pensai au f04 avec FPU.
En examinant le code, ils y a plusieurs choses qui ne vont pas :
Tu ne fais pas les même conditions de déplacement sur le CW que sur le CCW.
Avec le code que je t'ai donné, le changement de Dir se fait en même temps que le Step.. c'est très mauvais
Je te fait les corrections cet aprèm.
Dernière édition:
La configuration de l’horloge est détaillée dans le fichier « systeme_stm32f10x.c »
Ligne 987, fonction « SetSysClockTo72(void) » :
Le AHB prescaler ( HCLK ) à la ligne 1022 : RCC_CFGR_HPRE_DIV1
Le APB1 prescaler ( PCLK1 ) à la ligne 1028 : RCC_CFGR_PPRE1_DIV2
Le APB2 prescaler ( PCLK2 ) à la ligne 1025 : RCC_CFGR_PPRE2_DIV1
Les valeurs possibles sont définies dans « stm32f10x.h » à partir de la ligne 1724.
Ton TIM2 est configuré pour générer des interruptions à une fréquence de 4Khz :
F_TIM2= 72000000 / (71+1) / 250 =4000.
Donc une fréquence step de : 4000 / 2 = 2KHz.
A cette fréquence le moteur tournera à : (2000/500)*60=240rpm
@CNCSERV te propose d’aller beaucoup plus haut en fréquence afin d’avoir un résultat satisfaisant.
Note : le délai minimum de quelques µs après changement de direction est à respecter, tu peu gérer ça dans ta routine d’interruption du TIM2 en rajoutant d’autre(s) valeur(s) de cycle par exemple « cycle=2,3,… ».
Ligne 987, fonction « SetSysClockTo72(void) » :
Le AHB prescaler ( HCLK ) à la ligne 1022 : RCC_CFGR_HPRE_DIV1
Le APB1 prescaler ( PCLK1 ) à la ligne 1028 : RCC_CFGR_PPRE1_DIV2
Le APB2 prescaler ( PCLK2 ) à la ligne 1025 : RCC_CFGR_PPRE2_DIV1
Les valeurs possibles sont définies dans « stm32f10x.h » à partir de la ligne 1724.
Ton TIM2 est configuré pour générer des interruptions à une fréquence de 4Khz :
F_TIM2= 72000000 / (71+1) / 250 =4000.
Donc une fréquence step de : 4000 / 2 = 2KHz.
A cette fréquence le moteur tournera à : (2000/500)*60=240rpm
@CNCSERV te propose d’aller beaucoup plus haut en fréquence afin d’avoir un résultat satisfaisant.
Note : le délai minimum de quelques µs après changement de direction est à respecter, tu peu gérer ça dans ta routine d’interruption du TIM2 en rajoutant d’autre(s) valeur(s) de cycle par exemple « cycle=2,3,… ».
On est d'accord que dans ce cas, comme le prescaler div est différent de 1; alors le timer clock est multiplié par 2 ? il me semble que c'est ce qui est écrit dans le manuel. Cela est concordant avec ce que tu mets
Merci en tout cas, c'est exactement ce que je cherchais comme explication et que je ne reussissais pas à trouver.
C'est pas trop mal, reste a affiner.
Il faudrait que t'arrive a mesurer la frequence d'interruption et la durée de de la fonction. Il n'y a pas beaucoup de flottants mais quand je t'ai donné le code je pensai au f04 avec FPU.
En examinant le code, ils y a plusieurs choses qui ne vont pas :
Tu ne fais pas les même conditions de déplacement sur le CW que sur le CCW.
Avec le code que je t'ai donné, le changement de Dir se fait en même temps que le Step.. c'est très mauvais
Je te fait les corrections cet aprèm.
Oui oui les conditions font parties des choses que je dois revoir en effet ! Je voulais terminer par cela une fois que j'avais mes interruptions correctement configurées
Je suis de festival aujourd'hui mais je vais reflechir à cette histoire de cycle pour intégrer le changement de dir avant le step mais comme ca la solution ne me saute pas aux yeux. J'essaie de trouver et je comparerai avec ce que tu vas me proposer
J'ai changé mes variables prescaler et count mais pour j pense qu'il faut d'baord que j'ai le bon code pour les changements de direction avant de voir cela.
Tu parles d'une routine à 50Khz donc un step tous les 25Khz ? ca donne 40us ce qui est toujours dans les clous par rapport aux capactés du driver. Je vais tester cela des que mon changement de dir est en bonne et due forme
edit: mon prochain projet j'incluerai cubemx et HAL
j'ai tenu à ne pas m'en servir sur ce projet car cetait le premier et je voulais impérativement comprendre ce qu'il se passait. maintenant que j'y vois plus clair, je vais pouvoir m'aider de cet outil qui simplifie pas mal la tache pour ce genre de chose...
Pour une fréquence d’interruption de 50Khz, c'est-à-dire
F_TIM2= 72000000 / (71+1) / 20 =50000 Hz
le moteur tournera à : (25000/500)*60=3000 rpm
C’est un peu élevée comme vitesse ( à vérifier en fonction des capacités de ta configuration « moteur-driver-alimentation » ), @CNCSERV aurait plus de connaissances là-dessus et il peut t’en parler.
Je propose plutôt une fréquence d'interruption de 20Khz ( ou encore moins ) donc :
F_TIM2= 72000000 / (71+1) / 50 =20000 Hz
Vitesse moteur maximale : (10000/500)*60=1200 rpm
Pour la Fréquence pour un moteur Pas à Pas et pour ton application 20kHz c'est largement suffisant en 1/8 de pas ça nous donne (20000/1600 ) * 60 = 750tr/min
C'est 0.2% garanti sans bug
Pour les butées logicielles comme on ne gère pas les accélérations, il y une possibilité de décrochage du moteur.
C'est 0.2% garanti sans bug
Pour les butées logicielles comme on ne gère pas les accélérations, il y une possibilité de décrochage du moteur.
Sujets similaires
Sujets similaires
Identification
Référence plaquette porte outils filetage vertical
