NanoSpotWelder

Az utóbbi időben - teljesen véletlenül - rákattantam a diy ponthegesztők tervezésére és  megvalósítására. Már a korábbi analóg ponthegesztőm építése közben megfogalmazódott bennem, hogy érdemes lenne egy mikrokontrolleres vezérlésű készüléket létrehozni. Korábban még soha nem dolgoztam Arduino-val (nem is ismertem), nagy néha az Intel MCS51-es család közelébe sodort az élet. Az Atmel processzorok közül is csak az ATtiny45-t ismertem, mert egy csapatépítő tréningre - egy megoldandó feladatként - építettem egy morze csipogót, de ennek is már jó 8-9 éve. Szóval nem mondhatni, hogy nagy gyakorlatom lenne a mikrokontrolleres környezetben, de valahol mégis csak  informatika, az meg elég közel áll hozzám. Lássuk, hogy hogyan alakítottam ki nulláról egy Arduino fejlesztői környezetet, valamint, hogy hogyan alakult az Arduino Nano-val valamint egy Atmel ATmega328P mikrokontrollerrel kivitelezett ponthegesztőm!

Követelményspecifikáció

A témával kapcsolatos leírásokat áttekintve a megvalósítandó kütyümmel szemben az alábbi elvárásokat támasztottam:

• MOT (Microwave Oven Transformer, mikrohullámú sütő transzformátor) alapú legyen. A MOT-ot vezérlő teljesítményelektronika egyezzen meg a már bevált analóg ponthegesztőével. Ha ott már bizonyított, akkor itt is jó lesz.
• MOT túlmelegedés védelem. Erre a "feature"-re azért van szükségem, mert bár egy sima, rövid impulzusú ponthegesztés során nem igazán melegszik a MOT és a vezérlő triac, de én azért szeretném vallatóra bírni a kütyümet, feszegetni a határait. Ilyenkor huzamosabb ideig elég számottevő áramok folynak, az elektróda kábelek igen át tudják melegíteni a MOT-ot, így elkel a hűtés. Viszont ha már egy proci a vezérlő, akkor legyen beállítható egy riasztási hőmérsékleti érték és a ventilátor kapcsolása is legyen automatikus: a riasztási hőmérséklet előtt 10°C-al kapcsoljon be és ki.
• Csak az akkucellák/akkutelepek ponthegesztésének támogatása. Az analóg ponthegesztőmnél a cserélhető elektróda "applikátorok" kialakítása sok energiát felemésztett, mind a befektetett munka, mind az elérhető rövidzárási áram tekintetében. Így a kötött (nincs nagyáramú csatlakozó, nem szerelhető le) elektródás kivitelt célzom meg, persze az elektróda végek könnyített cseréje még beleférhet.
• Kettős, impulzusszámlálás elvén működő időzítés. Itt ,itt és (egy kicsit elnagyolva, de) itt található cikkekben egészen jól körbejárják, hogy miért is előnyös kettős impulzust használni a ponthegesztés közben. Mivel processzor fogja vezérelni a kütyümet, így igazán nem nagy kihívás egy ilyen szolgáltatást implementálása, tudjon hát ilyen az enyém is! Mivel egyrészt fogalmam sincs, hogy a megvalósítás milyen hegesztési áramot fog produkálni, másrészt a különböző munkadarabok eltérő beállításokat igényelhetnek, így a kettős impulzus paramétereit széles határok között lehessen változtatni. De támogassa a "hagyományos" egy impulzusú hegesztést is. 
• Kézi időzítésű hegesztés. No, nem mintha acéllemezek ponthegesztésére tervezném a szerkezetemet, de egész egyszerűen szeretném megmérni a határértékeket, ezt így tudom a legegyszerűbben kivitelezni. Bár az itt található cikkben van egy ajánlott megoldás, hogy real-time/indirekt módon hogy is lehetne mérni az átfolyó áramot (valószínűleg így az én kütyüm is tudna >1000A-eket), de gyakorlatiasabbnak /korrektebbnek vélem a hagyományos, lakatfogós nagy értékű váltóáramú áramú mérést.
• Grafikus display, egyszerű kezelőszervek. Egy cikkben olvastam egy nagyon klassz és egyszerű megoldást a menükezelésre, gondoltam én is megpróbálom ezt használni. Egy ideig még elgondolkodtam, hogy érdemes-e csupán a karakteres LCD-ket választani, vagy épp OLED kijelzőt kipróbálni, de a Nokia 5110 modul annyira egyszerű és nem túl drága, elég nagy a felülete, így viszonylag könnyű volt a döntés.
• Diszkrét elemekből legyen összerakva a mikrokontrolleres vezérlés. Az alapja egy ATmega328P mikrovezérlő legyen Arduino SW platformon, de támogassa a könnyű firmware upgrade-t, amit a legkönnyebben egy ISP port betervezésével érhetek el.
• Nem funkcionális szempont, hogy - szokás szerint - minél olcsóbban lehessen kihozni...

A fejlesztői környezet kialakítása

