Kategóriák
Munkával kapcsolatos észrevételek, kérések, kérdések, egyelőre egy halomba, minden ami idefér

Hardvertől a szoftverig. Ahhoz, hogy programot írjak, sokszor magamnak kell megcsinálni azt amit kitaláltam.

Egy különleges fejlesztési munka során néha sokminden nem éppen programozói munkát is el kell végezzek, a prototípus gyártástól a különféle fejlesztésekkel járó kísérletezésekig. Ilyenkor a programozóból esztergályossá vagy tekercselővé vedlek át, és örömöm lelem a változatos munkában. Úgy vélem, ezzel a különlegességgel tudom a megrendelői igényeket a legjobban kiszolgálni. Egy ilyen különleges tekercs elkészítéséről szól ez a poszt.

Feladatom, hogy készítsek egy olyan tekercset, ami néhány-tíz párhuzamos vezetőből áll, hogy a szükséges réz keresztmetszet biztosítva legyen, valamint a működési frekvencián az áramkiszorulás jelensége miatt is megfelelően működjön.

Ezért a tekercs készítéséhez szükséges huzalokat egy pászmába fogva egy tároló tekercsdobra csévéltem fel. Ügyeltem arra, hogy a feltekerés során a huzalpászmát ne csavarjam saját tengelye körül, mert ezzel a tekercsem induktivitását befolyásolnám.

Huzal előkészítés és leszabás után.

A tekercselés előtt a tekercselemet rögzítő sablont készítettem, ami tekercssablonból (2 db), távtartóból és rögzítőelemből áll. A tekercselemet a védő szigetelés elkészítéséig a szétesés ellen gyorskötözővel biztosítom. A kivezetéseket warnisch vászon szigetelővel védett bekötéssel rögzítem a csatlakozó saruig. Ez némileg eltér a közönséges tekercselésnél megszokottaktól, ahol a kivezetés anyaga nem a tekercselő huzal. A működési frekvencián ez a kötés a teljes keresztmetszeten nem készíthető el, csak a vezetékpászma végén egy sarut forrasztok, ezzel kapcsolódok a teljesítmény elektronikához.

Tekercselő szerszám szétszerelve.
Tekercselő szerszám szétszerelve.

A huzalpászmára felhúzom a tekercselemeket összekötő középső szigetelést, majd a tekercs végét szigetelő csövet. A szerszámba bekészítek két gyorskötözőt, majd a huzalpászmát kézbe veszem és a csövet befűzöm a szerszámba, majd a kivezetéshez még kihúzok belőle kb 50 mm hosszúságú pászmát.

Tekercselés kezdete.
Tekercselés kezdete.

A harmadik gyorskötözőt csak előkészítem, ennek még későbbiekben szerepe lesz. Az első menet feltekerése után az előkészített gyorskötözőt is beteszem, végét azonban nem fűzöm keresztül a szerszám oldalán.

Végrögzítő kötés elhelyezése.
Végrögzítő kötés elhelyezése.

A végrögzítő gyorskötözőt a tekercselés irányában a kezdeti kivezetés elé teszem közvetlenül, majd feltekerem a pászmából a szükséges menetszámot.

A kivezetés ideiglenes rögzítése.
A kivezetés ideiglenes rögzítése.

Mint korábban írtam a harmadik kötözővel a szükséges menetszám után a tekercs kivezetését rögzítem, hogy amikor átlépek a második tekercselembe, a feltekert vezetékpászma ne pörögjön le.

Átlépés a második tekercselembe.
Átlépés a második tekercselembe.

