Korábban írtam, hogy a JBC forrasztóállomásomhoz készült egy olyan (egyelőre teszt) szoftver verzió, ami a 245-ös pákahegyek mellett, 210-es pákahegyek használatát is lehetővé teszi. Sajnos ezzel kapcsolatban nem sok visszajelzést kaptam, de én azért ezt a szoftvert használtam (bár többnyire 245-ös pákaheggyel), hogy kiderüljön ha valami hiba maradt benne. A tapasztalatom az volt, hogy mintha a 245-ös hőmérséklete "jobban lengene" mint a korábbi szoftverrel, de eddig nem találtam az okát. Ez a teszt szoftver sűrűbben méri a hőmérsékletet, és a PID paramétereket is próbáltam ehhez igazodva beállítani.

Azonban a napokban beugrott egy apróság amit elfelejtettem: a sűrűbb mérés miatt nem csak az P,I,D paraméterek (szorzóit), hanem az I emelkedési/csökkenési sebességének limitjén is igazítanom kellett volna - amit most megtettem. Nem nagy dolog, de most érzésre ugyanúgy viselkedik a 245-ös pákahegy, mint a korábbi szoftverrel. Továbbá úgy tűnik mintha ez a korrekció a 210-es páka szabályzásának is jót tett volna (azzal 210-es pákaheggyel ami nekem van jelenleg, mindössze 1...3 fokot lendül túl felfűtéskor).

Az lenne a kérésem, hogy aki megépítette az állomást, és van kedve/lehetősége tesztelni ezt a szoftver verziót, az próbálja ki, és jelezzen vissza mit tapasztal. Amennyiben már eleve a teszt szoftver futna rajta, akkor a 245-ös pákahegyhez tartozó, default PID értékeken is módosítani kell:
P=24, I=19, D=18
Ezek a korábbi szoftvernek megfelelő beállítások, de a teszt szoftver előző verziója más default értékeket használt eddig.

A szoftver letölthető innen: Skori_JBC245-210_ForrasztoAllomas_TESZT.zip

A PID paraméterek állítása (ez csak ebben a teszt szoftverben van benne):
Középső gomb lenyomva tartva, majd 2x felső gombnyomás, utána középső felenged.
Itt választható a fel/le gombbal, hogy a 210 vagy a 245 beállításait akarjuk módosítani.
Utána középső gomb, majd beállítás.
Kilépés: középső gomb hosszú megnyomása

Figyelem! 210-es pákahegy használata, 245-ös pákahegyhez tartozó beállításokkal károsíthatja a 210-es pákahegyet (eléggé eltérő a termoelem feszültsége)! Erre érdemes odafigyelni. Fordított esetben (245 helyett 210-es beállítás) sem lesz jó a hőmérséklet szabályzás, de más problémát nem okoz.

Szia!
Így van a jövő héten már tervben van a gyártása, addig a P2 nincs is bedugva csak akkor amikor kell.
Üdv: Gábor

Akármilyen ideiglenes fémtartót azért érdemes készíteni, mert e nélkül mindig próbál hőn-tartani a páka. Ha beteszed a tartóba, akkor "pihenni" fog, visszahűl valamennyire, illetve hosszabb pihenéskor teljesen lehűl.

Szia!
Köszönöm mégegyszer a kiváló tervezést!
A pákatartó csatlakozása még nem alakult ki mi és hogyan lesz de tényleg nem egy nagy munka addig is tudom használni.
Üdv: Gábor

Jó lett, remélem ellátja majd nálad is a feladatát, ahogy szeretnéd! Használd egészséggel!
Látom a pákatartó számára a csatlakozások még nincsenek kivezetve - még lesz vele egy kis munka (bár az már pillanatok alatt megvan).

Szia!
Köszi! Csak végszükségre tettem be a gombokat meg egyébként is volt belőle. Ha a rotari meghibásodik akkor tudjam még kezelni, de nem szándékozom üzemszerűen használni.
Üdv: Gábor

Nincs ezzel semmi baj, szép átlátható építés.
Nincs rá szükség, de ha mégis akarnád, akkor nehézkes nyomkodni a vezérlőpanelen lévő mikrokapcsolót, mert a LED-ek vezetéke fölé került. Csak azért említem, mert látszólag elfért volna az állított tüskesor is, amivel elkerülhető lett volna a takarás. Most utólag már ne nyúlj hozzá, sosem lesz szükség arra a gombra.

Szia!
Remélem nem elrettentő példa...
Üdv: Gábor

Szia!
Jóllátod. A befejezést akkorra tervezem, és egyébként is nevezetes dátum nekem.
Üdv: Gábor