Mint azt a bevezetőben már említettem: fogalmam sem volt, hogy mi is az az Arduino architektúra, így hát beleástam magam a különböző leírásokba. Jó sok cikk áttanulmányozása után végül is arra jutottam, hogy egy egész klassz HW/SW környezet: többféle board, nagyon sok és ötletes kiegészítő modul. De ami nekem a lényeg: igen jó szoftveres támogatás: C++, hihetetlen sok library és többféle IDE. Szóval már első olvasatra tetszett a dolog. Így naná, hogy mindenféle tapasztalat nélkül azonnal bele kell vágni!

A leírásokból nagyjából már tudtam, hogy milyen komponensekre lesz szükségem (Nano V3 vagy Uno board a fejlesztéshez, ATmega32P, ISP, 16MHz kvarc, LCD/OLEDdisplay, rotary encoder, stb.) Ezeket meg is rendeltem a távol-keletről (fél sőt harmad áron is hozzá lehet jutni, csak ki kell várni a szállítási időt), de addig is nekiálltam a fejlesztői környezet kialakításának.

Természetesen én is az Arduino IDE-vel kezdtem, egy ideig tetszett (most már lassan csak azért hagyom meg, mert Java-ban van írva) de hamar rájöttem, hogy ez nekem nem annyira jön be: se integrált SCM támogatás, se InteliSense; nehézkes a kódok szervezése; nincs auto-complete; nem használ Make-t, mindig mindent újrafordít; ino a fájlok kiterjesztése... a vége felé már a syntax highlight sem tetszett... De egyfelöl "programnyelvi korrektségből", de inkább a boot-loaderek, továbbá az egyes példakódok vitathatatlanul egyszerűbb feltöltése miatt meghagytam.

Megnéztem az Atmel Studio-t: az MS Visual Studio core - bár nem ébresztett jó emlékeket bennem - ugyan nem riasztott vissza, de nem igazán boldogultam az Arduino library-k integrálásával. Emiatt hamar tovább keresgéltem, és rátaláltam az Eclipse IDE Eclipse C++ IDE for Arduino pluginra. Egy video alapján (szöveges leírás itt) egyszerűen beállítottam és már használtam is az Eclipse-t Arduino környezetre. Kicsit fura és körülményes a különböző könyvtárak kezelése, de mikor már kezdett a többféle modulok próbálgatása után bonyolulttá válni a kódom és annak az infrastruktúrája, világossá vált, hogy azért ennek is meg van a maga előnye. Az ISP meghajtására az AVRDudess-t használom. 

Az általam használt fejlesztői környezet tehát az alábbi szoftver-komponensekből áll:

• Eclipse IDE for C/C++ Developers, Oxygen.3a Release (4.7.3a)
• Eclipse C++ IDE for Arduino
• AVRDudess
• Arduino IDE

 A HW komponensek kiválasztása 

Mikrokontroller modul

Arduino board

Már a tervezés során célul tűztem ki, hogy nem fogok egy board-ot beáldozni a ponthegesztőbe, hanem egy diszkrét elemekből felépített mikrokontrolleres környezet fogja meghajtani a kütyümet, viszont a firmware fejlesztése alatt mindenképpen szükségem volt egy 'bóti' modulra, azon mégis csak hatékonyabb a tesztelés. Az egyes Arduino board-ok specifikációjának átolvasása után ugyan elegendőnek ítéltem meg a Micro típust is, de nem igazán akartam birkózni a fejlesztés során egy USB-TTL illesztővel, így az Uno-ra és a Nano-ra  esett a választásom. Az Uno azért kellett, mert a DIP28-as chip kivitele azzal kecsegtetett, hogy egyszerűen a proci áthelyezésével letudom a firmware beírását a diy ponthegesztőmbe, a Nano-t meg csak a biztonság kedvéért szemeltem ki. Nos, nem minden alakult a terv szerint... 

Az egyes board-ok ára (<800Ft) miatt tulajdonképpen fel sem merült bennem a nem klón választása. Viszont az egyes Arduinoval foglalkozó blogok, fórumok és videók áttanulmányozása során világossá vált, hogy lényegében minden lehetséges problémára fel kell készülnie annak, aki a távol-keletről kíván Arduino board-okat használni: változatos UART chipek, hibás/hiányzó bootloader, soros kommunikációra képtelen board, stb.). Így eleve többféle Nano-t rendeltem (ezt, ezt és ezt), persze nem épp emiatt: még van néhány Nano-s projekt ötlet a fejemben. 

A várakozásokkal szemben egyik board-al sem volt komolyabb konfliktusom, mindegyik működött (a maga módján), egyiknek sem volt bootloader baja. A CH340-es UART illesztőkkel semmi gondom nem akadt, semmit sem kellett telepítenem, elintézte az oprendszer. Az Uno board-al egy kicsit "megjártam": egy SMD kivitelűt nyertem egy aukción (~850Ft), így buktam az egyszerű proci áthelyezéses firmware égetéses módszertant. De sebaj, próbálgatásokra jó lesz, és amúgy is felkészültem a hasonló problémák kezelésére.

 A különböző Nano-knak sem volt eget verő problémája, de csak az első típust tudom kifogástalannak mondani.

