Vue normale

Hier — 23 décembre 2024Flux principal
À partir d’avant-hierFlux principal

Encodeur à quadrature, Pico et MicroPython

Bonjour à tous,

L'article d'aujourd'hui regroupe plusieurs domaines.
Il démarre en effet de la récupération d'éléments sur l'imprimante HP DesignJet T520 ou je m'arrête spécifiquement sur les moteurs équipés de disques optiques.


Equipé d'un moteur 5V (CN459-60067 BN026Y18), d'un disque optique et d'un encodeur à quadrature optique, je voulais savoir s'il était possible de l'utiliser avec MicroPython.

Le disque optique

La photo haute résolution du disque optique permet de relever plusieurs informations utiles.

Le disque présente 50 interstices transparents entre deux numéro successif. Le disque étant numéroté de 1 à 12, cela représente 600 pulsations par tour (ce que reprend l'une des références sur le disque).

Les autres références/informations sur le disque ne renvoi malheureusement que vers les imprimantes HP.

L'encodeur optique

Pour sa part, l'encodeur optique est monté sur une plaquette fixée directement sur le support métallique.
Cet encodeur contient un LED (émetteur de lumière) ainsi que deux capteur photo-sensibles. Le décalage entre les deux capteurs permet d'identifier le sens de rotation du moteur.



Le connecteur 4 contacts est utilisé pour:

  • la masse
  • l'alimentation 5V (déduit de la résistance utilisée pour la LED).
  • Deux signaux à quadrature.

Les signaux

Quelques mesures rapides permettent de savoir que le capteur produit une tension de sortie (pas besoin de résistances pull-up ou pull-down).

Maintenant que le brochage est identifié, il ne reste plus qu'à branché un oscilloscope sur les deux canaux de sorties.


 


Notez le décalage entre les deux signaux entre marche avant et marche arrière!

L'oscilloscope nous informe aussi que la fréquence des pulsations est de 24.4 KHz (soit 24400 fois par seconde). La période est de 1/24400 soit 41µSec (temps en deux impulsions sur un même canal).

Brancher sur Raspberry-Pi Pico

Les signaux de sortie étant étant en 5 volts (ou presque), il faut utiliser un pont diviseur de tension pour ramener la tension sous 3.3V.

 

Bibliothèque et code d'exemple

D'autre part la période de 41µSec nécessitera un code particulièrement rapide pour ne pas rater d'impulsion.
Une section de code en PIO permettra de suivre suivre la cadence... même sous MicroPython!

La bibliothèque adéquate est disponible dans le dépôt esp8266-upy ( esp8266-upy/LIBRARIAN/rp2lib ).
rp2qenc.py contient le code PIO et la classe PIO_QENC permettant d'utiliser un encodeur à quadrature autonome sur un Pico.
La classe PIO_QENC permet de compter (ou décompter) un compteur permettant de connaître le nombre de tour moteur (valeur signée encodée sur 32 bits).

Le code permettant de lire le compteur est relativement simple.

from machine import Pin
from time import sleep_ms
from rp2qenc import PIO_QENC

pinA = Pin(15, Pin.IN, Pin.PULL_UP)
pinB = Pin(16, Pin.IN, Pin.PULL_UP)

qenc = PIO_QENC(0, (pinA, pinB))
print('starting....')
for i in range(120):
    print('iter %3i : Quadrature value = %i' % (i,qenc.read()) )
    sleep_ms(500)
qenc.sm_qenc.active(0)
print('stop')


Voici qui termine ce petit article.

Plancha-CMS: Refusion et fin de projet

Amis Maker,

Pas plus tard qu'hier, le projet "Plancha-CMS", un projet MicroPython de refusion CMS, se voyait doté d'une interface utilisateur et de ses premières fonctionnalités (Cooling et Pre-Heat)!

Très excité par cette avancée rapide, je décidais de poursuivre sur ma lancée avec la refusion!

projet "Plancha-CMS"

La refusion

La refusion (reflow en anglais) est un procédé permettant de réaliser la soudure de composants montés en surface (CMS, SMD en anglais) placés sur la carte. C'est ma refusion de la pâte à soudé (aussi appliqué sur la carte) qui soude les composants.
Plus de détails ici sur Wikipedia.

Le profile de refusion

Il n'est pas question de placer la carte, les composants et la pâte de refusion sur une surface étant déjà 250°C! Il faut y aller "en douceur" si je peux m'exprimer ainsi.

Il faut donc suivre ce que l'on appelle un "profile de refusion" visant à:

  1. éviter un choc thermique trop brutal,
  2. de permettre au composant de monter un peu en température
  3. permettre au flux contenu dans la pâte de fondre et de se répandre sur la carte
  4. d'éviter que les composants ne grillent parce qu'il restent trop longtemps à une température trop élevée.

Voici deux exemples de profile de refusion:

 

Enfin, l'article "Reflow Soldering Technology" propose de nombreuses informations pratiques.

Source: Reflow Soldering Technology

Source: Reflow Soldering Technology

Profile d'essai SN0 de la Plancha-CMS

Sur base des informations ci-dessus, voici les 5 phases du profile que je vais mettre en oeuvre pour les premiers essais.

  1. Mise en chauffe: Montée à 150°C en 90' => soit une rampe de 2°C/sec
  2. pré-chauffage: (Rampe jsq'à 180°C en 90' => soit une rampe de 0.33°C/sec
  3. Mise en refusion: montée à 245°C en 45' => soit une rampe de 1.44°/sec
  4. Refusion: maintient à 245°C pendant 30'
  5. Refroidissement: coupure de la chauffe et ventilation

Codage du profile SN0 en Python

Le profile ci-dessous peut être encodé comme suit:

PROFILE_SN0 = [(150,90),(180,90),(245,45),(245,30)]

Voici une liste de tuple (t°_finale, temps_alloué_sec) décrivant les différentes phases détaillées ci-avant.
Le refroidissement venant après la dernière phases.

La première phase est donc 150°C en 90 sec. La dernière est 245°C pendant 30 sec (le maintient à la température de refusion).

Du code pour le peuple

Le code est bien entendu disponible sur le dépôt GitHub Plancha-CMS.
Le script main.py assure le traitement d'un profile par l'appel de la méthode  profile_heating( profile ) qui accepte le profile en paramètre (voir PROFILE_SN0 ci-avant).

Petit rappel

La mise en oeuvre du profile de chauffe s'appuie sur un contrôleur PID qui, lui, contrôle la température de la semelle chaque seconde et applique la correction nécessaire (voir les précédents articles sur Plancha-CMS).

Traitement d'une phase

Pour chacune des phases, le temps alloué en divisé en intervalles de 5 secondes, ce qui permet de calculer la rampe de température à suivre pour atteindre la température finale désirée.
Le PID est donc informé, toutes les 5 secondes, de la nouvelle température à atteindre. Cela permet d'éviter les trop brusques montées en température de la semelle.

Avec des intervalles de 5 secondes, le contrôleur PID dispose de 4 à 5 itérations pour effectuer l'asservissement de la température.

En admettant que la température de la semelle est à 22°C (t° de la pièce) lors du démarrage de la première phase (150,90) du profile, soit (atteindre 150°C, en 90Sec) , nous pouvons déduire:

  • Nous aurons 90 / 5 = 18 itérations de 5 secondes pour cette phase.
  • Une différence de température de 150°C - 22°C = 128°C à combler
  • Soit 128°C / 18 itérations = une augmentation de 7.11 °C toutes les 5 secondes.

La fin de la première phase atteinte, il ne reste plus qu'a  passer immédiatement à la suivant, donc (180,90), et procédé à l'identique... sauf que cette fois, la température de départ est 150°C (T° de fin de la phase précédente).

Contrôler l'exactitude de la régulation.

Voici les informations PID produites par l'exécution de profile_heating( PROFILE_SN0 ) :

1, 46, 41
2, 46, 40
3, 46, 41
4, 46, 41
5, 46, 42
0, 52, 43
1, 52, 44
2, 52, 44
3, 52, 46
4, 52, 47
1, 58, 48
2, 58, 50
3, 58, 50
4, 58, 51
5, 58, 52
0, 65, 53
1, 65, 54
2, 65, 54
3, 65, 55
4, 65, 56
0, 71, 57
1, 71, 58
2, 71, 59
3, 71, 61
4, 71, 63
1, 77, 64
....

On constate que la première colonne est remise a zéro toutes les 5 secondes (à chaque fois que le PID est informé d'une nouvelle température. La deuxième colonne est la T° a atteindre, la troisième colonne est la température de la semelle.

Les données importées dans une feuille de calcul permet de générer un rendu sous forme de graphique.
La première colonne (les itérations PID, chaque seconde) est remplacée par une valeur incrémentée permettant ainsi d'obtenir un écoulement du temps linéaire et globale sur la totalité de la régulation.


Rendu dans le graphique, il est possible de voir les escaliers des différentes consignes attribuées au PID (en bleu) et le suivit de température de la semelle (en rouge).

Phases de la refusion et température de la semelle

La courbe de refusion est excellente (même si elle présente un retard de 5 à 10 degrés). Il y manque la phase de maintient à 245°C qui n'était pas encodée dans le script Python.

Après une légère adaptation du code, il est maintenant possible de relever une courbe de refusion complète... et le résultat est plutôt satisfaisant :-)

Refusion SN0 -> refusion de SnCu à 245°C

Auto-critique:

1. il serait plus approprié d'avoir un pointe a 245°C qui dure plus longtemps.
2. le retard systématique entre la consigne et la température est probablement causée par le déplacement de la sonde de température du dessous de la semelle au dessus de la semelle. Ce qui aurait sensiblement modifié les paramètres PID.
3. Adapter les paramètres pour répondre au point 2 pourrait fort bien corriger le point 1.

Ressources

Voici un projet terminé qui saura se monter utile.

Plancha-CMS: contrôle utilisateur et premières fonctionnalités

Amis Maker,

Peut-être vous souvenez-vous du projet "Plancha-CMS", un projet MicroPython au long cours sur-lequel je me penche de temps à autre.
Le dernier article date de mai 2023 avec un dernier dernier opus technique  en Août 2021.

Interface Homme-Machine

Dans l'article de mai 2023, j’envisageai l'usage d'un écran OLED graphique.
Quand j'ai repris mon projet ce Week-end, j'ai finalement opté pour un afficheur 2x16 I2C et un encodeur rotatif+click I2C... c'est que je voulais avancer vite.


Sur l'image ci-dessus, il est possible de constater:

  • La finalisation de l'interface utilisateur
  • La connexion USB vers l'ordinateur (pour finaliser le développement)
  • La présence du bouton Reset (et du plus discret switch RUN_APP)
  • Le repositionnement du thermocouple sur le dessus de la plancha.

Securité avant tout

La Plancha-CMS dispose déjà d'un arrêt d'urgence qui s'avère essentiel durant le développement.

J'ai cependant ajouté quelques sécurités complémentaires:

  • Arrêt forcé du relais SSR au démarrage du microcontrôleur.
  • Définition d'une température critique (CRITICAL_T = 380).

La température est constamment surveillée par le contrôleur PID, contrôleur qui fonctionne en toute indépendance grâce à un Timer!
C'est donc l'endroit idéal pour renforcer la sécurité.
Si la température lue par le PID atteint CRITICAL_T alors:

  • le contrôleur PID est arrêté
  • le relais SSR est désactivé
  • le microcontrôleur est réinitialisé (pour assurer de l'arrêt du code).

Interface utilisateur

Le menu principal est simple a appréhender, il suffit d'utiliser l'encoder et de cliquer pour sélectionner la fonctionnalité. Les LEDs vertes de l'encodeur indique simplement qu'il n'y a pas de tâche en cours d'exécution.

Le menu prévoit 3 fonctionnalités:

  • Pre-Heat: préchauffage à la température sélectionnée par l'utilisateur. Affichage de la T° en temps réel.
    Maintenue de la température; cliquer pour sortir de la chauffe et entamer la phase de refroidissement par air forcé (jusqu'à T° < 35°C).
    Le refroidissement peut être interrompu à tout moment (en cliquant).
  • Cool: Refroidissement par air forcé avec affichage de la température. Interruption manuelle en cliquant.
  • Solder: en cours de développement - Processus de soudure en suivant un profil de refusion. 

Processus de Préchauffage

Si l'utilisateur sélection l'entrée Pre-Heat alors il à la possibilité de sélectionner la température de préchauffe souhaitée (à l'aide de l'encodeur rotatif).


Une fois la température sélectionnée... il faut encore confirmer la pré-chauffe (au cas où la sélection serait une erreur utilisateur).

Une fois confirmé, la température est configurée sur le contrôleur PID et affichée en temps réel sur l'écran.

L'utilisateur peut quitter le processus à tout moment en cliquant l'encodeur rotatif.

Le script affiche également des informations sur la connexion USB-Serie, de quoi reconstituer un graphique de la montée en température à l'aide d'une feuille de calcul.

Temps_sec, T_Consigne, T_reel
1, 100, 45
2, 100, 44
3, 100, 44
4, 100, 45
5, 100, 46
6, 100, 48
7, 100, 51
8, 100, 54

Ressources

  • Dépôt Plancha-CMS (GitHub, MCHobby)
    Voyez le fichier install.sh pour l'installation des dépendances.
     

A tout bientôt pour la suite ;-)
Dominique


Apprendre Python gratuitement avec le MIT

Le MIT propose un cours en ligne gratuit pour débuter en programmation avec Python. Un apprentissage flexible pour enrichir vos compétences numériques. Un accès gratuit pour une compétence essentielle Le Massachusetts Institute of Technology (MIT), institution mondialement reconnue, met gratuitement à disposition son cours phare, Introduction to Computer Science and Programming with Python. Accessible via […]

Utilisation de l’écran rond CrowPanel IPS tactile Elecrow 1,28 pouce ESP32

Après la présentation de l’écran tactile circulaire équipé d’un ESP32 C3 que propose Elecrow, j’ai voulu tester l’afficheur en microPython, avec Thonny. Vous trouverez dans cet article les étapes de l’installation de microPython et les premiers tests. Utilisation de l’écran rond CrowPanel IPS tactile Elecrow 1,28 pouce Installation de microPython On va commencer par effacer […]

Cet article Utilisation de l’écran rond CrowPanel IPS tactile Elecrow 1,28 pouce ESP32 a été publié en premier sur Framboise 314, le Raspberry Pi à la sauce française.....

💾

💾

Data to Fish: Data Science Tutorials using Python, SQL and more!

14 juillet 2020 à 11:01

Data To Fish was born in an effort to facilitate the application of data science using various tools such as Python, R, Julia and SQL.

We are passionate about data, and strive to provide you the most up-to-date and accurate information about common data-related problems.

The content provided on this website is constantly reviewed. Yet, if you do come across any errors in the content, please feel free to reach us at datatofish@gmail.com. Please note that due to the high volume of requests, we can no longer accommodate personal requests of code reviews. Please also refrain from including any email attachments.


Direct link

Automate storing of Object given parameters at creation

28 janvier 2017 à 22:41
Basically replacing this

class A:
    def __init__(self, b, c, d, e):
        self.b = b
        self.c = c
        self.d = d
        self.e = e

by

class A:
    def __init__(self, b, c, d, e):
        # You can edit parameters' value here before they are being stored
       
        for k, v in vars().items():
            setattr(self, k, v)


By me.
Permalink

Debugging Python script more easily with Notepad++

25 juillet 2016 à 22:22
[path_to_script]\python-no-autoclose.py "$(FULL_CURRENT_PATH)"

In the menu  Run > Run, put this in the text field and hit Save, give it a name and a key combination. Personally I used Shift+F5. Be wary than all key combinations might not work, try it to make sure or change it.

The script:

import sys
import traceback
import subprocess
import os
import pathlib

if sys.argv[1:]:  # Failsafe
    try:
        os.chdir(str(pathlib.Path(sys.argv[1]).parent))
    except Exception as e:
        traceback.print_exc()

    try:
        subprocess.call(['python', sys.argv[1]])
    except Exception as e:
        traceback.print_exc()
else:
    print('I\'m very confused...')

print()
input('Press Enter to exit.')
Permalink

Signing data with HMAC - sebsauvage.net- Snyppets - Python snippets

27 novembre 2014 à 19:25
Bon, sachant que sebsauvage lit rarement ses mails, je vais tenter de le contacter par ici. :)

Ton implémentation est non sécurisée. C'est mal car d'autres personnes risquent de s'en inspirer sans savoir les problèmes liés à cette implémentation.

1) " Warning - When comparing the output of hexdigest() to an externally-supplied digest during a verification routine, it is recommended to use the compare_digest() function instead of the == operator to reduce the vulnerability to timing attacks." https://docs.python.org/3.4/library/hmac.html#hmac.HMAC.hexdigest

2) "The digestmod argument to the hmac.new() function may now be any hash digest name recognized by hashlib. In addition, the current behavior in which the value of digestmod defaults to MD5 is deprecated: in a future version of Python there will be no default value. (Contributed by Christian Heimes in issue 17276.)" https://docs.python.org/3/whatsnew/3.4.html#hmac
Donc il faudrait mieux commencer à spécifier une valeur pour digestmod.