Nabumm ! Egy hónappal a határidő előtt készült el ! Miért olyan furcsa ez itt magyarországon ???

A belsejéről is mutass képet, azt is szívesen megnézzük.
Alul a feliratban látok egy kis időugrást, mintha február 19-et mutatna, ami még kb. 1 hónap múlva lesz.

Szia! Az állomás a jövőben készült? Vagy az elején nem a dátum van?

Köszönöm a tippet!

Szia!
A lomexben vásároltam nyomógomb enkóder egyben. Bővebben: Link
Üdv: Gábor

Jól néz ki, milyen enkódert tettél bele?

Sziasztok!
Kicsit ugyan lassan de elkészült a forrasztóállomásom. Skori kolléga állomástervei alapján készült. Néhány önszivatás és elcserélt alkatrésztől eltekintve egyből indult az áramkör. A dobozolás nem a legkedvesebb foglalkozásom, de sikerült bezárni a készüléket. Még két pákatartó elkészítése hátra van akkor lesz teljes a készlet. Két pákát kötöttem rá, az egyik egy eredeti JBC nyél eredeti heggyel, a másik egy Aliról rendelt nyél és hegy. Még hosszan tartó tesztet nem tudtam csinálni mert csak pár napja készült el, de nagyon jók a tapasztalatok. Kaptam javításra egy smd panelt ennek a pákaállomásnak hiányában az IC kukázható lett volna. 170 EUR-os alkatrészről van szó.
Nagyon köszönöm a lehetőséget és a tervezést, kiváló hasznos szerszáma a műhelynek.
Üdv: Gábor

Ne vedd magadra,de továbbra is úgy látom, hogy ebben a projektben a webusb inkább csak egy teher... Ha webfelületen akarnám konfigurálni, paraméterezni, és/vagy frissíteni a szoftvert, akkor ESP8266 vagy ESP32 lenne a megoldás. Mindkettőnek viszonylag erős a processzora, és a forrasztóállomás funkciók mellett is könnyedén beleférne wifi webszerver funkció, ami a frissítéstől kezdve, minden beállítást könnyedén megvalósíthat. Persze értem, neked a webusb használata lenne a lényeg - csak itt feleslegsnek tűnik. A wifi egyúttal tökéletes leválasztást is megoldja, és egy webfelületen simán elférnének pl. hardver konfig bellítások is. A webfelületen beállíthtóvá tennék olyanokat is pl., hogy konfigurálni lehessen melyik gombnak mi legyen a funkciója. Így a hardverre "ahogy sikerül alapon" is beköthetném a ledet, nyomógombokat, enkódert, stb... és a webfelületen pár kattintással beállíthatnám, hogy minden jól működjön... Itt lehetne a PID paramétereket menüben,. webfelületen is állítani, akár sokféle egyedi pákahegyhez is optimalizálva. Igazából kissé komolyabb algoritmussal még a PID beállítást is lehetne automatizálni, ami néhány forrasztás alatt megtanulhatná, hogy az adott pákahegyhez milyen beállítás kell. Mondjuk ennyire nem akartam "túltolni" a dolgot, de ha akarnám, akkor ezek lennének a fő irányok. De a felhasználók zöme (én is) nem akarja folyton az állomás menüjét piszkálgatni, csak forrasztani, és esetleg hőmérsékletet állítani - az állomás meg csak tegye a dolgát, a többi nem érdekeli. Tehát nem kell csicsás kijelző sem (csak valami alap), mert a többségnek a piros/zöld led is bőven elegendő infót ad.
A saját állomásomba is elsősorban mások kedvéért került bele a 210-es pákahegy kezelése. Persze forrasztottam párat 210-es pákával, tényleg jó, főleg apró dolgokhoz, de nem jobb annyival a 245-ösél, hogy ne lennék meg nélküle. Másképp fogalmazva, nekem a 245-ös mindene is elég, ebből már sokféle hegyet bevásároltam, a 210-es pákához csak két pákahegyem van, és lehet, hogy ez már így is marad.

