[Arduino] Régulation pac

[BiduleOhm]

C'est sûr que j'ai toujours vu du linéaire aussi. Tu peux avoir un offset dans certains cas mais ça reste linéaire.

Wé m'enfin pour qu'il y ait une chute de tension il faut qu'il y ait un courant et ici les courants sont censés être insignifiants donc idem pour les ddp. C'est surtout pour palier aux parasites qu'on a créé les boucles de courant (signal qui passe pas loin du triphasé sous plusieurs dizaines d'A par ex...), le problème c'est que spa super adapté à l'arduino.

S'il a des pb c'est soit qu'il tire du courant pour alimenter des trucs qu'il ne devrait pas (relais, moteur, ...) à partir d'une alim de capteur, soit qu'il utilise des fils extrêmement fins et/ou longs (m'enfin même de la paire téléphonique sur quelques dizaines de mètres ne devrait pas poser de pb avec du 0-5 V), soit qu'il a des faux/mauvais contacts (au hasard oxydation).

L'avantage qu'il a ici c'est que les variations mesurées sont lentes donc il peut mettre un filtre passe-bas sévère (genre quelques Hz comme fréquence de coupure) pour virer les parasites. Bon après ça ne corrige évidemment pas les faux-contacts, etc... qui ne seraient de toute façon pas corrigés par une boucle de courant.

[Sk_rmouche]

Wé m'enfin pour qu'il y ait une chute de tension il faut qu'il y ait un courant et ici les courants sont censés être insignifiants donc idem pour les ddp. C'est surtout pour palier aux parasites qu'on a créé les boucles de courant (signal qui passe pas loin du triphasé sous plusieurs dizaines d'A par ex...), le problème c'est que spa super adapté à l'arduino.

Tu serais surpris de ce qu'on peut voir sur site, les courants sont censés être faibles, mais les fils utilisés sont aussi très fins, leur résistance est loin d'être insignifiante. Dans son cas ça doit pas vraiment jouer car les longeurs sont limitées, mais quand tu as une alim distante et 100 mètres de filasse 0.25mm2 ou plus fin encore, la résistance linéique et la capacitance de la ligne pose problème.

La boucle 4-20 mA est plus résistante face aux parasites c'est clair, mais permet aussi d'augmenter franchement les distances pratiques également.


On a un site avec de vieilles machines ( 35+ ans ) et ce sont de vieux contrôleurs Shimaden

En moyenne 30 à 40 mètres de distance entre la sonde et le contrôleur, le tout en 0-10V, et bien entendu de la filasse toute pourrie et ultra fine.  A chaque fois qu'un équipement démarre tu vois le contrôleur qui danse sur la température lue. Ca va que c'est pas critique et que c'est des variations lentes ( chambre froide pour carcasse ) mais quand même

Je pensais suggérer de passer du RJ45 au lieu de fil de haut-parleur vieux de 35 ans, ça irait peut-être mieux



C'est quoi qui gêne pour l'Arduino et le 4-20 mA ?

[BiduleOhm]

Oui avec des fils fins et de grandes distances tu peux commencer à avoir des pb, mais dans son cas je doute que ce soit ça le souci. Il a dû faire un câblage à la lolox, il est là le souci

Après le mieux reste le numérique, la mesure reste fiable même si le signal est dégradé vu que tout ce qu'on a besoin c'est de pouvoir faire la différence entre 1 et 0.

Wé, le RJ45 t'as 4 paires torsadées et blindées (attention, sont pas forcément blindés, évite le CAT 5, prends du CAT 5e ou CAT 6 si possible) et le connecteur est ultra standard donc pas de pb d'appro ou de remplacement en cas de souci.

C'est ce que je disais pour le filtre, dans ton cas aussi tu pourrais mettre un passe-bas (même un simple réseau RC suffit) qui virerait le transitoire quand t'allumes l'autre machine. A défaut des tores de ferrites ça peut dépanner et ça ne change pas la résistance du circuit. Eloigner les câbles ça aide pas mal aussi (loi du carré inverse, toussa...), le mieux c'est d'avoir deux groupes de câbles les plus loin possible l'un de l'autre: un mesure et un commande/puissance.

