PID szabályzó nem egy egyszerű frekvencia kitöltési tényezőjének %-os változtatása.
PID egy elég bonyolult szabályzási forma
Mint a neve is adja Proporcionális integráló deriváló szabályzás. a kimenet matematikai képlete felírva kb 5cm hosszú

A 10 ben már benne van a PID komponens , ha a 8 ban nincs akkor jobban jársz ha megelégedsz egy pwm vezérléssel . Egy számítás a kiöltés értékére Duty= 255*((beállított -mért) / beállított ) Emellé használsz még egy elágazást ami 0 ra állítja a kitöltést ha a mért- eléri a beállított értéket.
Lehet hogy van profibb számítás , nekem ezt sikerült "megszülnöm"

Azt néztem én is, de nekem Kínai, hogy miért kell ilyen bonyolítást egy ilyenbe belevinni. Adott 100C elérése, alatta vagyunk, akkor fűtés bekapcsol, elértük minden rendben! Csak a túlfűtést kell valahogy elkerülni.

Ezért kell a PWM ahogy közelít a beállított hőmérséklethez a mért érték úgy csökken a kitöltési tényező (csökken a fűtőteljesítmény) és a végén a 100 foknál már csak időnként 5-10% körüli kitöltéssel pici ideig ráfűt ...

Egyszerü a msgyarázat, a PID tudja tartani az adott hőfokot minimális histerezissel, gyorsan reagál egy hőmérséklet változás miatti korrekcióval. Amit te gondolsz az elég nagy lengéssel fogja, sőt lehet olyan körülmény amikor el sem fogja érni a kivánt hőmérsékletet, vagy csak nagyon lassan.
Röviden fogalmazva, ég és föld a különbség.
Természetesen minden hütés fütési feladat nem igényel PID szabályzást.

A legújabb verzió

https://www.flowcode.co.uk/download/ Megjelent a 11

Pic16f628

Sziasztok! Rs232 kommunikációt kezelő programot szerkesztettem 600-as bitrátával. Első körben, mivel csak kisérletezgettem, arduino megára programoztam. A progi szépen is működött, ezért átszerkesztettem 16f628a-ra. Azt tapasztaltam, hogy 1 bit szélessége sokkal kisebb lett, olyan, mintha nagyobb bitrátára programoztam volna, így a slave már nem olvassa. A program(flowcode 6) saját rs232 modulját használtam mindkét esetben, az oszcillátol beállítás is ok. Mi okozhat még ilyen hibát?

Konkrétan és nagy biztonsággal nem tudok válaszolni, csak tippelek, saját tapasztalatok alapján.

Lehet, hogy nem jól adtad meg a programban a kontroller órajelét. Ilyenkor szokott (látszólag) gyorsabban vagy lassabban működni a program.

Ha az "átszerkesztés" alatt azt érted, hogy a kész, működő programban egyszerűen átállítottad a mikrokontrollert, akkor könnyen lehet, hogy ez a hiba. Ez a módszer nálam soha nem volt jó, mindig hibásan működött a program. Csak az segített, ha indítottam egy új projektet az új kontrollerrel, újra megcsináltam annak beállításait és a régi projekt exportált makróit importáltam az újba. A makró export/import nagyban könnyíti a helyzetet, a változókat viszont újra létre kell hozni az új projektben.

Köszi a választ, program fordítás közben észrevettem a megoldást: 20MHz-es órajellel dolgoztam, a program futtatása közben kiírta, hogy túl alacsony ehhez a 600- as baudrate. Gondolom automatice magasabbat állított be. Váltottam 8MHz-re, és megjavult

A teszt során felmerült még egy probléma: a kütyü teszi szépen a dolgát egész nap, olvassa a portot és vissza is küldi amit kell. Éjjel magára hagyom, reggelre valahogy mindig megbolondul. Nem fagy le teljesen, látszólag tovább olvas és vissza is beszél, viszont már nem a megfelelő adatot küldi vissza, és a fogadott adat változásaira nem reagál. Megoldás lenne erre a watchdog timer reset? Ha igen, egy rövid programot tudnátok mellékelni, hogyan is kell pontosan használni, mert ha a processzor beállításnál engedélyezem, az áramkör nem működik, gondolom még valami a programban is kell hozzá (gondolom a clrwdt, csak ezt hogy illesztem be, hogy jó legyen?). ...vagy esetleg mi lehet még.

Azt gyanítom, hogy zajos/instabil a kontroller tápfeszültsége és a konfigurációban nincs bekapcsolva a Brown-out Reset (BOREN).

Ez az opció újraindítja a kontrollert, ha a tápfeszültség a biztonságos szint alá csökken. Ha ez ki van kapcsolva és a feszültség adott szint alá esik, akkor nem indul újra a PIC de a működésében zavarok léphetnek fel.

Érdemes bekapcsolni a Power-up Timert-t is. Ez bekapcsoláskor egy kicsit késlelteti a kontroller indulását, jó esetben megvárja, amíg stabilizálódik a tápfeszültség.

A Watchdog tulajdonképpen egy időzítő, amit mindentől függetlenül szabadon fut. Ha a beállított időn belül nem nullázod, újraindítja a kontrollert. Ez elsősorban akkor hasznos, ha valami miatt "lefagy" a kontroller és nem jut el nullázó parancsig. A lefagyást okozhatja a már említett tápfeszültség zavar és programozói hiba is.
Nevezett kontrollernél kicsit trükkös a dolog, mert választanod kell, hogy az osztót (amivel lehet növelni a Watchdog periódusidejét) vagy a Timer0-nak vagy a Watchdog-nak ajándékozod, lásd OPTION_REG nevű regiszter.

Valami zajra gondolok én is, szerintem ez a hálózatról jöhet be. Boren és por reset be van kapcsolva, egész nap elmegy, reggelre a kismanó mégis megbolondítja. Egyébként sima trafós tápon van, 7805-tel és úgy gondolom megfelelően kondizva. Nem tudom esetleg a hálózaton lévő bojler vezérlőjel okozhat-e ilyet? bár az tudtommal valamikor nappal is kapcsol, jelen esetben viszont csak éjjel bolondul meg mindig, reggelre produkálja a hibát. Ezért gondoltam a watchdog timer resetre, csak ezt még nem tudom, hogy kell használni. Érdekes, hogy ha szigetelt csavarhúzóval egy pillanatra a mclr lábhoz érek, a hiba megszűnik és megint ketyeg egész nap hibátlanul. Esetleg megoldás lehet az is, a az mclr lábat bemenetként definiálom? mi történik ilyenkor...

Nem lehet hogy valamelyik változó értéke "túlfut" ?? Az MCLR lábat 10k de inkább kisebb ellenállással húzd fel a tápfeszültségre .

A kapcsolás, fizikai kilakaítás ismerete hiányában nehéz további konkrétumot mondani. Könnyen lehet, hogy egy láb optocsatolós leválasztása is már megoldaná a gondot.Újraindítod a kontrollert, kézzel.

Jut eszembe ez a téma: Mikrokontrollerek zavarszűrése.