tettem bele minimális ID-t a P már megvolt.
Ami tanulság. Fontos a jó P vezérlés, amit korábban csináltam az már elég jól viselkedik, de az csak a 12V-os betápomra és arra a hegyre igaz ami épp benne van.
A 12V-os 60% -os max PWM-re elégséges a 100ms -es mintavételezés, de ez a hegy többet tud, ha 20V-al és erősebb PWM-el hajtom meg, ott már ez édes kevés (ezt többen írtátok is, de mint írtam én a T12-höz voltam szokva).
Bevált nálam az eltérő ADC mintavételezés. Felfűtés alatt lehet ritkábban, közelítve a beállítotthoz pedig sűrűbben mérni kevesebbet beavatkozni.
Fontos mérni a bejövő tápot, mert változik a 0 hibapont PWM értéke magasabb feszültségnél alacsonyabb lesz jóval.
A WEBUSB nekem bejött. Ugyan még csak ismerkedésben vagyok, viszonylag gyorsan akartam eredményt elérni, ezért alap dolgokat használtam csak. Érdemes jobban elmélyedni benne.
Most már körvonalazódik bennem egy project, ami lehet itt is jobb fogadtatást kap mint ez
Egy USB PD-s T210 vezérlő kijelzővel, ahol MCU végzi a vezérlést és ha gépre kötik, akkor nem lehet vele forrasztani, de a beállítások és FW frissítés elvégezhető WEBUSB-n keresztül. Így akkor nem kell menüben lépkedni a paraméterek beállításához, hanem egy HTML-ben megjelennek a paraméterek és elvégezhető akár azok megváltoztatása is.

Több dologban is haladtam. Először is a kezdeti összetákolt html js-t átírtam egy reactive-ra (én a vue-t favorizálom).
Belekerült egy kódszerkesztő és egy terminál, plusz a diagramot is átírtam és megoldottam, hogy az eddig lekezelt soros portok között lehessen váltani (persze kapcsolódás előtt csak)
A korábbi vezérlésem még mindig nagyon alap volt, az látható is volt, hogy kilengett rendesen.
Volt még egy komoly probléma benne, hogy ha a hiba negatív volt (túlfűtött) akkor lekapcsolt a vezérlés, így a következő mérésnél átesett megint pozitív hibába és így oszcillált. Természetesen erre lenne megoldás a PID.
Próbáltam letudni könnyen, gondoltam veszek egy működő PID kódot és átírom JS-be és meg is vagyok.
Az első probléma amivel találkoztam, hogy nagy hiba esetén az integrál tag nagyon elmegy, de ezt írták is egy forrasztásos oldalon, hogy ne ezzel fűtsünk fel, hanem már csak a közeli értéknél térjünk át (pl addig 0-ás Ki-val)
A másik, hogy egy jól működő P az alap, majd az I-vel kisimítani és a D-vel finomítani.
Ezután végeztem egy olyan vezérlést, ahol egy csúszkán léptetgettem a PWM kitöltést és néztem, hogy kb. milyen hőmérsékletre áll be. Azt gondoltam majd egy exponenciáis függvénynel kell meghatározzam a nulla pontom, de egész lineáris lett.
Lett egy képletem, ahol a beállított érték 15%-a PWM-em, amivel a beállított érték tartható. Azután a hibához még hozzáteszem a beállított érték arányát, abból kiindulva, hogy nagyobb hőmérsékleten nagyobb beavatkozás szükséges.
Ez már egy jóval kiegyensúlyozottabb vezérlést hozott. Ehhez jön majd még az I és a D

Nálam a HW tuningolása még egy későbbi rész, de mindenképp a te kapcsolási rajzod lesz az elősdleges amiből kiindulok. Plusz van egy Unisolder elnevezésű github project, az is egy komolyabb megközelítés. Jelenleg nálam még az LM358-as sokfelé fellelhető opamp-os kapcsolás van. Márcsak azért is, mert az alapból elbírja a nagyobb feszültséget a VDD-n felül, de azért egy diódával védve van.
Ami még a közeljövő problémája, hogy megoldjam a pákafelismerést. Az unisolder readme-ben szépen leírja, hogy milyen ellenállás értékek melyik pákát jelentik.

A Minifor esetében digitálisnak esetleg a ki/be kapcsolását lehetett nevezni. a hőmérséklete meg csak saccolható volt. Amúgy a leírtak talán bonyolultnak tűnnek, de valójában ez csak néhány sor utasítás a programban. Persze a Minifor akkor is felkötné magát, ha megmutatnád neki, hogy manapság milyen SMD alkatrészeket, és milyen sűrűségű elrendezésben kellene beforrasztania Viszont a csehszlovák pillanatpákám, az simán.... Igaz ott a hardveres PWM-et biologiai processzor vezérli, széleskörű optikai adatelemzés mellett.

Szegény Minifor páka tudta volna ezt, felkötötte volna magát a saját drótjára..