A második típusnál (kissé nagyobb proci, egysorban a LED-ek, forrasztás oldalon a CH340-es UART) a program soros porton történő feltöltése előtt meg kell nyomni a reset gombot, gondolom a C4 kondi hiányzik vagy épp kicsi az értéke. A harmadik fajta Nano (nekem a legszimpatikusabb, minden egy oldalra integrált) viszont csak 56K-val hajlandó kommunikálni, de ez sem gond: az IDE-k boards.txt-jébe egy újabb Nano típust vettem 57600bps soros port sebességgel fel és ennyi.

ATmega328P mikrokontroller

A kész kütyübe szánt mikrovezérlőt szintén olcsóbban kívántam beszerezni.  A távol-keleti kínálatban létezik olyan - pár forinttal drágább csak - mikrovezérlő, amelybe beégették már a bootloader-t, de erre nekem semmi szükségem. Már 450Ft-tól elérhetőek (én 395Ft-ért aukcióztam), de sajnos még ez sem érkezett meg a cikk írásáig, így dupla áron a hazai forrásból pótoltam. A 16MHz-es kvarc, lemezes IC foglalat a hazai viszonylatban is igen olcsó, csak a szállítási költség dobja meg egy kissé (nagyon).   

ISP

A diszkrét elemekből felépített vezérlő modul miatt - de amiatt is, hogy valószínűsítettem, hogy majd lehetnek problémáim az egyes board-ok felélesztésével kapcsolatban - eleve készültem az ISP beszerzésére is. Mivel ebből is rengeteg implementáció létezik, így ez esetben is többfélét gondoltam, hogy kipróbálok. (Egy ilyen ISP-m volt a korai időkből, de nem sikerült már feléleszteni az újabb oprendszereken). USBtinyISP (ez és ez) és USBasp (ez) típus is rendeltem (az USBasp Windows 10 driver beállítása itt). Az USBtinyISP-hez ezt a drivert használtam. A kedvencem - a mérete miatt - a legkisebb kivitelű, az ATtiny44 alapú ISP, gyakorlatilag csak ezt használom (bár az USBasp meglepően gyors, lehet, hogy később új kedvencem lesz....)

BreadBoard

Nagyon tetszett a forrasztásmentes próbapanel ötlete, még soha nem próbáltam, gondoltam itt az ideje. Nem elrettentő az ára - persze néhány fajta patch kábel is kell hozzá - cserébe eszetlen gyorsan össze lehet tákolni egy kapcsolást. Persze ezekről is olvasgattam/néztem riasztó leírásokat, de nem gondoltam túl nagy kockázatnak a kipróbálását, én ezt szereztem be (bár a tápegységet egyáltalán nem használom, a kapcsolója meg az első használatkor meg is adta magát). Nano-val való kísérletezés esetén érdemes beruházni egy IO shield-be is, így lényegesen több hely marad a breadboard-on a többi alkatrésznek.

Nokia 5110 LCD és a KY-040 rotary encoder modulok

Korábban már említettem, hogy honnan a menü ötlete, ami a Nokia 5110 LCD és a KY-040 rotary encoder modulokat is predesztinálta. Persze a fejlesztés közben kiderült,  hogy a menü kódja nagyon sok "drótozott" komponenst tartalmaz, így az én megoldásomban gyakorlatilag csak a menü "hangulati képe" maradt meg, a többi teljesen átdolgozásra került. A Nokia 5110 LCD modulokról is sok - néhol egymásnak merőben ellentmondó - információkat gyűjtöttem be, amik alapján szintén több forrásból több példányt szereztem be (ezt, ezt és ezt). Sajnos már nem tudom megmondani, hogy mely forrásból származik a modul (tök ugyan úgy néz ki mindegyik), de van egy modul, ami csak és kizárólag 5V-ról hajlandó menni és kell neki - a későbbiekben kitérek rá - az  adatvezetékeken a szintillesztő ellenállások. Cserébe viszont működik a contrast és a bias állítás. A másik kettő forrás esetében viszont teljesen mindegy, hogy 3.3V vagy 5V-ról van-e hajtva, nem kell nekik a szintillesztő ellenállások, de "cserébe" nem működik a sem contrast, sem az előfeszítés állítás...

 A KY-040-es modul kapcsán nem találtam semmilyen olyan információt, ami okán több forrást kellett volna kipróbálnom, én innen szereztem be, igen kedvező áron.

Hőmérő szenzor DS18B20/LM335

A tervezés alatt a Dallas DS18B20 digitális hőmérő szenzorát gondoltam használni, de a cikk írásáig még nem érkezett meg. Egy ideig kotorásztam az alkatrészeim között és találtam néhány LM335-ös analóg precíziós szenzort, amit más esetben messze elkerülnék (ezért is maradtak meg), de az ATmega328P-nek van A/D bemenete, így ezt használtam fel. Mindenesetre a firmware-t felkészítettem arra, hogy akár egy DS18B20-ast is könnyen be lehessen vetni. A DS18B20 szenzort innen rendeltem, a hazaihoz képest majd harmad áron. 

A kapcsolási rajz