A tekercselő szerszámba ekkor berakom a gyorskötözőket (eddig azért nem raktam be, mert akadályozott volna a munkában, majd megkezdem a második tekercselem szükséges menetszám feltekerését. Ekkor is ügyelek arra, hogy a tekercselő szerszámot tengelye körül forgatva végezzem a tekercselést, a pászma körbecsavarása nélkül, így a pászma sodratlan lesz.

Második tekercselem elkészítése.
Második tekercselem elkészítése.

A tekercs végére felhúzom a warnisch csövet, majd a tekercselő szerszámot összeszorító csavarkötést oldom. Először a másodjára készült tekercselemet tartó oldalt bontom le, és rögzítem a gyorskötözőkkel.

Tekercsvég rögzítés.
Tekercsvég rögzítés.

Rögzítés során ügyelek arra hogy a tekercselem alakja megtartsa a szerszám alakját. A gyorskötözők záróelemét a zárás előtt a tekercs külső éléhez fordítom, hogy később lecsippenthető legyen a tekercs sérülése nélkül.

Tekercselem összekötözve.
Tekercselem összekötözve.

Ezután kiveszem a rögzítő menetes szárat és a másik szerszámot záró oldalt is eltávolítom, majd a korábban befűzött két gyorskötözőt is zárom.

A másik tekercs ideiglenes rögzítése.
A másik tekercs ideiglenes rögzítése.

Miután mindkét tekercselemet a gyorskötözőkkel ideiglenesen rögzítettem, a tekercselő szerszámokat kiveszem a tekercsek belsejéből.

Szétszdés után.
Szétszdés után.

A szerszám nyitása után 25 mm széles 0.13 mm vastag üvegselyem szövettel elvégzem a tekercsek bandázsolását.

Bandázsolás közben.
Bandázsolás közben.

Mindkét tekercselemre 1500mm hosszú üvegselyem szalagot tekerek. Ahogy haladok a körbetekeréssel, a gyorskötözőket lecsippentem, vigyázva a tekercs sértetlenségére. A szalagot folyamatos feszítéssel húzom, és megszorítom a tekercs vezetőinek rögzítéséhez. A kivezetéseknél elvégzem a szalag kötését.

Elkészült a bandázs.
Elkészült a bandázs.

Amint mindkét tekercselem bandázsolását elvégeztem a ferrit fazékmagra illeszkedő csévetestet a tekercsbe teszem.

Csévetest behelyezése.
Csévetest behelyezése.

A csévetestekre szerelt tekercseket a későbbiek során Vilepox lakkak telítem, majd szárító kemencében fogom kiszárítani. Ezt a műveletet csak a tekercsvégekre szerelt saruk elkészítése után végzem el, mert a lakktól törékennyé válnak a kivezetések. Először azonban a prototípus ház elkészítését kell bevárni és méretre szabni a tekercs kivezetéseket.

Kész tekercs ferrit maggal.
Kész tekercs ferrit maggal.

Ez azonban már egy másik poszt lesz. Mert az igazi programozó mestert az sem riasztja vissza, ha egy teljesen ismeretlen mikrokontrollerre kell programot írni.

Ha tetszett, komment és észrevétel jöhet, rövidesen folytatódik a történet és kiderül mi is lesz ebből a csoda tekercsből!

Kategóriák
Munkával kapcsolatos észrevételek, kérések, kérdések, egyelőre egy halomba, minden ami idefér

Siemens szervo motor ellenőrző mérése

Úgy hozta az élet, hogy munkám során egy CNC megmunkáló központ egyik tengelyének hajtását kellett ellenőriznem. A tengely végén egy 1FT5066-0af01-2-z típusjelölésű motor volt. Némi utánajárással megállapítottam, hogy ez a motor egy háromfázisú BLDC motor, a tengelyén egy szintén háromfázisú tachogenerátorral, ami az analóg szabályozott hajtás felé ad a fordulatszámmal arányos feszültségjelet, valamint egy rotor pozíció ecodert is tartalmaz. A tengely végén egy ROD426 típusú encoder ad jelet a CNC gép számítógépe számára.

Először megkerestem az interneten a motorhoz tartozó gyári szerviz manuált, ebben hamar megtaláltam a beállítás lépéseit és mérési eljárását. A géphez tartozó dokumentációban a motor csatlakoztató kábel bekötését is sikerült előtaláljam, mert a szerviz manuálban ennek a kábelnek a bekötésére is hivatkoznak.

A motor kapocstáblájának belső oldalán a motorról némi információt sikerült megtudjak:

Látható a bal felső részén jobbról bal felé a tengely fék, majd a hajtó főmotor, a tachhométer generátor és a rotor pzíció encoder “LG” jellel.

A csatlakozó kábelről rendelkezésre állt rajz:

A szerviz manuálban a mérésekről a következő leírást olvastam:

A motor tengelynek, a tachogenerátor forgórésznek és a rotor encodernek egymáshoz viszonyított szöghelyzetét nagyon pontosan minden szétszedés vagy javítás után be kell állítani illetve ellenőrizni. A mérendő jelek a a főmotor tekercseiben indukált feszültség, a tachogenerátor kapcsain megjelenő indukált feszültség és a rotor pozíció encoder kapcsain mérhető jel. A mérés idejére a motor tengelyét a hajtás felőli oldalról nézve az óramutató járásával megegyező irányba kell forgatni, majd a kívánt jeleket oszcilloszkóppal mérni és ellenőrizni. Először a főmotor indukált feszültsége és a rotor pozíció encoder egymáshoz viszonyított helyzetének ellenőrzésére szolgáló mérési eljárás:

Persze az élet soha nem olyan egyszerű, mint a dokumentáció. A mérés elvégzését lehetetlenné tette, hogy a rotor pozíció encoder jele bizony nem jött ki a megfelelő kivezetésen, sőt semmilyen más ponton sem. Összehasonlító mérést végeztem egy másik tengellyel is, és legnagyobb megdöbbenésemre a biztosan jól működő motorból sem jött rotor pozíció encoder jel! Nem volt mit tenni, a szabályozott hajtás oldaláról vizsgáltam tovább az encoder jelének problémáját, majd rájöttem, hogy az encoder jele csak akkor jelenik meg, ha azt tápenergiával látom el. A csatlakozó hajtásban a csatlakozó 6. lábához 12V tápfeszültség kapcsolódik egy soros 100 Ohm ellenálláson keresztül, aminek nyilvánvalóan az volt a célja, hogy bármilyen külső zárlat okán kialakuló áram semmiben se tegyen kárt.

Ennek az információnak a birtokában a 10. kivezetést a mérőföldre, a 6.kivezetést egy soros áramkorlátozó ellenállást bekötve +12V tápfeszültségre kapcsoltam. A kimeneteken azonban csak időnként megszűnő zajt mértem. Ekkor vált nyilvánvalóvá számomra, hogy a kimenet nyilvánvalóan open-collector típusú, így a mért kimenetre egy 10 kOhm felhúzó ellenállást kötöttem. Sajnos ez is kimaradt a dokumentációból, de ezután már el tudtam végezni a mérést.

A motor tengelyére spárgát tekertem, majd azt kézzel meghúztam. A motor kivezetésein (2. sugár) és a rotor pozíció encoder kimenetén (1. sugár) mért jelet az oszcilloszkóppal rögzítettem. Trigger az encoder jel lefutó éle volt.

Amint láttam hogy sikerült érdemi jelet rögzítenem nagyon megörültem, belenagyítottam és kiértékeltem a mérést az előirat szerint:

A kurzorokat az encoder jel éleire állítottam és ellenőríztem a forgórész indukált feszültségének nullátmenetével (2. tengely) Mivel precíz egyezét láttam a beállítás jónak bizonyult.

Az előírás szerint mind a hat esetet végigmértem, vagyis az encoder jelhez képest a főmotor tekercseinek indukált feszültségét (3 mérés) és a tachogenerátor tekercseinek indukált feszültségét (3 mérés) egymáshoz képesti fázishelyzetét ellenőriztem az előírás szerint.

Remélem másnak, aki hasonló témában keres az interneten releváns információt tudtam adni. Sajnos a dokumnetáció és a valóság eléggé messze voltak egymástól, de kis ügyességgel meg lehetett oldani a problémát!

Kategóriák
Munkával kapcsolatos észrevételek, kérések, kérdések, egyelőre egy halomba, minden ami idefér

ATMEGA 644A – RS485 buszos adatgyűjtő áramkör

A következő posztban szeretnék bemutatni egy olyan témát, ami a műszaki praxis során sokszor előfordul, azonban számtalan apró buktatója van és általában az eredménytermék nem tudja azt, amit az alkotók és a megrendelők elvárnak tőle.

Az én gyakorlatomba is pont ilyen okból került be ez a feladat: Adott volt egy meglévő adatgyűjtő rendszer, ami maximum 30 eszközből néhány bitnyi információt gyűjtött, és képes volt néhány bitnyi adatot – működtető kimenetekként – eljuttatni az adatgyűjtés helyére.

A példaként beszállított alkalmazás több hibával, döcögősen üzemelt és a vizsgálatom után megszületett az újratervezést támogató döntés.

A tervezés során fél duplex kommunikációs protokoll mellett döntöttem, az igények kiszolgálására ez is elégségesnek bizonyult. Döntésem hátterében a duplex kommunikáció ellen a kétszeres hardver igény – és így kétszeres meghibásodási lehetőség – szólt.

A kommunikáció megvalósítására az áramhurkos RS485-ös összeköttetést tartottam a legalkalmasabbnak, mert alkalmas sodrott érpáros vezetéken akár 5MB/s átvitelt 100m+ távolságra is biztosítja.

Ennek tipikus topológiáját a következő ábra mutatja:

SN75176 tipikus alkalmazása
RS485 busz struktúra 32 kapcsolódó eszközhöz.

Az így összekapcsolt mikrokontrollerek (SLAVE-eszközök) egy buszon kapcsolódnak az adatgyűjtő számítógéppel soros porton kapcsolódó busz illesztést és vezérlést végző MASTER eszközhöz.

Ez gyárthatósági és praktikussági okokból azonos hardvert jelent különböző betöltött programokkal.

Az RS485 busz gyártói ajánlat szerinti PCB kialakítására egy példát találunk a gyártó adatlapjában, ami nem sok segítséget, éppen csak iránymutatást ad.

SN75176 tipikus PCB ajánlás

A lényeg azonban így is látható : rövid, vastag vezetékekkel kell az áramkört a busz vezetékhez kötni. A műszaki gyakorlatban sodrott érpáros kábeleket legolcsóbban CAT5E+minősítésű nyolceres “internet” kábelként lehet beszerezni. Ilyen kábeleket praktikusan RJ-45 csatlakozóval mutatkozott célszerűnek szerelni.

Az áramkör tervezésnek szinte egyik kulcsmozzanatához értünk: Az érsorrend kiválasztásnál úgy kell eljárjunk, hogy a kapható kábelek esetén az “A” és “B” vezetékek egy pászmába kerüljenek.

Bus kapcsolat RJ-45 csatlakozón keresztül

(a gyakorlat azt mutatja, ez nem mindíg és nem mindenkinek sikerül)

Jelen példánkban a 4 -5 vezetékek és 3 – 6 vezetékek egy pászmába esnek. A szokásos színjelölés mellett zöld – zöld/fehér és kék – kék/fehér erek. A párhuzamosítást redundancia miatt végzem. A próbagyártás és tesztelés során az összeköttetés minőségi paramétereit lényegesen javította az ilyen párhuzamosság.

Adatgyűjtő készülék PCB SMD beültetés előtt.
ATMEGA644A mikrokontrollerrel készült RS485 buszos adatgyűjtő készülék

A kép jobb oldalán látható a busz csatlakozó foglalata. Ide jó minőségű árnyékolt kivitelű aljzat kerül beültetésre, az áramköri lemezhez forrasztott árnyékolással. A vezetékek topológiáját úgy alakítottam ki, hogy az alkatrész oldalon a csatlakozót árnyékoló fém ne okozzon zárlatot a használat (mozgatás, során a fém ház súrlódhat az alatta lévő fóliával) során.

A két csatlakozó közt található a buszmeghajtó illesztő áramkör, csatlakozása rövid, vastag vezetékkel biztosított.

Félgyártmány forrasztási oldal
ATMEGA644A mikrokontrollerrel készült RS485 buszos adatgyűjtő készülék

Az illesztő áramkör két darab RJ-45 típusú csatlakozóval kapcsolódik a buszhoz: így a kábelek könnyen előre gyárthatóak csatlakoztatásuk gyors telepítést tesz lehetővé.

Az áramkör tervezésénél másik nagyon fontos probléma volt a cél rendszerek digitális földjeinek különböző potenciálja. Ezek elválasztását opto-csatolók biztosítják. A tápenergia ellátás egy közös vezetéken keresztül történik, egy kis kapcsolóüzemű tápegység használatával: így elérhető hogy a tápfeszültség esés a teljes vezetékhosszon alacsony legyen, és az energiaszállítás jó hatásfokon történjen.

Ez különösen fontos, amikor 32 áramkör (teljes kiépítés) kerül telepítésre. A tápfeszültség ilyenkor 20..32 V teljes áramfelvétel 200mA. Így a tápenergia kábelezésre tökéletesen megfelelt a közönséges flexibilis hangszóróvezeték erenként 0.5 négyzetmilliméter keresztmetszettel.

A megépített és néhány száz példányban már telepített készülék 20 MHz órafrekvencián stabil üzemet biztosít 250kbit/sec átviteli sebességen.

Sokakban felmerülhet a busz lezáratlanság kérdése. A busz lezárását praktikusan az utolsó áramkör üresen maradó RJ-45 csatlakozójába egy aljzatba krimpelt ellenállással lehet elvégezni. A tapasztalat azt mutatja, hogy ez szükségtelen.

A bus MASTER készülék paneljén a kommunikációs vonal potenciálját fél tápfeszültség közelébe az R29 és R28 ellenállásokkal lehet elvégezni. A tapasztalat azt mutatja, hogy kompatibilitási okokból ez szükségtelen sőt elkerülendő!

Kategóriák
Munkával kapcsolatos észrevételek, kérések, kérdések, egyelőre egy halomba, minden ami idefér

A Z80 processzor diszkrét bája

Őskövület a feledés szemétdombjáról – mondhatnánk azonban több szempontból is rendkívüli figyelmet érdemlő mikroprocesszort, valamint a benne rejlő lehetőségek alkalmazását és ennek programvédelmi megfontolásait szeretném ebben a posztban bemutatni.

Ki ne szeretett volna már olyan hardveres programvédelmet készíteni, ami egyrészről hatósági eljárás céljából a programot rögzíti kiolvasható módon (eprom) ugyanakkor a konkurencia reverse-enginering próbálkozásai ellen megvédi azt?!

Erre kínál egy kiváló lehetőséget ez a processzor, és ennek használati technikáját szeretném röviden bemutatni itt. Ahhoz, hogy megértsük miként működik ez a védelmi megoldás, tekintsük át a processzor és a perifériák közti kommunikációt memória írás és olvasás tekintetében.

Processzor - busz kapcsolat
A processzor memória kapcsolat időbeni felosztása.

Az ábrán látható a Z80 processzor memória hozzáférés időzítése. Vegyük észre, hogy a processzor megkülönbözteti az utasítás lehívási ciklust a többi memória hozzáféréstől, ami lehetőséget biztosít az adat és programkód memória elválasztására. Ezzel a lehetőséggel azonban védelmi szempontból is tudunk élni, mégpedig pont úgy, hogy az adat és kód hozzáféréseket egy memóriában tároljuk lehetőleg jó alaposan összekeverve. Az utasítások és adatok alkalmasan összekevert mintája a program egyedi “ujjlenyomata” is lehet, és mivel a tárgykód változás esetén relokálódik, mert a fordításkor az utasítások számára foglalt hely változik, nagyon egyedi is lehet. Alkalmas fordítóprogrammal és makrók használatával a kódba ékelt adatok mennyisége a kód méretének néhány százalékos mértékét meghaladó méretben a visszafejtést nagyon megnehezíti.

Utasítás beolvasási ciklus
A processzor utasítás beolvasási ciklusa (M1)

A fenti ábrán a processzor utasítás lehívási ciklusa van ábrázolva, és pirossal kiemelve amikor a buszról utasítás byte-ot olvas a processzor. Ha egy utasítás több byte-ból áll, akkor a T1-T4 ciklusok ismétlődnek addig , míg a teljes utasítás beolvasásra nem kerül.

Amikor a processzor az utasítást végrehajtva memória műveletet végez – olvasási vagy írási esetleg R-M-W ciklust, akkor az alábbi diagram szerint történik a memória hozzáférés:

Processzor memória olvasási és írási ciklusa
A processzor – memória kapcsolat időbeni megvalósulása.

Ugyan a diagramon az M1 vonal nincs ábrázolva, de ezen ciklusok alatt logikai “H” szinten áll, azaz inaktív.

A programunk védelmére ez biztosítja a gyakorlatilag csak nagyon nehezen megfejthető megoldást.

Tekintsük az alábbi kódszakaszt és annak memóriába fordított gépi kódját!

példa a kódba ágyazott adathozzáférésre
kódba ágyazott adat

Vegyük észre, hogy a befordított tárgykódban a szubrutin hívó utasítás utáni két byte-ot a szubrutin ADATKÉNT olvassa fel a memóriából, a környező utasítás byte-okat viszont KÓDKÉNT! A különbséget a hardveres működés során a fentiekben ismertetett M1 vonal aktivitása jelzi.

A példában a veremtárban a stackpointer mögött egy lokális változót hozok létre, hivatkozás az (IX -2) mutatóval történik azt kinullázom, majd ötig elszámolok vele a példa kedvéért. A rutin végrehajtása után felszabadítom a veremtárban foglalt helyet. A foglalt hely mérete 2 byte, ennek komplemensét adom az SP regiszter aktuális értékéhez, ami tulajdonképpen a kivonást jelenti.

A programvédelem hardver alapja, hogy az adatbusz tartalmát a címbusztól függően összekeverem, ha kellően bonyolult a függvény, akkor ez már jól védi a memória tartalmát visszafejtés ellen, de azért néhány kreatív ötlettel visszafejthető. (lásd xx posztot, ezt még nem írtam meg, de tervben van) A hab a tortán csak ezután jön! A kódoló függvénybe vegyük bele az M1 vonal értékét például egy XOR kapun keresztül!

Amennyiben saját fordítóprogramunk van (én ezt használok) és azt úgy írtuk meg, hogy a program által generált objektum kód tartalmazza, hogy mely byte-ok utasítások és melyek adatok, akkor a tárgykód készítésekor (eprom tartalom előállítása) ezeket különféleképpen kódolva jutunk el a csaknem visszafejthetetlen kódig. A példában a kódoláson felül az adatként értelmezett byte-okat negálni kell.

Ezt azzal lehet elérni, hogy a példában bemutatott módon kreatív makrók alkalmazásával például egy érték paraméter szerinti rutin felhívást (c# switch – case struktúra) valósítunk meg:

switch-case példa

A példában a .db és .dw utasításokkal definiált byte-ok adatként kerülnek tárolásra, (még a cimkék is!) míg a többi kódként.

Ez a visszafejtésnél azért okoz nehézséget, mert a kódot soronként kell elemezni, hogy egy szubrutinhívás után adat vagy programkód következik, esetleg indirekt szubrutinhívással még jobban nehézzé tehető a helyzet. Ekkor annak, aki a kódot meg akarja fejteni a visszafordítás során el kell dönteni egy eprom adatról, hogy az adatként vagy kódként kerül feldolgozásra, mert ettől függ a processzor – memória közé beékelt kódoló logika működése. További nehézséget jelent a bemutatott példában az adatstruktúra értelmezése, ugyanis byte-os konstansok, word-os konstansok, és word hosszúságú szimbólumok értéke is kerülnek egymás után tárolásra. Ennek a struktúrának az értelmezése a felhívott szubrutin dolga, amit itt terjedelmi okok miatt nem mutatok be, de a működése könnyen érthető: az első .w konstans megmutatja hány ága van a switch szerkezetnek, utána byte-os konstansokkal felsorolásra kerülnek a különböző esetek, majd az illető esetekre és az ELSE ág lefordított tárgykódjára mutató szimbolikus címek értékei következnek.

Ez a processzor számára “in-situ” körülmények közt természetesen megy, az eredmény az M1 vonalon, de ez a kódolt eprom vizsgálatakor byte-onként nem áll rendelkezésre a kíváncsi tekintetek számára! 🙂

Nos, dióhéjban ennyit szeretnék elmondani erről, nem veséztem ki teljes mértékig a témát, különös tekintettel az interrupt ciklusok és az M1 vonal működésének összefüggésére, de úgy vélem bemutattam egy technikailag szofisztikált programvédelmi megoldást, ami megalapozza ennek a processzornak a XXI. században történő használatát.

Kategóriák
Egyebek, gépház, házirend stb. Maga az iparos. Történetek a múltból és a jelenből. Munkával kapcsolatos észrevételek, kérések, kérdések, egyelőre egy halomba, minden ami idefér Utazás, szabadidő és mindenféle érdekes dolog. Véleményem a világ dolgairól

Helló Világ!

Annak írok, aki itt jár. Ha tetszik ha nem, ennek a honlapnak a gazdája én vagyok. Nekem kell felelősséget viselni a törvények szerint.


Szabályok:
Az egészséges, építő, jobbító kritikát szívesen fogadom.


A kérdésekre, kérésekre, szívesen válaszolok, de ez a saját munkám terhére nem mehet.


Aki türelmetlen vagy zaklat, kitiltom.


Aki tiszteletlen azt kitiltom.

A számomra elfogadhatatlan, üzleti és/vagy magánérdekeimet sértő hozzászólásokat törlöm.

Ha valaki linkel engem, viszonossági alapon én is linkelem őt. Ez természetes, kedvenceimet a kedvencek menüben találhatják.


Ennyi.