Esetemben a PWM kikapcsolása után kb. n*10µs várakozás a tranziensek lezajlására, utána termoelem erősítők bemenetének bekapcsolása, majd további kb. 100us várakozás míg a termoelem erősítő kimenete beáll a megfelelő értékre (mivel az erősítő sávszélessége véges). Utána indul az ADC. Az első néhány mintát eldobom, (tapasztalat szerint az ADC első néhány mérése sokkal gyakrabban hibás, mint a további minták) majd utána további 128db mintából számolom a hőmérsékletet. Ezután az erősítők bemenetét ki lehet kapcsolni (kikapcsolt állapotban egy köztes értékre áll be, hogy következő méréskor ne egy szélső állapotból induljon az opamp beállása), majd a PID számolása után indítható a PWM az új értékkel.
A többi mérés (3.3V, 22V tápfesz, hőmérséklet a dobozban) simán mehet a PWM futása közben is.

Az erősítők bemenetét eredetileg csak a túlvezérlés elkerülése miatt kapcsolgattam, (túlvezérlés esetén a beállási idő, megnövekedne egy további feléledési idővel), de ez a megoldásom, a 210-es páka esetében tulajdonképpen jól jött, mert így a mérőbemenet problémamentesen összeköthető volt a PWM kimenettel. Azok a megoldások, ahol pl. csak dióda védi az erősítő bemenetét jól működnek ugyan, de a túlvezérlést nem kerülik el, így általában hosszabb beállási időkkel kell számolni.

Hogy ki mennyi várakozásra kényszerül a fűtés kikapcsolását követően az messze a konkrét konstrukció függvénye! Emlékeim szerint nálam 12.5kHz a PWM periódusa, ezzel szinkron van indítva a megfelelő időben a mérési procedúra, ahol csak 4-et mérek gyors egymásutánban. Átlagolás után némi szűrés jön. A fűtés leállítása és mérés indítása között kb 150usec idő telik csak el. A teljes mérés idejére már nem emlékszem...
Nyilván így nem lehet(átlagban) a 100% kitöltés elérni, de mivel 24V-os a táp, így azt sosem szabad amúgy sem megközelíteni, még felfűtéskor sem! Ez amúgy is korlátozott, megadható hány W-al fűtse max a hegyet, mert nem fog neki jót tenni, ha 1-2sec-nél gyorsabban akarjuk elérni a 3xxC hőmérsékletet...
A mikrovezérlő nálam egy 103-as STM, kicsit túlhúzva(nem a vezérlés igénye volt ez, hanem a grafikus megjelenítés határait feszegettem)

a 3ms mérési gyakoriságra én azt tudom mondani, hogy más oldalon olvastam, hogy 5ms -ot vár fűtés kikapcsolás után, hogy ne a fűtés feszültésgét olvassa vissza hőelem feszültség helyett.
Szóval 3ms -ba hogy fér bele, hogy kikapcsolod a fűtést, kiolvasod többször (én pl a legtöbb ciklusig tartó ADC mérést állítottam minden kiovasott csatornára, mivel scan mode-ban több ADC-t olvasok) és a kiolvasott értékeket átlagolod?
Az én ADC módom
- 241 cycles ADC csatornánként, ez így ~50khz (0.02 ms) mert van az ADC-n egy 2-es DIV
- 3 csatornát mérek (még lesz egy a belső referencia feszültésgre)
- DMA-val egy bufferbe írom ciklikusan ringbe, folyamatosan a mérési ciklus alatt ami 10ms
- 8 mérésre van a buffer beállítva csatornánként
így a 10ms után közel ~100 mérést végez (DMA interrupt-ra tettem egy számlálót) amiből az utolsó 24 van a bufferben. A három csatornára leátlagolom az értékeket és nekem az a mért értékem.
Olvastam angol nyelvű oldalon, hogy valaki még a bufferen végigmegy és az átlaghoz képest 10% -os eltérésű értéket hibára veszi és megismétli a mérést, de én eddig nem tapasztaltam kiugró értéket.
Persze lehet valami nagy órajelű MCU-t használsz , nekem jelenleg 48Mhz, de akkor is mi van a fűtés kikapcsolási utáni várással és a 3ms mérésközben akkor mennyi idő ameddig a fűtés be van kapcsolva?
A PWM nálam 100KHz-re van osztva, de ez bitenként 100KHz, mivel 255 az autoreload, ezért 1 PWM teljes ciklus 2.5ms ha jól számolom.

mint írtam nem voltak tapasztalataim C210-el, csak T12-vel ahol ez az idő elég volt. Most már vannak így most átgondolom.
A meghajtáshoz pedig 12V 2A-es tápont használok most, ami csak kisebb PWM kitöltést enged, így nem történnek olyan gyorsan a dolgok, Vagyis épp az hogy így is gyors, így még átgondolom.