A NanoSpotWelder két kapcsolási rajzát is közre adom. Az egyik a kész áramkör (ATmega328P alapú) a cikkbe illesztve. A másik a Nano board-dal próbapanelon összedrótozott deszkamodell rajza kattinthatóan.

Aki nem sajnál egy Arduino Nano vagy épp Uno boardot beáldozni és beépíti a ponthegesztőjébe, annak nem kell IPS-ről gondoskodnia: a firmware feltölthető a szokásos módon, USB portról.  A rajzokon a DS18B20 hőmérő szenzorok vannak feltüntetve, az LM335 bekötése csak annyi módosítással jár, hogy csak az anódja és a katódja van bekötve (az adjust nem), és ugyan azt az R4-et (4k7) használom felhúzó ellenállásként, mint a DS18B20 esetében. (A viszonyításhoz a rajzon hagytam a DS18B20 szimbólumát is.) Persze az adott  hőmérő szenzor használata a firmware-ben is újra fordítással jár majd.

A "barebones" (diszkrét elemekből összerakott) Arduino lelke egy ATmega328P mikrovezérlő, a szokásos bekötéssel (talán az AREF, 21-es pin bekötése nem a szokásos), ISP porttal. A ponthegesztő kisfeszültségű áramellátását egy min. ~9V-os trafó biztosítja, amelynek egyenirányított - de még nem simított - jelével hajtjuk meg a 4N25-el kivitelezett ZCD (Zero Carrier Detect) áramkört. A ZCD a mikrovezérlő D2-es bemenetét (megszakításként) vezérli. A "raw", 100Hz-es hálózati impulzus jel leválasztásáról D2 dióda gondoskodik.

Nem egy túl bonyolult a kapcsolás, így az egyes komponensek funkciójáról csak pár mondatot ejtek. Az +5V-os egyenáramú tápot egy egyszerű LM7805-ös stabilizátor IC, az LCD számára a 3.3V-os tápot egy LM78L33 szolgáltatja. A Q3-as tranzisztor kapcsolja a ventilátort, a Buzzer1 passzív piezo hangszóró pedig a menü aktivitásakor valamint a riasztás során biztosítja a hangkeltést. (A Buzzer1 nekem egy korábbi projektemből (csavarbehajtók felújítása) a li-po akku őrökből kiszerelt buzzerek egyike.) LED2 a hegesztési ciklus alatt aktív (LED1 a hegesztési pulzusoknak megfelelően "villog"), tehát addig világít, amíg a hegesztési protokoll véget nem ér, vagy kézi vezérlésű hegesztés alatt amíg S1 nyomva van. Az S1 lábkapcsoló indítja a hegesztést. A hegesztő beállítását az U2-es LCD és a KY-040 rotary encoder modul szimbóluma biztosítja. A KY-040 modul könnyebb bekötése miatt a rajzon feltüntettem a modulra nyomtatott PIN jelzéseket is. Fontos a KY-040 modul esetébe a C1 (itt lehet bővebben olvasni róla), ajánlott értéke 470nF, én 1uF-ot használtam. A MOT vezérlését az analóg ponthegesztőnél már megismert MOC optodiak  biztosítja, LED1 itt is csak diagnosztikai célokat szolgál, de akár kivezethető az előlapra is, elég látványos lesz tőle a kütyü.   

A kapcsolás nem érzékeny az optodiac  típusára, lehet akár nullátmenetes MOC-ot használni pl.: 3063, vagy épp a 3020-as random-phase kivitelt is, mivel szoftveres nullátmenet kapcsolás van, így ez indifferens. Amennyiben valaki a firmware-ban mégis átvezetné a későbbiekben említésre kerülő, az induktív terhelések okozta áramkésés miatti bekapcsolási késleltetést (sinusMax), úgy már csak a random-phase típusú MOC-ok használhatóak!

A PCD8544 alapú LCD modulok - by design - 3.3V-os tápfeszültséget igényelnek, míg a mikrovezérlő 5V-os szinteket ad ki. Sok - ezzel a témával foglalkozó - cikk (pl: itt, itt, és itt, de itt még jól le is beszélik az olvasót a modulról) említi, hogy érdemes szintillesztő ellenállásokkal ellátni az LCD adatvezetékeit. Nos, nekem a 3-ból csak egy olyan LCD modulom akadt, aminek kellett a szintillesztés, de az is 5V-ról volt csak hajlandó elindulni. Az én modulom a 10k-15k- ellenállás érték tartományhoz ragaszkodott, sem alatta, sem felette nem volt hajlandó a modul megszólalni, csak az ebbe a sávba eső ellenállások esetén. A többi LCD modult 3.3V-ról és szintillesztés nélkül hajtom (és nincs is contrast...).

Az Arduino Nano  V3-as board verzió deszkamodell "bekötési képét" itt lehet megtekinteni, a képen jól látszanak a "deviáns" LCD modulom szintillesztő ellenállásai. De valószínűbb, hogy a többi LCD modulom a deviáns, mivel azoknál nem működik a contrast/bias állítás...

 A firmware

 A ponthegesztő vezérlő programja a github-ról tölthető le. A kód egy Eclipse C++ Arduino projekt. A stabil firmware a git master branch ágán érhető el, míg a fejlesztéseket a developer ágban végzem, tehát onnan nem nagyon érdemes letölteni a projektet, nem minden van abban az ágban kipróbálva.  A kód bőbeszédűen van kommentelve, a jobb érthetőség miatt.

