CNC Fórum

Na první pohled jsem si všiml v každém kódu jedné věci:

V prvním zbytečně voláš 2x calc_error() a protože v této funkci vždy voláš read_thermocouple(), mohou být výsledky těch 2 volání rozdílné, což způsobí malou nekonzistenci v previous_error. V praxi to asi nebude vadit, ale zavolal bych calc_error() jednou a uložil výsledek do lokální proměnné.

V druhém bych pro výpočet nové hodnoty spark_time použil přímo hodnotu z funkce millis() namísto původní hodnoty spark_time. Bude to pak více odpovídat aktuálnímu stavu časovače a při použití malých hodnot spark_on a spark_off nebude problém s "doháněním" aktuální hodnoty časovače v případě, kdy časovač z nějakých důvodů "ujede" moc dopředu.

pokud
static boolean spark_state = LOW;
chces pouzit k uchovani stavu mezi volanimi funkce nesmi byt lokalni

Najprv si to rozmysli. Prva vec je casovy interval pid slucky napr 100ms, a druha vec jehodnota ktora je vystupom pid regulatora. V tojim pripade dlzka on zaputbnia kurenia napr v sekundach.

Najprv si to rozmysli. Prva vec je casovy interval pid slucky napr 100ms, a druha vec jehodnota ktora je vystupom pid regulatora. V tojim pripade dlzka on zaputbnia kurenia napr v sekundach.

Zatím to mám vymyšlené tak, že jednou za interval (řekněme každou sekundu) změřím teplotu, proženu ji výpočtem, získám hodnoty p, i, d; tyto hodnoty si někam uložím, asi do globální proměnné, nevím kam jinam. Odtud si je pak vezmu na výpis pro ladění přes seriový port, ale hlavně jejich součtem získám PID_hodnotu, kterou aplikuju takto

topeni_on = PID_hodnota
topeni_off = sekunda - PID_hodnota

samozřejmě si to pojistím tak, že:
max PID_hodnota = interval
min PID_hodnota = 0

Jak pise Radhard, modularita je zaklad. Ok, ja bych si pod takovym pojmem predstavil, ze treba ten kod ohledne pid bude proste cerna bedna, kterou nekam kakopiruju, reknu co se do ni sype (teplota realna a pozadovana), a kterym pinem s topnym telesem ma cvakat. Pokud musim pouzivat globalni promenne abych si zapamatoval minule namerenou hodnotu, kterou potrebuju pro dalsi vypocet, tak mi to prijde jaksi polovicate. Nebo to tak normalne chodi a jenom si na to musim zvyknout?

Mr. MR píše: ↑9. 10. 2020, 3:02 Jak pise Radhard, modularita je zaklad. Ok, ja bych si pod takovym pojmem predstavil, ze treba ten kod ohledne pid bude proste cerna bedna, kterou nekam kakopiruju, reknu co se do ni sype (teplota realna a pozadovana), a kterym pinem s topnym telesem ma cvakat. Pokud musim pouzivat globalni promenne abych si zapamatoval minule namerenou hodnotu, kterou potrebuju pro dalsi vypocet, tak mi to prijde jaksi polovicate. Nebo to tak normalne chodi a jenom si na to musim zvyknout?

No tak ta funkce, co budes volat dostane jeste aktualni stav a vrati stav novy, ktery si uchovas v te globalni promenne

Kód: Vybrat vše

static bool heating_state = HEATING_OFF;
...
heating_state = adapt_heating(temp_measured, temp_requested, heating_pin, heating_state);
...

pravdepodobne tam mam 2-3 syntakticke chyby
pricemz konstanty HEATING_OFF a HEATING_ON muzes mit definovane v hlavickovem souboru te knihovny...

prcek píše: ↑9. 10. 2020, 8:03 pokud
static boolean spark_state = LOW;
chces pouzit k uchovani stavu mezi volanimi funkce nesmi byt lokalni

Ale právě proto, aby se uchovala její hodnota mezi jednotlivými voláními funkce je ta proměnná statická. Je velký rozdíl mezi normální lokální proměnnou a statickou.
Normální se vytváří na zásobníku volání a je tudíž při návratu z funkce zahozena (její obou platnosti je pouze uvnitř dané funkce).
Oproti tomu statická proměnná se vytváří na haldě, a je tudíž dostupná počas celého běhu programu. Oproti globální proměnné je viditelná jen v té metodě, kde byla deklarovaná, a tudíž se neplete s dalšími globálními proměnnými.

StoupaCZ píše: ↑10. 10. 2020, 7:35 Ale právě proto, aby se uchovala její hodnota mezi jednotlivými voláními funkce je ta proměnná statická. Je velký rozdíl mezi normální lokální proměnnou a statickou.
Normální se vytváří na zásobníku volání a je tudíž při návratu z funkce zahozena (její obou platnosti je pouze uvnitř dané funkce).
Oproti tomu statická proměnná se vytváří na haldě, a je tudíž dostupná počas celého běhu programu. Oproti globální proměnné je viditelná jen v té metodě, kde byla deklarovaná, a tudíž se neplete s dalšími globálními proměnnými.

Pravdu mas, napsal jsem pitomost.