Gondolkoztam én is, hogy ne fix a mérési időközzel dolgozzak, de végül elvetettem, mert két pákát kell egyszerre kezelni (bár egyfajta ciklus-átugrás lehetőségén azért szintén elgondolkoztam).
Ami miatt mégis elvetettem:
- nem egészen 2msec alatt, 2x 128db mintát tudok venni, azaz ennyiszer mér hőmérsékletet ez idő alatt. Ez még rövid ciklusidő esetén sem okoz számottevő veszteséget a kitöltési tényezőből.
- eleve 22V körüli tápot használok, ami több mint amivel a gyári állomás fűt, tehát még a kitöltési tényező veszteséggel együtt is gyors lesz.
- a 210-es pákahegy felfűtése így is 1sec körül (vagy az alatt) van, szóval belefér... a 245-ös pákahegyek zöme is kb. 6 másodperc alatt felfűt - még az sem vészes. A 150°C-os standby állapotból pedig "egy pillanat alatt" üzemkész bármelyik páka.

Mivel nálad eleve korlátozni kell a kitöltési tényezőt, a jelenlegi hardver esetében, így nem igazán látom értelmét a mérési idő miatti, fűtés kihagyásból eredő, max. PWM kitöltési tényező csökkenésével foglalkozni.

Elgondolkoztam rajta egyébként, hogy (valmikor később, ha ráérek ) az állomásom menüjébe én is beteszek egy beállítható PWM limitet, hogy nagyobb tápfesz, és/vagy mondjuk gyengébb táp is használható legyen.

Gondolj már bele...ha 300msec a fűtés alapegysége, az alatt simán tud 100C-t is emelkedni egy C210-es hegy hőmérséklete!! Hogy lesz ebből használható szabályozás? Sehogy!
Illene legalább +-5C-on belül tartani a hegy hőmérsékletét, és már ehhez is sokkal gyorsabb szabályozás kell...pedig hol vagyunk még egy pontosnak nevezhető +-1..2C- vezérléstől?!
Az én állomásomban kb 3msec a mérési gyakoriság. Ez kb fok pontosságú lekövetést ad... Talán nincs erre szükség egy jól paraméterezett PID szabályozónál, de nem hiszem hogy ennél sokkal ritkább elég lehet egy jó vezérléshez ennél a hegynél....

Sziasztok,
Igen, köszönöm a hozzászólásokat. Nem volt tapasztalatom a JBC-vel kapcsolatban a T12-ővel volt csak, úgy indultam neki, hogy ami ott jó volt itt is jó lesz, de már látom, hogy nem úgy van és teljesen igazatok van.
A JBC heggyel kapcsolatban, köszönöm az aggódásokat, már túl vagyok a kiégetésen.
Nem programhiba hanem kiváncsiság okozta, de láttam vörösen izzani. Fájna is a szívem, ha nem egy kínai klón lenne 1000 Ft-ért (igazából 3000 volt 3 darab).
Este még nem hagyott nyugodni a dolog, mert elég lépcsőzetes volt a vezérlés (ugye én a T12-höz szoktam ott szinte lanykás a meredekség), először arra gondoltam, hogy a hőtehetetlenség, de közben rájöttem, hogy a vezérlés volt rossz.
Itt is úgy van mint T12 nél, hogy vagy fűtünk vagy méricskélün és én ritkán mértem, hogy fűthessek.
Most átírtam a firmware-t ( ha lehet ilyen fellengzősen nyilatkozni a kódomról ), mert 300 ms -ig fűtöttem és ez volt a lépcsőzés oka. A kód még a régi mért érték alapján dolgozott pedig már nem kellett volna a fűtés.
Változtattam a fűtési időn (vagyis a mérési időközön másik megközelítésben), de így meg nem volt olyan látványos a felfűtés.
A megoldás az lett, hogy bevezettem egy mód választót a mérési időre, amit szintén a brózerből vezérlek. A vezérlésben pedig ha még messze a mért a beállítottól, akkor ritkábban mérek (felfűtés mód), ha pedig közelebb van akkor sűrűbben (mérési mód).
Így most a mellékelt képen a jelenlegi állapot. Van még mit csiszolni, de láthatóan jobb .

A 100ms időegység csak az ide berakott adatokra vonatkozik? A JBC 210-es pákahegy rendes szabályozásához ennél sokkal rövidebb időközzel célszerű mérni, és beavatkozni. Gondolom ezen majd módosítasz. Javaslom, hogy a fejlesztéshez készíts valamilyen páka-szimulátort, ne élesben tesztelj mindent, mert nem olcsó egy 210-es pákahegy.