Minden processzoros eszköznek a firmware szolgáltatásai szabják meg termék tudását, gyakorlatilag itt is erről van szó: a vezérlő program van felruházva mindenféle okossággal, hogy a ponthegesztőt kényelmesen és hatékonyan lehessen használni. A ponthegesztő elemi impulzusát - amit számol - a hálózati frekvencia két utasan egyenirányított értékét jelenti, tehát 50Hz hálózati frekvencia esetén ez 100Hz, aminek a periódus ideje 10ms. 

A kettős impulzusszámlálás a firmware-ben az alábbi fogalmakkal van implementálva.

 Az következő ábrán egy virtuális szkóp csatornái segítségével alkothatunk képet az egyes jelalakok időbeli alakulásáról. A "Vezérlés" felirat a triac vezérlését jelzi (D12),  a "ZCD" a nullátmenet figyelést (D2), míg a "MOT" a transzformátoron mérhető jelalakot illusztrálja. A képen megfigyelhető a még fejlesztés alatt lévő V0.0.2 firmware által bevezetett "Packet" (hegesztő impulzus csomag) fogalma, az újabb verzió már lehetővé teszi az egyes csomagok ismételhetőségét 1-255 darabszámmal, az egyes csomagok közötti "Packet pause" várakozási impulzusszámmal.

 Egyes leírásokban (pl.: itt) megemlítik, hogy az induktív terhelés esetén 90º-ot késő áram miatt érdemes a triac  bekapcsolását is eltolni az áram maximumára (a kódokban "sinusMax"-ként hivatkoznak erre a késleltetési értékre), magyarul: a triac-ot a feszültségcsúcson kell begyújtani.. Ezen viszonylag elég sokat gondolkodtam és kísérletezgettem is, de számottevő/érezhető hatást nem tapasztaltam, így kiirtottam a kódból is, indokolatlanul bonyolulttá tette azt.

A firmware teljes UML osztálydiagramja az alábbiakban látható.

NanoSpotWelder (NanoSpotWelder.cpp)

A program központi eleme a NanoSpotWelder Arduino komponens, a szokásos setup() és loop() függvényekkel. A setup() függvény példányosítja a szükséges segédosztályokat, és beállítgatja a program működésének paramétereit.  A loop() függvény kezeli a rotary encoder és a weld button állapotának változását, valamint szükség esetén a konfigurációban történt változások mentését az EEPROM-ba a Config osztályok keresztül. 

A ponthegesztő firmware-ének központi függvénye a  weldButtonPushed(), amely az S1 lábkapcsoló lenyomásakor kapja meg a vezérlést. A függvény kiértékeli, hogy kézi vagy impulzus hegesztés van-e beállítva, és ennek megfelelően vezérli a processzor PIN_TRIAC lábát. Impulzusszámlálás üzemmódban a függvény a PIN_ZCD lábra, a jel lefutó élére telepíti a zeroCrossDetect() megszakítási függvényt, majd a ponthegesztési protokoll végén eltávolítja a processzor megszakítási vektor táblájából. Tehát a ZCD (Zero Cross Detect, nullátmenet figyelés) megszakítás csak a hegesztési eljárás alatt aktív, minden más esetben nem. Mivel a zeroCrossDetect() megszakítási függvény a hálózati feszültség nullátmenete közelében kapja meg a vezérlést, és a triac ebben a függvényben vezérelt (késleltetés nincs a kódban) így a triac vezérlése a nullátmenetben történik (emiatt mindegy az optodiac típusa)

A zeroCrossDetect() interrupt függvény egy állapotgépet implementál, melynek state UML diagramja az alábbiakban látható.

A konfiguráció megengedi, hogy az elő-impulzusok számát 0-ra vegyük - ez jelenti az egy impulzusos hegesztési módot -, ilyenkor a szünet-impulzusok számát nem is veszi figyelembe, és egyből a hegesztési fő-impulzusok számlálásába kezd az állapotgép. Normál - 2 impulzusos hegesztés esetén - az állapotgép végig járja a különböző "stációkat", az esetleges ismétlések számosságával.

A többi függvény (mainMenuController(), menuController(), ventilatorController(), stb.) a rotary encoder jeleinek fogadását és az LCD modul vezérlését oldják meg

 Nokia5110DisplayWrapper ( Nokia5110DisplayWrapper.h)

Az osztály az Adafruit_PDC8544 leszármazottja. Eleinte arra gondoltam, hogy a sokféle kijelző (karakteres/grafikus LCD, OLED) sajátosságait fedem el ezzel az osztállyal. De túl nagyra hízott a kód, így már csak szimbolikus funkciója van. Elsősorban az LCD modulok háttér világítását kezeli, de ebben az osztályban próbáltam általánosítani az egyes LCD modulok sajátosságait, nem egészen kielégítő eredménnyel. De hát ami hardweresen olyan, amilyen, azon nagyon nehéz szoftveres eszközökkel javítani... 