Jen info:
Teď jsem hledal problém zamrzávání a resetu Arduino DUE s komunikací I2C na OLED display.
Zkoušel jsem posilovat sběrnici rezistory 2k2 proti 3,3V a zlepšilo se to, ale stále se to sem tam (1xmin) zaseklo.
Nakonec stačilo na kablík cca 100mm mezi diplejem a MCU nacvaknout feritový váleček.
Je to pro mě první zkušenost kde opravdu váleček funguje skoro jako zázrak, není tam a reset každých cca 5s, je tam a celý den bez chyby i bez rezistorů.

Třeba informace někdy někomu pomůže.

Cjuz píše: ↑12. 10. 2020, 7:56 Jen info:
Teď jsem hledal problém zamrzávání a resetu Arduino DUE s komunikací I2C na OLED display.
Zkoušel jsem posilovat sběrnici rezistory 2k2 proti 3,3V a zlepšilo se to, ale stále se to sem tam (1xmin) zaseklo.
Nakonec stačilo na kablík cca 100mm mezi diplejem a MCU nacvaknout feritový váleček.
Je to pro mě první zkušenost kde opravdu váleček funguje skoro jako zázrak, není tam a reset každých cca 5s, je tam a celý den bez chyby i bez rezistorů.

Třeba informace někdy někomu pomůže.

To je nějaké divné.
Píšeš, že vedení k displeji má 100mm. Tak pokud nesedíš přímo před anténou televizního vysílače, tak na tom kousku drátu se toho moc nenaindukuje.
Je zbytek zapojení OK? Pull-upy na I2C, zablokované napájení, správné napěťové úrovně atd.?
Řekl bych, že ten feritový kroužek jen trochu posunul nějaké parametry, takže se něco, co je špatně, dostalo těsně za hranu a už to nějak funguje.
Ale chyba tam (podle mě) pořád někde bude.

Mex píše: ↑12. 10. 2020, 8:23
Cjuz píše: ↑12. 10. 2020, 7:56 Jen info:
Teď jsem hledal problém zamrzávání a resetu Arduino DUE s komunikací I2C na OLED display.
Zkoušel jsem posilovat sběrnici rezistory 2k2 proti 3,3V a zlepšilo se to, ale stále se to sem tam (1xmin) zaseklo.
Nakonec stačilo na kablík cca 100mm mezi diplejem a MCU nacvaknout feritový váleček.
Je to pro mě první zkušenost kde opravdu váleček funguje skoro jako zázrak, není tam a reset každých cca 5s, je tam a celý den bez chyby i bez rezistorů.

Třeba informace někdy někomu pomůže.
To je nějaké divné.
Píšeš, že vedení k displeji má 100mm. Tak pokud nesedíš přímo před anténou televizního vysílače, tak na tom kousku drátu se toho moc nenaindukuje.
Je zbytek zapojení OK? Pull-upy na I2C, zablokované napájení, správné napěťové úrovně atd.?
Řekl bych, že ten feritový kroužek jen trochu posunul nějaké parametry, takže se něco, co je špatně, dostalo těsně za hranu a už to nějak funguje.
Ale chyba tam (podle mě) pořád někde bude.

Já to taky nechápu, ale pokud dám na i2c osciloskop tak si ani neškrtne, procesor padá hned ani displej nenaběhne. S feritem jsem schpný průběh měřit, úrovně jsou správné, hrany taky jakš takš, jen je tam nějaké rušení, není to čisté. Chyba - ale, kde ji hledat. Mám teorii že ten OLED něco vrací zpět a celé to pak havaruje, možná je to i tím že MCU u DUE jede na jiné frekvenci než běžná arduina.

Oled vrací kromě ACK bitu něco jen když po něm požaduješ data. DUO stojí na procesoru ARM, ale to je jedno. Důležitý je správný časování (max 400KHz) a strmé hrany (správné pulup odpory).
A nezapomenout - I2C není navržena jako externí sběrna, ale jen pro komunikaci po desce.

Nebo bude někde utržená zem (GND).
A taky bych zkusil zjistit důvod těch resetů, tzn. podívat se do příslušného registru, na základě čeho se ten reset vygeneroval.

Nektere OLED dost rusi, pokud tam mas nejakou prasecinku z hlediska EMC ktera u LCD projde, tak u OLED uz bude problem.
Ferit dost pomuze, ja mam napriklad bezny lcd s hd44780 krmeny plochym kabelem o delce cca 1m ve stroji kde se spinaji rychlym mosfetem desitky amper a bez feritoveho navleku na kabel se taky vubec nechytal. S nim jede zcela bez problemu.

Ked tam mas oled 1,3" tak tam na plosaku chyba jeden kondenzator preto to blbne. Dopln a malo by to byt ok. C2

Skontoluj to.
viewtopic.php?t=2142&start=1200

CNC Fórum

Arduino

Re: Arduino

Re: Arduino

Re: Arduino

Re: Arduino

Re: Arduino

Re: Arduino

Re: Arduino

Re: Arduino

Re: Arduino

Re: Arduino

Re: Arduino

Re: Arduino

Re: Arduino

Re: Arduino

Re: Arduino