Teplotní čidlo DALLAS DS18B20

[Cmrnda]

Koupil jsem čidlo DALLAS na vyhodnocování teploty na chladiči u regulátoru panelů, zapojil do ESP 32, naprogramoval a zjistil jsem to že "všehlasné" Dallas je tak pomalé, že je k vyhození hned, a né až potom.

Použil jsem kód pro Arduino IDE:

//----------------------------------------------
#include <OneWire.h>
#include <DallasTemperature.h>

#define ONE_WIRE_BUS 0 //vývod P0

OneWire oneWire(ONE_WIRE_BUS);
DallasTemperature sensors(&oneWire);
//----------------------------------------------
float tempC = sensors.getTempCByIndex(0);

if (tempC != DEVICE_DISCONNECTED_C)
{
udp.print("Temperature for the device 1 (index 0) is: ");
udp.println(tempC);
}
else
{
udp.println("Error: Could not read temperature data");
}
//----------------------------------------------

První je deklarace a druhý je lup.

Ono to funguje, ale čekací doba na výpočet či měření, nebo co se děje dál, je 500ms.
Kdo by věděl a měl chuť sem sdělit kód s měřením kratším než 1ms, určitě ho uvítají všeci majitelé čídla se senzoremr Dalas DS18B20.

[kybos]

Za 1 ms se ani nevytvoří dostatečná teplotní diference oproti minulému stavu, aby bylo možno při takové rychlosti snímání a rozlišovací schopnosti teplotního čidla (12 bitů) monitorovat nějakou změnu. Pokud chceš řešit teplotní diference jaderného reaktoru, musíš použít jiná čidla. Na běžné monitorování nebo řízení chlazení polovodičů DS18B20 stačí. Změř si teplotní gradienty při skokové změně zátěže a časy reálné změny teploty pouzdra čidla a nejspíš zjistíš, že řídíš systém, který má reakční časy v jednotkách sekund. Na to čidlo s reakční dobou 500 ms s rezervou stačí. Na stole takový regulátor bez problému chodí. Potíže nastanou až při jeho instalaci do silně zarušeného prostředí. Někdy se to povede na první dobrou, jindy je to duchařina a musí se silně filtrovat i získané hodnoty.

[kamils]

Ono to funguje, ale čekací doba na výpočet či měření, nebo co se děje dál, je 500ms.
Kdo by věděl a měl chuť sem sdělit kód s měřením kratším než 1ms, určitě ho uvítají všeci majitelé čídla se senzoremr Dalas DS18B20.

Takový kód neexistuje protože samotnému čidlu trvá konverze podstatně déle:

ds18b20.PNG (27.23 KiB) Zobrazeno 71754 x

[soami]

Koupil jsem čidlo DALLAS na vyhodnocování teploty na chladiči u regulátoru panelů, zapojil do ESP 32, naprogramoval a zjistil jsem to že "všehlasné" Dallas je tak pomalé, že je k vyhození hned, a né až potom.

A proč potřebuješ měřit chladiče každou ms? Jak psal Kybos, než se rozdíl promítne do ohřevu/ochlazení té kovové olačky a následně se to projeví na dallasu, uběhne několik sekund. I pokud použiješ jen samotné čidlo, tak 0,5s zpoždění ve zpracování bude +- odpovídat teplotním změnám na čidle. Pokud chceš o něco (ne o moc) rychlejší a přesnější reakce, pořiď si odporové PT1000.

[Mex]

Prý to umí Chuck Norris.
Ale ten to zas nepotřebuje, protože on naopak řekne jaká má být teplota, a ta se přizpůsobí.

Docela by mě zajímalo, co reguluješ, že potřebuješ odezvu do 1ms.
Na to by snad mohl fungovat nějaký opravdu miniaturní termistor (vypadají jako zrnko písku, ze kterého lezou 2 vlasy), aby měl minimální tepelnou setrvačnost.

[Cmrnda]

Díky všem za infa, nejde o to, zda potřebuju měřit po 500ms nebo po 1sec. a nebo výše, ale o to že to značně brzdí procesor s jinými výpočty které jsou nutné měřit a řídit bez takovýhlech prodlev.

ds18b20.PNG

Kde najdu takovouhle tabulku?

Jinak termistor + odpor měří ESP32 za méně než 100 us ve 12bitech.

[tomasi02]

kamil neuvedl zdroj, ale je to v datasheetu
https://www.analog.com/media/en/technic ... s18b20.pdf

[Cmrnda]

Potíže nastanou až při jeho instalaci do silně zarušeného prostředí. Někdy se to povede na první dobrou, jindy je to duchařina a musí se silně filtrovat i získané hodnoty.