Az osztály az Adafruit_GFX és az Adafruit_PCD8544 Arduino könyvtárakat használja.

LcdMenu (LcdMenu.cpp, LcdMenu.h)

Ebben az osztályban próbáltam meg a korábban már említett (itt) - nekem nagyon tetsző - egyszerű és frappáns menüt implementálni. Ebben az osztályban az eredeti kódnak minden bedrótozott menü eleme és helyzeti értéke ki lett gyomlálva, így viszonylag korrekten bővíthető és módosítható. Ha módosítjuk a menüelemek számát (LcdMenu::initMenuItems() metódus), akkor ne felejtsük el az LcdMenu.h fájlban a LAST_MENUITEM_NDX értékét is aktualizálni!

A menü csak az egyszintes modellt támogatja, tehát minden menüelem mögött vagy értékválasztás van, vagy függvényhívás helyezkedik el, de további almenű kép nincs. Az egyes menüelemek kiírását, felvehető értékkészlet intervallumát, valamint az esetleges callback függvényét az initMenuItems() függvényben kell deklarálni. Itt még nyomaiban fellelhető, hogy próbálkoztam az egyes LCD modulok contrast beállításával, de végül is feladtam: némely modul nem hajlandó a contrast kezelésére, az én kütyümben is egy ilyen modul lett beszerelve (vagyis a menüelem nálam végső soron felesleges). Bár nem ez az osztály - hanem a NanoSpotWelder.cpp  menuInactiveController() függvénye a MENU_INACTIVE_IN_MSEC érték alapján - végzi a menü inaktivitás figyelését, de megemlítem, hogy ha nem a fő-képernyőben vagyunk, hanem egy tetszőleges értékbeállításban, úgy 30mp elteltével automatikusan visszalép a fő-képernyőben a menü.

 RotaryEncoderWrapper ( RotaryEncoderWrapper.h)

Az osztály a ky040 leszármazottja, segítségével (+ egy jó nagy kondi a CLK vonalon) egész egyszerűen használható a KY-040 rotary encoder. Az osztályban definiált RotaryEncoderResult típussal az eszköz viselkedése egyszerűen követhető

Az osztály a k040 Arduino könyvtárat használja.

Config (Config.h)

Az osztály biztosítja az egyes beállítások perzisztenciáját, azaz a mikrovezérlő EEPROM-ba való beírását valamint az onnan történő kiolvasását. Működés alatt az egyes konfigurációs értékek a RAM-ból vannak kezelve, az EEPROM-ot (a viszonylag véges írási ciklusok száma miatt) kizárólag az értékek változása esetén piszkálja a firmware.

Az osztály az EEPROM Arduino könyvtárat használja.

MOTTemp (MOTTemp.h)

Ez az osztály csak amiatt született, hogy egyszerűen tudjam változtatni a MOT hőmérsékletét mérő szenzor típusát. Az Environment.h állományban definiált (vagy épp nem) az USE_DIGITAL_TEMPERATURE_SENSOR preprocesszor direktíva értéke (ha definiált, akkor a Dallas DS18B20, ha nem akkor az LM335) határozza meg, hogy milyen a szenzor típusa és annak megfelelően szolgáltatja az aktuális MOT hőmérsékletet.

A firmware jelen állapotában az LM335 szenzort támogatja, ha DS18B20-ast szeretnénk használni, akkor az Environment.h állományból a kommentből ki kell venni (ne legyen kommentelve) az USE_DIGITAL_TEMPERATURE_SENSOR preprocesszor direktívát, majd a firmware újra fordítását követően fel kell tölteni a mikrovezérlőbe és ennyi.

Az osztály az LM335 szenzor esetében az MD_LM335, míg a DS18B20 esetében az OneWire és a DallasTemperature  Arduino könyvtárakat használja.

Buzzer (Buzzer.h)

A passzív piezo hangszóró működtetéséért felelős osztály, elsősorban a magas MOT hőmérséklet riasztáskor aktív, de pl.: az egyes menü aktivitáskor is csippanthat, már ha az a konfigurációban meg van engedve. 

Egyéb, kiegészítő állományok

Defaults.h

Ebben az állományban olyan preprocesszor direktíva konstansok vannak, amivel a ponthegesztő alapértelmezett beállításait tudjuk megadni. Érdemes átfutni, mindegyik jól kommentezett. Az állományban a SYSTEM_FREQUENCY értéke adja meg, hogy milyen hálózati frekvencián üzemel a ponthegesztő. Ha neadj' egy 60Hz-es környezetbe exportálnánk a kütyünket, akkor itt kell az értéket megváltoztatni, minden mást a firmware automatikusan kiszámol.

Environment.h

A header-ben a SERIAL_DEBUG - ha definiált - akkor fejlesztés közben az Arduino board a soros porton (9600bps sebességgel) debug információkat küld vissza, így könnyebb a fejlesztés alatt a nyomkövetés. (Nyilván diszkrét mikrovezérlő esetén nincs soros porti UART, így ilyen esetben érdemes a SERIAL_DEBUG nélkül fordított kódot feltölteni)