[OrOoX]

Tu sais le câblage à la lolox il est en post initial, j'ai juste rajouté un potard pour simuler le 0-5V des entrées analogique ^^'


Ce que j'ai pu constater c'est que avec un multimètre assez précis, je perdais des dizaines de millivolts entre l'alimentation et la valeur lue
par l'arduino, par exemple à fond je n'ai que 4920mV alors que l'alimentation fournie bien 5000mV et la tension n'est pas égale sur tous les
pins de sortie de la breadboard donc des mauvais contact t'en a déjà là, les fils quand à eux n'ont pas tous la même résistance qui n'est pas nulle ...


Au vu des problèmes rencontrés je me demande si je ne gagnerai pas mon temps à faire directement la programmation sur l'automate Siemens qui
est prévu à cette effet, en plus avec la communication Lonwork je n'aurais plus à me taper des aller retour pour mettre à jour le programme ... La carte
arduino ne servirait donc plus qu'à recevoir le 0-5V de l'automate et à générer le pwm pour le détendeur électronique vu que les sondes seraient
connectées sur l'automate et en plus suivant mon stock, serait du PT100 voir du PT1000.

[OrOoX]

Bon je me suis repenché sur le code vu que la mise en place de l'automate est pas pour tout de suite, du coup avec les dernières mesures des
capteurs de pression c'est bueno mais le problème c'est toujours le calcul de température ...

La courbe n'est pas du tout linéaire du coup ça me sort pas la bonne température, genre ça avec une courbe de tendance en mode
polynominale degré 3, qui me sort la formule y = 0,0823x3 - 1,956x2 + 19,627x - 43,101


  courbe_temp_pression.PNG (Taille : 35.36 Ko / Téléchargements : 2)

Du coup j'ai adapté un code que j'ai trouvé sur le forum Arduino mais ça fait nawak ...

Code :

float correction_BP(float x)
  {
    return (0.0823*x*x*x) - (1.956*x*x) + (19.627*x) - 43,101;
  }

float correction_HP(float x)
  {
    return -0.2346*x*x*x*x + 4.5717*x*x*x - 33.2*x*x + 117.78*x - 114.78;
  }

double mapf(double val, double in_min, double in_max, double out_min, double out_max) {
    return (val - in_min) * (out_max - out_min) / (in_max - in_min) + out_min;
}

void loop() { 
  // Récupération des températures
  sensors.requestTemperatures();
 
  // Récupération pression BP + Calcul relation pression/température
  //Capteur_BP = analogRead(Pin_Capteur_BP);
  Capteur_BP = 105; // 380
  Pression_BP = mapf(Capteur_BP, 105, 671, 0.0, 9.0); // Tension <=> KPA
  Temperature_BP = mapf(Capteur_BP, 105, 671, -26.07, 39.44); // Tension <=> Température °C
  Serial.println(Temperature_BP);
  float Temperature_BP_cor = correction_BP(Temperature_BP);
  Serial.println(Temperature_BP_cor);

Ca devrait me sortir le même genre de valeurs théoriquement mais à la place j'ai :

20:19:09.440 -> -26.07 ( température mapf )
20:19:09.440 -> 101.00 ( température corrigée )

Et quand tu demande à google de calculer ... : -46400.2809057


J'ai raté un truc ou je suis juste débile ?

[Kissagogo27]

tu peux pas découper ta courbe en tronçons de la forme ax+b ?

[OrOoX]

Ca pourrait être envisageable mais chiant pour la BP mais la HP ahem ...


Je sais pas pourquoi mais j'ai l'impression que les arduinos ont beaucoup de mal avec les fonctions mathématiques ... Comme moi quoi

[Kissagogo27]

j'pense que c'est surtout toi

[BiduleOhm]

Déjà tu mixes du double avec du float avec du int.

Ensuite t'as pas précisé au compilo que tes constantes sont des floats.

Enfin, quand je vois x*x*x*x je me dis que t'as ptet des overflows.

Commence par tout passer en float (le double est overkill pour ce que tu fais) et rajouter un f derrière tes constantes.

Ensuite utilises du quadratique maximum, au moins pour commencer, pas besoin du cube ou plus.

[OrOoX]

Whoua ... J'ai rien compris


Le double c'était du copier coller, j'ai pas chercher plus que ça la différence vu que ça ne changeait rien ^_^'

Pas précisé que les constantes sont des floats ? Les quelles ? Si tu parle de Pression_BP et Temperature_BP c'est fait en début de code, j'ai
pas tout mis car le reste n'a pas de lien avec le problème actuel. ( c'est une ré-écriture du code initiale posté avant )