Co mě hodně pomohlo je "pulldown" a to u každého vstupu (pokuď je podporován). Nějaké zatlumování odpory bylo spíše na nic. Dále měření 5x po sobě a hodnotu vydělit /5. Víc než 5 a méně než 5 se mi ukázalo jako neoptimální.
Pro toto čidlo jsem přidal odpor 4K7 na +, vč.pulldown.

[Cmrnda]

kamil neuvedl zdroj, ale je to v datasheetu
https://www.analog.com/media/en/technic ... s18b20.pdf

Dík.
Nj, n... Tak to je v kopru.

[luky]

Díky všem za infa, nejde o to, zda potřebuju měřit po 500ms nebo po 1sec. a nebo výše, ale o to že to značně brzdí procesor s jinými výpočty které jsou nutné měřit a řídit bez takovýhlech prodlev.

Nejsem úplně programátor, ale takovéhle věci se řeší tak, že pošlu požadavek na zjištění teploty, mezitím si počítám co potřebuju a jakmile mám měření teploty hotový, tak si ho přečtu, ne? Nemusíš čekat 500ms...

[Cmrnda]

..... že pošlu požadavek na zjištění teploty, mezitím si počítám co potřebuju a jakmile mám měření teploty hotový, tak si ho přečtu, ne? Nemusíš čekat 500ms...

No, to je ten příkaz "sensors.requestTemperatures();", trvá cca 100msec. Další příkaz čtení je "sensors.getTempCByIndex(0); trvá cca 400ms.
Tak o čem je řeč?
Prostě tě to dál nepustí...

[luky]

Aha, tak to se do toho budeš muset ponořit hlouběji.
1) čti to čidlo přímo podle adresy. Takhle to pokaždé hledá všechna čidla na sběrnici a pak ti vypíše to první.
2) Jdi trochu hlouběji - to čidlo požádáš o čtení teploty a po nějaké době si přečteš, jestli už je hotový a případně jaký je výsledek převodu. Tuším tam byl v registech nějaký flag, že už je hotovo a umělo se to i samo na běrnici nějak přihlásit o řeč.

[kybos]

Co mě hodně pomohlo je "pulldown" a to u každého vstupu (pokuď je podporován). Nějaké zatlumování odpory bylo spíše na nic. Dále měření 5x po sobě a hodnotu vydělit /5. Víc než 5 a méně než 5 se mi ukázalo jako neoptimální.
Pro toto čidlo jsem přidal odpor 4K7 na +, vč.pulldown.

U mne pomohlo použít aktivní napájení 5 V místo 3,3 V, blokovací keramický kondenzátor na napájení u každého čidla na sběrnici, stíněné datové vedení připojené na zemi u procesoru, programové zahazování nepředpokládaných hodnot (všechny záporné a nulové hodnoty teploty a příliš velké odchylky od vlečeného průměru, pokud jsou jedinečné) a hodnoty 85°C. Je ale potřeba vzít na vědomí, že ovládanými ventilátory řídím teplotu chladičů spínacích prvků, na kterých se spínají proudy v řádu 200 A a čidlo musí být v co nejtěsnějším tepelném kontaktu s chladičem. Frekvence chybných čtení se snížila z jednou za pět minut na jednou za týden, ale pořád to neodpovídá mým představám o spolehlivosti tak důležité komponenty systému, jako je chlazení výkonového střídače.

[kamils]

Bohužel standardní knihovna pro Dallas blokuje program dokud není měření dokončeno. Je potřeba trochu zesložitit kód o druhou úlohu, která bude čekat na výsledek měření.
Nejjednodušší je vytvořit task "loop_mereni" ve kterém se čte z čidla a po je skončeni se nastaví proměnná "Mereni_OK". V hlavní smyčce se jen kontroluje nastaveni "Mereni_OK".
Asi nějak takhle:

Kód: Vybrat vše

//----------------------------------------------
#include <OneWire.h>
#include <DallasTemperature.h>

#define ONE_WIRE_BUS 0 //vývod P0

void loop_mereni(void *parametry);

OneWire oneWire(ONE_WIRE_BUS);
DallasTemperature sensors(&oneWire);
float tempC;
bool Mereni_OK;
TaskHandle_t uloha_mereni;

void setup ()
{
	/***
	setup vseho moznoho
	***/
	
	 xTaskCreate(loop_mereni, "MERENI", 1000, NULL, configMAX_PRIORITIES - 1, &uloha_mereni);
	 Mereni_OK = false;
}

void loop()
{
//----------------------------------------------

	if(Mereni_OK == true)
	{
		Mereni_OK = false;
		if (tempC != DEVICE_DISCONNECTED_C)
		{
			udp.print("Temperature for the device 1 (index 0) is: ");
			udp.println(tempC);
		}
		else
		{
			udp.println("Error: Could not read temperature data");
		}
	}
}

//----------------------------------------------