Az USE_DIGITAL_TEMPERATURE_SENSOR ha definiált, akkor a DS18B20, ha nem definiált, akkor az LM355 hőszenzort használja a kód. Minden esetben újrafordítást igényel az érték megváltoztatása.

NanoSpotWederPinouts.h

Ebben az állományban van deklarálva, hogy a ponthegesztő processzora (akár a mezei ATmega328P, akár egy Nano vagy Uno board) mely kivezetésén milyen perifériás egységeket talál. Így, ha nem a rajzon megadott bekötést használnánk, elég csak ebben az állományban átvezetni a változtatásokat.

Version.h

A ponthegesztő firmware-jának verzióját tartalmazza.

Menü térkép

A ponthegesztőm menüszerkezete egy egyszintes menü, azaz minden menüelem mögött egy értékmegadás, vagy közvetlen funkcionalitás van, almenük nincsenek.

Főmenü

A főmenüben az aktuális hegesztési paraméterek, valamint a MOT pillanatnyi hőmérséklete látható.

 Kettős impulzus esetén a képernyő első két sorában látható rövidítések jelentése a következő:

• Pc: packet count (hegesztési csomagok száma)
• Pp: Packet pause (hegesztési csomagok közötti várakozási impulzusok száma)
• Pwld: pre weld pulse count (elő-impulzusok száma)
• Paus: pause pulse count (az elő- és a fő-impulzusok közötti szünet impulzusok száma)
• Wld: weld pulse count (fő-impulzusok száma).

Weld mode

A hegesztés módját állítja be. Felvehető értékkészlet: "Manual" vagy "Pulse". "Manual" esetén a hegesztés addig aktív, amíg a lábkapcsoló le van nyomva, míg a "Pulse" módban a beállított impulzusok számlálásával határozza meg a ponthegesztő az időintervallumokat.

PreWeld pulse

Az elő-impulzusok számának beállítása itt történik, 0..255 intervallumban. A 0 érték azt jelenti, hogy nincs elő-impulzus (sem a pause), azaz csak fő-impulzus lesz. A képernyőn azonnal látszik, hogy a beállított impulzus érték mekkora időbeli értéket is jelent ezred-másodpercben, vagy épp másodperc + ezred-másodpercben. (Jelenleg az 50Hz-es hálózati frekvencia van beállítva, ez a Defaults.h állomány SYSTEM_FREQUENCY értékével állítható)

Pause pulse

Az elő- és a fő-impulzus közötti szünet beállítása (impulzusszámokban kifejezve), értékkészlet: 0...255.

Weld pulse

A fő-impulzus beállítása, értékkészlet: 1...255.

Packet count

Hegesztési csomagok ismétlésének száma, értékkészlet: 1-99 (a firmware v0.0.2-es verziójától)

Packet pause

Hegesztési csomagok ismétlése közötti szünet beállítása (impulzusszámokban kifejezve), értékkészlet: 1-255 (a firmware v0.0.2-es verziójától)

MOT T.Alrm

A MOT hőmérséklet riasztási értékének beállítása. Ezt elérve a ponthegesztő csipog és figyelmeztető üzenetet jelenít meg a képernyőjén. A riasztási hőmérséklet előtt 10°C-al a ventilátor be- ill. kikapcsol. Felvehető értékkészlet: 50..90ºC

LCD contrast

Az LCD contrast beállítása, jelen esetben az aktuális modulommal nincs hatása. (Értékkészlet 0..127)

LCD light

Az LCD háttérvilágítás be- és kikapcsolása, értékkészlet: "On"/"Off"

Beep

A menü aktivitását visszajelző csipogás be- és kikapcsolása, értékkészlet: "On"/"Off"

Fctry reset

Gyári beállítások visszaállítása. Ezt a menüt választva a ponthegesztő a firmware-ba beállított default értékeket állítja vissza (A Defaults.h állományban deklarált értékek)

Exit menu

A menüből való kilépés.

A firmware feltöltése

A kész ponthegesztőnél a lefordított hex firmware állomány feltöltésére az AVRDudess programot használom, IPS-ként az USBtinyISP-t bevetve. Az AVRDudess beállítása a képről megtekinthető, de gyakorlatilag csak a "ATmega328 barebones (16MHz)" presets értéket kell kiválasztani. Nem várt feature, hogy az ISP adatvezetékeire kerültek a Buzzer1 és a LED2 végpontjai, így a program feltöltése alatt klassz betárcsázós modemszerű hangokat lehet hallani, de nem zavaró (sőt!), hát így hagytam. Egy kicsit zavaróbb - de ez sem akkora baj - hogy az ISP a feltöltés alatt az USB portról tápot ad az egész kütyünek, ami viszont az LM335 hőszenzor esetében fals mérést, végeredményben indokolatlan riasztást eredményez, még a ventilátor is elindul(?!). Ugyan ez csak a kisebbik (lila) ISP esetén fordul elő, de mindegy, már így marad, csak nagy néha frissítem a firmware-t, addig meg kibírom az indokolatlan pánikot: az egész feltöltés ellenőrzéssel együtt ~40mp-ig tart (~21kB a firmware mérete jelenleg).