Comme suggéré par l'issue (1) et cette réponse sur SO (2), je proposerais d'utiliser SHA-256 ou SHA-512 comme suit :

hmac.compare_digest(hmac.new(key, name, digestmod=hashlib.sha256).hexdigest(), signature)

(+ remplacer partout où il faut bien sure et ne pas oublier import hashlib)

(1) https://bugs.python.org/issue17276
"As of now the hash algorithm for HMAC defaults to MD5. However MD5 is considered broken. HMAC-MD5 is still ok but shall not be used in new code. Applications should slowly migrate away from HMAC-MD5 and use a more modern algorithm like HMAC-SHA256.

Therefore I propose that default digestmod should be deprecated in Python 3.4 and removed in 3.5. Starting with Python 3.5 developer are forced to choose a hash algorithm like SHA256. Our documentation shall suggest it, too."

(2) http://crypto.stackexchange.com/a/9340/18518
"Yes, there are currently no known attacks on HMAC-MD5.

[…]

However, this does not mean you should use HMAC-MD5 in new cryptosystem designs. To paraphrase Bruce Schneier, "attacks only get better, never worse." We already have practical collision attacks for MD5, showing that it does not meet its original security goals; it's possible that, any day now, someone might figure out a way to turn those into a preimage attack, which would compromise the security of HMAC-MD5. A much better choice would be to use HMAC with a hash function having no known attacks, such as SHA-2 or SHA-3."
Permalink
❌
❌