void loop_mereni(void *parametry) 
{
  while (true) 
  {
	tempC = sensors.getTempCByIndex(0);
	Mereni_OK = true;
	vTaskDelay(pdMS_TO_TICKS((100));
  }
}

[yolo80]

ESP32 vie multitasking
https://simplyexplained.com/blog/multit ... -freertos/
https://randomnerdtutorials.com/esp32-d ... duino-ide/

[Cmrnda]

Multitasking, asi vhodná věc, jenže vím já jestli už se nepoužívá v nějakých knihovnách pro ESP32? V tom prvním článku píšou že všechny kódy běží na prvním jádru, to ano, ale co knihovny? Zase jinde sem čet že právě WiFi a kol běží na druhém jádru.
Pokuď nebudu znát průběžnou vytíženost CPU obou jader, bude velmi obtížné do toho nechat balancovat přepínání jader a ještě včetně priority procesů.

Zkusím nějaký experiment.

.... blkovací keramický kondenzátor na napájení u každého čidla na sběrnici, stíněné datové vedení připojené na zemi u procesoru ...

Nj, ale kam až zajít, k propájené plechové krabičce s průchodkovými kondenzátory? Jinak to blokování konndenzátory je dost problém, protože vývody/vstupy nemají vedle "zem". U ESP jsou snad jen 3 a je to celý velký, takže není možné blokování provést těsně u vstupů. U RPI pico je ijch daleko víc a ještě je to menší, tam možná, ikdyž stěží...

[Mex]

Nevím, proč jsi ve spojitosti s blokováním kondenzátory zmiňoval vývody ESP?
Blokovat napájení kondíkem je třeba u čidla. Ideálně přilepit malý SMD kondenzátor přímo na jeho nohy.

U ESP má případně smysl snížit rychlost hran malým sériovým odporem. Něco mezi 22R a 68R. Ale to platí u dlouhých vedení.
A u těch dlouhých pak má smysl dát na konec i antiparalelně malou schottky diodu proti podkmitu úrovně na datovém vodiči.
Ty Dallasy jsou na to dost citlivé.
Ale opět, má to smysl až u dlouhých vedení, řekněme tak od 5m víc.

Napsat neblokující čtení, na to nepotřebuješ multitasking a už vůbec ne víc jader.
Komunikace s tím čidlem je tak pomalá, a ESP tak rychlé, že to zvládneš jednoduchým algoritmem s přerušením.

[Cmrnda]

Nevím, proč jsi ve spojitosti s blokováním kondenzátory zmiňoval vývody ESP?

Protože jestli chceš odrušit přívod do procesoru, tak je nutné dát R/C člen kondenzátorem ke vstupu toho vstupního zařízení, ať je to co je to.
Bude-li to naopak, tak obráceně, budeš odrušovat vstup do čidla.

U ESP má případně smysl snížit rychlost hran malým sériovým odporem. Něco mezi 22R a 68R. Ale to platí u dlouhých vedení.
A u těch dlouhých pak má smysl dát na konec i antiparalelně malou schottky diodu proti podkmitu úrovně na datovém vodiči.
Ty Dallasy jsou na to dost citlivé.
Ale opět, má to smysl až u dlouhých vedení, řekněme tak od 5m víc.

U mě nepadá na váhu, 1m. Jinak 22-68 Ohm do série? Záleží na výstupních reálných odporech čidla, předpokládám že u tohoto budou velmi nízká a tím pádem i odolná proti rušení bez nějakého odporu 22Ohm, u mě k smíchu...

Komunikace s tím čidlem je tak pomalá, a ESP tak rychlé, že to zvládneš jednoduchým algoritmem s přerušením.

Přerušením čeho?

[Mex]

Nevím, proč jsi ve spojitosti s blokováním kondenzátory zmiňoval vývody ESP?

Protože jestli chceš odrušit přívod do procesoru, tak je nutné dát R/C člen kondenzátorem ke vstupu toho vstupního zařízení, ať je to co je to.
Bude-li to naopak, tak obráceně, budeš odrušovat vstup do čidla.

Co bys chtěl odrušit od procesoru?
Potřebuješ tomu čidlu zajistit hladké napájení. Je to vevnitř částečně analogový obvod a dobře vyfiltrované napájení je důležité, pokud to má dávat nějaké rozumné výsledky. Proto kondenzátor přes napájecí piny.

U ESP má případně smysl snížit rychlost hran malým sériovým odporem. Něco mezi 22R a 68R. Ale to platí u dlouhých vedení.
A u těch dlouhých pak má smysl dát na konec i antiparalelně malou schottky diodu proti podkmitu úrovně na datovém vodiči.
Ty Dallasy jsou na to dost citlivé.
Ale opět, má to smysl až u dlouhých vedení, řekněme tak od 5m víc.

U mě nepadá na váhu, 1m. Jinak 22-68 Ohm do série? Záleží na výstupních reálných odporech čidla, předpokládám že u tohoto budou velmi nízká a tím pádem i odolná proti rušení bez nějakého odporu 22Ohm, u mě k smíchu...

S tím smíchem a svými smajlíky mi připomínáš naši moudrou eurokandidátku Danuši Nerudovou.
Až budeš mít někdy volnou chvilku tak si něco nastuduj o impedanci vedení, o odrazech na volném konci a podobně.

Komunikace s tím čidlem je tak pomalá, a ESP tak rychlé, že to zvládneš jednoduchým algoritmem s přerušením.

Přerušením čeho?

Podle toho, jak si ten algoritmus vymyslíš. Buď od změny na vstupu pinu, nebo od časovače.

[Cmrnda]

Co bys chtěl odrušit od procesoru?
Potřebuješ tomu čidlu zajistit hladké napájení. Je to vevnitř částečně analogový obvod a dobře vyfiltrované napájení je důležité, pokud to má dávat nějaké rozumné výsledky. Proto kondenzátor přes napájecí piny.

Všechny ty směsice kmitočtů co procesory a místní příslušenství vydává.
O odfiltrování napájení snad nemůže být mezi odborníkama ani řeč, protože to považují za samozřejmé.
Za to u in/out je to potřebné zvážit.

S tím smíchem a svými smajlíky mi připomínáš naši moudrou eurokandidátku Danuši Nerudovou.
Až budeš mít někdy volnou chvilku tak si něco nastuduj o impedanci vedení, o odrazech na volném konci a podobně.

Jen študuj, budeš za to pochválen před nastoupenou jednotkou.

Komunikace s tím čidlem je tak pomalá, a ESP tak rychlé, že to zvládneš jednoduchým algoritmem s přerušením.
Podle toho, jak si ten algoritmus vymyslíš. Buď od změny na vstupu pinu, nebo od časovače.

Aha, , ale dám vědět co jsem prakticky zjistil, narozdíl od študia rádoby bezvadných skriptů.

[Cmrnda]

Asi nějak takhle:
.....

Výborně, funguje na první spuštění, 593ms stačí, míň to nejde, bez zdržování pracovního cyklu. Dík.

[kamils]

Není zač,
ať se daří.

[kamils]

Výborně, funguje na první spuštění, 593ms stačí, míň to nejde, bez zdržování pracovního cyklu. Dík.

Není zač,
ať se daří.

[Kodl69]

tohle už jsem řešil před mnoha lety na arduinu, na časování existuje knihovna http://www.xpablo.cz/?p=421 a potom o žádný zastavování procesoru nejde, dallasu jsem nechával celu sekundu, ono není zas tak moc kam spěchat, ale když uteče zpráva z uartu, tak je to větší průšvih. Ostatně na tohle se používá zase přerušení... Ale jako antiprogramátor o tom vlastně vůbec nic nevím.

[Cmrnda]

No, moment, o zastavování procecoru vůbec nejde, jde o to jak odpojit čekání od sondy od průběhu CPU.
14 let "nový" ?
Mě to funguje, v přeložení nápovědy v samotném kÓdu je napsáno o co tam, a jak běží.

void Ukol_1(void *parametry)
{
while (true)
{
sensors.requestTemperatures();
tempC = sensors.getTempCByIndex(0);
Mereni_DALLAS_OK = true;
Jadro_CPU_DALLAS = xPortGetCoreID();
vTaskDelay(pdMS_TO_TICKS((100)));
//Odložte úkol o daný počet zaškrtnutí. Skutečná doba, po kterou zůstane úloha zablokována, závisí na rychlosti tikání. Konstantu portTICK_PERIOD_MS lze použít k výpočtu reálného času z rychlosti tikání - s rozlišením jedné periody ticku.
//Aby byla tato funkce dostupná, musí být INCLUDE_vTaskDelay definováno jako 1.
//Další informace naleznete v části konfigurace.
//vTaskDelay() určuje čas, kdy se úkol chce odblokovat vzhledem k času, kdy je volána vTaskDelay().
//Například zadání doby blokování 100 tiků způsobí, že úloha po volání vTaskDelay() odblokuje 100 tiků.
//vTaskDelay() proto neposkytuje dobrou metodu řízení frekvence periodického úkolu, protože cesta procházející kódem, stejně jako další úkoly a aktivity přerušení, ovlivní frekvenci, při které se vTaskDelay() volá, a tedy i čas. při kterém se úkol dále provede.
//Viz xTaskDelayUntil() pro alternativní funkci API navrženou pro usnadnění provádění s pevnou frekvencí. Provádí to zadáním absolutního času (spíše než relativního času), kdy se má volající úloha odblokovat.
//@param xTicksToDelay Množství času v intervalech tikání, které by měla volající úloha zablokovat.
}
}