Yeap les x*x*x*x c'est pas optimisé, j'ai tenté avec la fonction pow() mais ça me sort toujours 101 pour la BP, c'est fou ça ...

Du coup j'ai changé les double en float par contre que veut tu dire par rajouter un "f" derrière les constantes ?


Et j'ai pas compris pour le quadratique maximum ...

Code :

float correction_BP(float x)
  {
    float x3 = pow(x,3);
    float x2 = pow(x,2);
    
    return (0.0823*x3) - (1.956*x2) + (19.627*x) - 43.101;
  }

float correction_HP(float x)
  {
    float x4 = pow(x,4);
    float x3 = pow(x,3);
    float x2 = pow(x,2);
    
    return (-0.2346*x4) + (4.5717*x3) - (33.2*x2) + (117.78*x) - 114.78;
  }

float mapf(float val, float in_min, float in_max, float out_min, float out_max) {
    return (val - in_min) * (out_max - out_min) / (in_max - in_min) + out_min;
}

void loop() {  
  // Récupération des températures
  sensors.requestTemperatures();
  
  // Récupération pression BP + Calcul relation pression/température
  //Capteur_BP = analogRead(Pin_Capteur_BP);
  Capteur_BP = 105; // 380
  Pression_BP = mapf(Capteur_BP, 105, 671, 0.0, 9.0); // Tension <=> Bars
  Temperature_BP = mapf(Capteur_BP, 105, 671, -26.07, 39.44); // Tension <=> Température °C
  Serial.println(Temperature_BP);
  float Temperature_BP_cor = correction_BP(Temperature_BP);
  Serial.println(Temperature_BP_cor);

Edit : AH LE BOULET, j'avais pas changé la virgule de 43.101 pour la correction BP ... Maintenant ça me sort -3342.38

[BiduleOhm]

Tous les chiffres tapés à la main genre 0.0823 etc. sont des constantes (t'es sûr que tu sais coder pour pas savoir ce qu'est une constante ? ) et dans ton cas ce sont des chiffres décimaux. Selon un tas de facteurs que je ne vais pas détailler ici le compilo peut les interpréter comme tel ou comme des int (donc 0.0823 --> 0, 1.23 --> 1, 7.89 --> 7, ...) donc si tu veux être sûr qu'ils soient interpretés correctement il faut les suffixer avec un f, par ex: 1.23f

T'arrives pas à utiliser pow() ? sérieusement ? result = pow(input, 2);

Ok, beaucoup mieux avec que des floats, plus clair et plus opti

Je disais de faire une régression quadratique sous excel au lieu d'une cubique, ou pire encore, pour éviter d'avoir des exposants trop élevés (maximum: un carré). Une fois que ça marche tu pourras affiner avec du cubique ou autre si tu veux.

[OrOoX]

Pour moi c'est des valeurs, je vois pas la différence


Sinon je connaissais pas le coup de rajouter un "f" derrière, ça revient à faire un float(0.0823) du coup mais en plus simple ?

Pour les pow(), pourquoi tu dis que j'y arrive pas ? Je l'ai mis dans le code et ça fonctionne ... Du moins je crois, j'ai pas d'erreur :p


Pour la formule j'ai bien vu que les autres existe mais ça me sort pas du tout la même précision, par contre j'étais tombé sur un
sujet qui disait que les arduinos auraient des problèmes pour calculer quand c'est un ordre 3 ou 4 et +.

[BiduleOhm]

Ben y'a de grosses différences, et accessoirement ça permet de les différencier quand on en parle.

Oui et non, spa un cast parce que un cast permet d'interpréter un type à la place d'un autre, là c'est plus comme une déclaration (ta constante n'a pas de type à la base, le compilo lui en attribue un et en général c'est int celui par défaut, c'est pour ça qu'il faut préciser que spa un simple entier avec f).

Ben pour le pow() tu dis que t'as tenté mais que ça marche pas ?

Oui mais pour le moment on s'en fou de la précision, le but c'est de justement dégrader la précision pour simplifier la formule pour pouvoir voir d'où le pb vient.

Oui, l'arduino n'est pas un DSP, les float et double ne sont même pas natifs (c'est pour ça qu'ils sont super lents et probablement plus buggés que le reste). Perso je fais tout en virgule fixe avec des entiers sauf si j'ai vraiment pas le choix ou que je sais qu'un float ne posera pas de pb à l'endroit où je l'utilise. M'enfin ça je l'avais déjà dit 15 pages avant, mais toi pas écouter

[OrOoX]

Bon bon bon ... Après moulte essais et énervement avec ce pdf : http://projet.eu.org/pedago/sin/ICN/1ere...onnage.pdf

J'ai enfin des valeurs "potable" mais non précise avec une courbe logarithmique ... Genre 38.83 pour 39.44°C ou 26.91 pour 26.78°C.


  courbe_134_logarithmique.PNG (Taille : 44 Ko / Téléchargements : 2)

Code :

float correction_BP(float x)
  {   
    return (36.276f*log(x)) - 197.28f;
  }

J'ai sortie une courbe polynomial ordre 3 aussi mais comme je suis une bille en math l'histoire des exposants m'a perdu
( y = 2E-07x3 - 0,0003x2 + 0,2576x - 44,42 )


  courbe_134_polinomial.PNG (Taille : 43.11 Ko / Téléchargements : 4)


Ca avance, même si il me faut plusieurs jours pour faire ce qu'un autre aurait surement fait en moins de 2h

[BiduleOhm]

Attends le mec il se fait chier à faire un paquet de mesures et une régression pour un LM35 ? sérieusement ?

Une polynomiale ordre 2 suffirait vu le très faible coef devant l'ordre 3, tu te fais chier pour rien...

[OrOoX]

Sauf que moi c'est pas une LM35 mais un transducteur de pression linéaire avec une température non linéaire ...


Dans le cas présent j'aimerais bien avoir moins de 0.5K d'erreur afin d'avoir une régulation stable qui ne va pas passer son temps à ouvrir
et fermer le détendeur inutilement, ça serait pour de la HP avec régul de ventilo, je serais moins pointilleux mais le détendeur lui
a besoin d'être précis, j'ai pu constater que 1 ou 2 crans avaient une incidence immédiate sur la surchauffe.

[Kissagogo27]

donc t'as un moyen indirect de calculer la pression non ? donc pk te faire chier a la connaître ? genre ton truc il est plus chiadé que dans l'indus ? :p

[OrOoX]

Bah le transducteur renvoie sur l'arduino qui déduit la pression réelle en fonction de la tension oui, sauf que pour calculer ma surchauffe il me faut
calculer la température d'évaporation à partir de cette pression, d'où la prise de tête ...

Je peux pas juste me baser sur la pression vu que c'est pas en relation direct avec ce que je veux comparer ( bars <=> °C ), et bien sûr c'est le même problème
pour faire l'inverse, à savoir déduire la pression à partir de la sonde de surchauffe, t'vois ?

[BiduleOhm]

Et qu'est-ce que t'utilises comme capteur pour la temp déjà ?

[OrOoX]

Pour l'instant c'est des DS18B20 pour mesurer la surchauffe et le sous refroidissement, on verra pour l'automate mais honnêtement ça sera surement
de la PT1000 vu les emmerdes que des LM35 génèrent pour les mettre en place ... ( ampli, circuit imprimé par sonde etc ... ).