A Nano alapú deszkamodellt csak fejlesztési időben használom, a programot a szokásos módon (soros UART-on keresztül, USB-n) az Eclipse IDE-ből töltöm fel a Nano board-ra.

A firmware továbbfejlesztési lehetősége

Idő hiányában - már a sarkamban vannak más projektek - nem volt már lehetőségem néhány ötletet implementálni, de leírom, hátha valakiben megfogan az ötlet. Ilyen a hegesztendő anyagok  különbözősége okán (EEPROM hely még van bőven) ki lehetne alakítani profilokat, amelyekben a beállított impulzus értékek eltárolhatóak lennének. Így nem kellene  pl.: munkadarabváltás  esetén újból beállítgatni az egyes időzítési értékeket.

 A firmware egy open source projekt, szabadon felhasználható, átírható, terjeszthető, eladható, stb. (Apache2 licensz -> ~ ne írd át az eredeti szerzőt a forrásokban; jelöld meg, hogy honnan származik, stb.) . Ha valaki sajátjának szeretné a bekapcsoláskor megjelenő "splash screen"-t, akkor ne feledkezzen el "aktualizálni" az LcdMenu::drawSplashScreen() metódusában a képernyő megjelenítését (itt)...

A ponthegesztő kialakítása

Ebben a projektben csak egy kisebb (DB-80DEA, talán 860VA?) típusú MOT-hoz jutottam hozzá, ez érezhető is a rövidzárási áramában. A szekunderét 3 menet Ø16mm² ívhegesztő munkakábel alkotja, aminek kivezetései közvetlenül az elektróda befogó adapterekhez megy 55cm hosszban, így nincs a nagyáramú körben csatlakozó. A hőmérő szenzor  - jelen pillanatban az LM335 - a munkakábel és a vasmag közé lett szorosan behelyezve (a képeken kék zsugorcsőben látszik). A munkakábelek egy-egy PG11-es tömszelencén keresztül lettek kivezetve a dobozból. 

 Az elektróda befogók egy-egy 10cm hosszúságú Ø10mm-es lágy vörösréz csőből lettek kialakítva. A végükre egy nagyobb, Ø6,5mm-es sorkapocs (csoki) egy elemének félbevágott része került hőlégfúvós forrasztással. Az elektródákat Ø6-os vörösréz pálcák alkotják 3-4 cm hosszban, melyeknek az egyik végét kissé hegyesre alakítottam ki (diy eszterga: egy fúróba befogva laposreszelő segítségével). Az elektróda befogókat és a munkakábeleket sajtolással (satuba fogva) rögzítettem egymáshoz, majd egy kicsit még rásegítettem a kontaktusra forrasztással is. A befogókat zsugorcsővel burkoltam, így már egész tűrhetően néznek ki.

   A kész kütyü egy KRADEX KP14-es műanyag asztali műszerdobozba került elhelyezésre, minden kényelmesen elfér benne. Az LCD-t és LED2 kontroll LED-et ragasztópisztollyal rögzítettem az előlaphoz, a KY-040-es modult a jobb mechanikai tartás miatt csavarozással.  A jobb hűtés miatt nem véletlen, hogy a doboztető és az aljzat bordázott szellőző része az előlap felé került! A szerkezet hűtéséről egy PC táp bontásából származó 12V-os ventilátor gondoskodik (a dobozból kifelé fúj).

A kész ponthegesztő üresjáratban 2.8V-ot, teljes rövidzárban 622A-t adott le.

Mi mennyibe került?

Következzék hát a legfontosabb kérdés - engem is nagyon érdekel!! - hogy mégis mennyiből lehet kihozni egy ilyen, mikrokontroller által meghajtott ponthegesztőt? Az alábbi táblázatban azokat a tételeket sorolom fel, amik feltétlen szükségesek, a fejlesztői/kényelmi eszközöket (Nano V3 board, breadboard, stb.) nem. No meg azokat sem tételesen (ellenállások, kondik, próbanyák, LED-ek, biztosíték, csatlakozók, stb.), amik általában igen olcsók, és lehet, hogy van is készleten, ha már az ember egy ilyen készülék létrehozásában gondolkodik. Ezeket egyéb tételként írom be, "hasra ütéses saccolással" megállapított árral. Amik ugyan voltak nekem (feszstab IC-k, MOC, 4N25, BTA41, stb.) alkatrészek, azokat is feltüntetem a HESTORE áraival, úgy is onnan rendelném őket. Amiket meg eleve onnan rendeltem, azokat meg is jelölöm.

 (2018.05. havi árak)

Tehát ~13eFt-ból ki lehet hozni a ponthegesztőt úgy, hogy a valószínűleg húzósabb tételek (MOT, segédtáp trafó, próbanyák, stb.) voltak, és minden más egyebet vennék.  Persze ha még ezeket is be kellett volna szereznem, akkor lehet, hogy már 20eFt körül járnék, de pl.: eladásra biztos, hogy legalább a másfél- kétszeresét kérném...