Üdv!

PID ?

Imi.

Szia Imi,
Első gondolatom nekem is ez volt, de +- irányba is kéne szabályozni a fordulatszámot.
Pontosan a PID 3 step-re gondoltam, de az csak digitálisan „kapcsolgat” előre hátra (nem biztos, annyira nem ismerem).
Lehet, hogy meg lehet oldani pid-del is, erre kéne ötlet. (2 pid használata?)
Utána volt olyan ötletem is, hogy ha eltérés van a résméretében, akkor időnként pl. 0,5-1-2 másodpercenként (ez lehetne állítható panelról) növelném vagy csökkenteném a fordulatszámot 1-2 Hz-ként pl. +- 10Hz –es tartományban.
üdv.

Üdv!

Van ugye egy alapjeled, hogy mekkora legyen a rés szélessége. Ez valahonnan jön: vagy felhasználó által beállított, vagy valamitől függő. Tehát értéktartó, vagy valamit követő formában van jelen.

Aztán van a mért értéked, hogy konkrétan mennyi a rés szélessége. A PID-re ráadod az alapjelet, és a mért értéket, és a PID kimenete változni tud +/- irányba, és ez már tudja változtatni a motor fordulatszámát +/- irányba.

Tegyük fel, hogy a rés kívánt szélessége X, a PID 0-ról elkezdett növekedni, és mondjuk 45% PID kimenet (tegyük fel, hogy a PID kimenete 0-100% tartományban mozog) olyan fordulatszámot eredményezett, amely épp tudja tartani X-et. Ha ezután X-t megnöveled, akkot a PID utánamegy, és megnövekszik a fordulatszám is, ha X-t csökkented, akkor is a PID is csökken, és a fordulatszám is csökken. Tehát a PID mindkét irányba tudja a fordulatszámot változtatni.

Szerintem felesleges trükközni, a PID megfelel erre a célra, persze be kell hangolni, és figyelni kell néhány dologra, pl. hogy van e mondjuk egy minimális fordulatszám, vagy maximális fordulatszám, ami alá/fölé nem mehet.

Imi.

halo !

a PID 3s nem csak digitális, elég sok mindent tud, tudja az analogot is, illetve ennek megfelelően a százalékos szabáylzást is.
a PID 3S és a compakt PID ugyanazt teszi, csak a Compact ki van bontva.

by-te

Biztos, hogy a Tia Portal-os PID tud +-100%-ban adni kimenetet? Ja és S7-1200 –ra gondoltam a megvalósítást illetően.
Valószínűleg úgy lesz, hogy 0% kimenethez tartozik a minimum fordulat 100%-hoz a max és majd a különböző anyagoknál ezek az, értékek változtathatók lesznek. Vagy mivel valószínűleg csinálok egy olyan opciót, hogy a szabályozást ki lehet kapcsolni és az így meghatározott fordulathoz kalkulálom a min és max fordulatszámokat, ha a szabályozás bekapcsolják.
üdv.

halo !

azt tudja amit minden PID.
az s7-1200-as sorozat is tudja a PID 3s és a PID compaktot is.

mivel Te határozod meg a minimum és maximum szintet a 0-100% -nak megfelelően , az analog kimenet működhet.

by-te

sziasztok!

Itthon, "játékból" írogatok programkódokat és szeretnék valami "látványos" szimulációt készíteni, WinCC Flexible-lel!

Amit kitaláltam, ami az alap, hogy egy 6 állomásos körasztal lesz animálva, zöld, piros (OK, NG) termékekkel.
Ezzel nem is volna gond, egy merker el tudja dönteni
De hogy kellene megcsinálni, hogy az üres jig, mondjuk szürke legyen? mert ez ugye már 3 állapot és két merker bit kell hozzá.

WinCC-ben ez hogy nézne ki? Egymás fölé kellene tenni más layerben a kettőt?

Amit akarok csinálni, mondjuk megy a körasztal, lenne kijáratás, kézi üzemmód (egy állomáson), meg ami szerintem jó ötlet a "véletlenszám" generátoromat tudnám használni,selejtgenerálásra, stb stb.

Egyrészt mert érdekel a dolog, másrészt szeretnék már valami bemutatható dolgot is elvinni állásinterjúra.

üdv
Pifu

Szevasz Pifu!

Csinálhatod úgy is, hogy lerajzolod háromszor és mindegyiknek a láthatóságát kapcsolgatod egy bittel de az nem túl szép megoldás.
Ha sok ilyen van egy screenen az körülményessé teheti a szerkesztését. Állandóan kotorászni kell az egymásra helyezett, a szerkesztőben egymást kitakaró objektumok között. vagy ha mindegyiket külön layer-re teszed az könnyíthet a helyzeten, de akkor meg a layereket kell kapcsolgatni ha módosítani kell rajtuk.

Amennyiben a szimbólumod grafikus primitívekkel rajzoltad (kör, vonal, négyzet, stb) akkor én az animation / appearance segítségével oldanám meg a dolgot.
Csináltam erre egy példa projectet. Két lehetőséged van:

Egy integer változó (a példában ez MW10) van hozzárendelve egy szürke hátterű és fekete keretű téglalap animation / appearance tulajdonságánál. Az integer egyes értékeihez eltérő háttérszíneket rendeltem hozzá.

Amikor az MW10 tartalma 1, akkor a téglalap színe piros lesz, ha 2 akkor narancssárga, ha 3 akkor citromsárga, ha négy akkor zöld. Minden más érték esetén a téglalap eredeti, tehát szürke színű lesz.
Itt tehát az MW10 integerbe kell a PLC programban különböző értékeket írkálni a szín megváltoztatásához.

A másik lehetőség a bitenkénti színváltás (binary appearance).
Egy byte változó van létrehozva ami az MB12 merker byte-ra hivatkozik. Az animation / appearance itt binary-re van állítva ahogy a képen is látható. Ilyenkor a színek nem a változó értékéhez, hanem annak bitjeihez rendelődnek hozzá a következőképpen:
Ha az M12.1 TRUE, akkor a téglalap piros lesz, Ha M12.2 TRUE, akkor narancssárga, ha M12.3 akkor citromsárga, ha M12.4, akkor zöld.
Ennél a megoldásnál arra kell figyelni, hogy ha a megadott bitek közül nem csak egy TRUE, hanem több is, vagy a byte olyan bitje TRUE, ami nincs felsorolva, akkor a téglalap eredeti (azaz szürke) színű marad!

Amennyiben a megjelenített szimbólumod előre megrajzolt grafika, akkor is megoldható a dolog, de teljesen máshogy. Ennek a leírásától most eltekintenék, mert túl hosszú lenne ez az üzenet...

[ Szerkesztve ]

szia!

Ez a válasz minden igényt kielégít!

Köszönöm

Sziasztok!
Siemens S7-ben lenne egy kérésem a lokásis változókkal kapcsolatban.

A képen lévő program mindösszesen annyiból áll, hogy ha az FC1 NW3-ban, az M56.0-t 1-be billentem, akkor a "temp_0" lokális változó is 1 lesz.
A problémám az, hogy én úgy tudtam, hogy a lokális változók az FC hívás végén tölődnek. Viszont nekem látható, hogy az FC1 NW1-ben még írás előtt 1-ben maradt a "temp_0", sőt az FC2-ben is 1-be billen a"temp" változó amint az M56.0-t aktiválom.

Most csak én értem félre a lokálsi változók működését, vagy ez tényleg nem rendeltetés szerű működés?
Köszönöm a válaszokat előre is.

Üdv, mcwizard!

Üdv mcwizard!

A lokális változók a hívás végén nem törlődnek. A rendszer nem törli őket szándékosan. Ám a tartalmukat nem szabad figyelembe venni a blokkon belül azelőtt, hogy értéket adtunk volna neki.

Az ok rendkívül egyszerű: A lokális változók tartalmát más blokkok lokális változói felülírhatják ha használnak lokális változót illetve ha írják azokat. Így minden blokkban minden lokális változó tartalma lényegében határozatlan, memória szemét van benne. Egyszerűen azért, mert minden blokk ugyanazt a stack-et (memória területet) használja a saját lokális változói tárolására.

Ezért ha csak egyetlen egy blokkod van ami ír egy lokális változót, de a többi blokkban is létrehozol változókat amik így ugyanarra a címre kerülnek, ám azokat nem írod csak olvasod, akkor azt fogod tapasztalni hogy amikor az író blokk megváltoztatja a lokális változó értékét, akkor az a többi blokkban is megváltozik. Illetve az író blokk elején is az az érték van benne amit utoljára beleír.

Ha azonban nem "steril", hanem olyan programban vizsgálnád meg ugyanezt a jelenséget ahol különböző blokkok különböző célra intenzíven használnak különböző belső változókat a saját céljukra (a gyakorlatban minden program ilyen lényegében) akkor gyökeresen mást tapasztalnál.

Ha tehát arra hagyatkozol amit most tapasztaltál, annak vége igen nagy szívás lehet. Ezért nagyon fontos szabály, hogy egy blokkban lokális változót SOHA nem használunk fel azelőtt a blokk lefutásán belül, hogy annak értéket adtunk volna!

Be lehet vele rendesen sz..ni.
Üdv.

“Az a baj a világgal, hogy a buták mindenben holtbiztosak, az okosak meg tele vannak kételyekkel.“

Szóval névtől függetlenül, ha valahol 1-re írom a 0.0-ás című lokális változót, akkor az addig 1 marad míg valahol máshol nem adok neki más értéket.
Nos ha erre nem figyelek jobban akkor meggyűlhet vele a bajom
Köszönöm a segítségedet!

[ Szerkesztve ]

Üdv mcwizard!

Meggyűlhet.
Meglehetősen misztikus hibajelenségeket produkálhat az ilyen hiba. Pl. ha az a bit egy másik blokkban (ami így, hibásan kezeli a temp változóterületet) éppen egy előírt érték dint-jének a közepére esik.
Nem mindegy ám, hogy egy szervóhajtást 23430-ra vagy a 4217734 pozícióra küldi a program.
Vagy hogy a kemencét 699 fokra fűti vagy tol neki néha egy 2747-et....

Üdv!

Erről a témáról eszembe jut még egy eset, amit szintén kegyetlenül meg lehet szívni ha nem figyelünk oda. De ennél ellentétes a helyzet, vagyis nem az van hogy azt gondoljuk jól működik és nem értjük miért nem, hanem látszólag hülyeséget csinál, mégis jól működik...
Ha lesz kedvem leírom a weblapomon egy írásban.

Az a poén, hogy használsz pl. egy Int-et és nem adsz neki értéket aztán csak azt veszed észre, hogy van benne 28534. Aztán elkezded keresni, hogy hogyan került ez a szám bele, de azt meg nem találod.
Felfutó élnek sem lehet használni a lokális változót!
Üdv.

“Az a baj a világgal, hogy a buták mindenben holtbiztosak, az okosak meg tele vannak kételyekkel.“

Sziasztok. A problémám pont a lokális változók témába vág, ezért írom ennek a folytatásába.
Egy kis előtörténet: eddig nem sok szerencsém volt Siemens-hez, de mivel a következő munkát ezzel kell megoldani, beszereztem Step7 Lite + PLCSim, meg az ST-Pro1 anyagát. Neki is fogtam a tanulgatásnak, heti/napi 1-2 órát (amennyi időt tudok szánni rá). Az FC-ket lokális változókkal deklaráltam, az OB1-ben meghíváskor rendeltem hozzá fizikai címeket. Minden működött is szépen, addig még nem írtam még egy FC-ét. Ezután állandóan elejtette az egyik blokban az SR flip-flop értékét. Néztem keresztbe is, meg hosszába, minden OK volt, semmi nem aktiválja az R ágat, de mégis... Pár nap olvasgatás után (fórum, Szirty oldala, stb), megtaláltam a hiba okát. A két FC ugyanazt a temp 0.0 cimet használja, és a második FC törli az értéket. Hogy lehet kivédeni az ilyen hibákat?

A lokális változók címét nem tudom megváltoztatni, automatikusan rendeli a program a változókhoz.

És megválaszolva a saját kérdésemet: ha meg kell őriznem az FC/FB egy belső állapotát, ki kell mentenem egy merkerbe (átdefiniálom temp-ről in_out-ra) vagy DB-be, még ha máshol nem is fogom használni.
Hozzá kell szokni ehhez a Siemens logikához.

Sok szabadságot ad ez a strukturált felépítés (FC,FB,DB) a direkt cimzéses rendszerekhez képest, de ennek a szabadságnak megvannak a saját veszélyei (legalább is kezdetben)

Üdv KLR!

Épp pár üzenettel ezelőtt írtam le kiemelve, hogy egy lokális változó értékét egy blokkban SOHA nem szabad azelőtt felhasználni hogy értéket adnánk neki a blokk lefutása előtt! :-)

Igen ha meg kell tartani a tartalmát, akkor lehet úgy is ahogy írod: in/out és kívülről mondod meg neki hova tegye valójában.
Ám ha egy blokkod sok olyan "lokális" változóval dolgozik, amik tartalmát meg kell tartani minden lefutáskor, akkor ott az FB, aminek épp ez a lényege. Olyankor nem TEMP, hanem STAT változót kell használni.

Itt találsz erről egy kis infót: Az S7 PLC programozása (2. rész)

Kössz a linket. A probléma a 4111 hozzászólásod előtt jelent meg nálam, de ez segített a hiba feltárásában. Előtte nem is gondolkodtam az L memóriaterület felhasználásának módján. Biztos le van írva, meg láttam is, de mivel csak alkalomadtán tudok olvasgatni / tanulgatni, elsiklottam felette. De hát a saját hibáján tanul az ember. Még jó hogy vannak segítőkész emberek, akik irányt mutatnak.
Most már világosabbá vált számomra az FC-ék és FB-ék közötti különbségek és felhasználási lehetőségek.

Üdv,

szia!

Én a mai napig nem futottam bele hasonló hibába, eddig csak különálló egymástól gyakorlatilag független blokkokat írogattam.

Eddig azt hittem, elég ha a blokkban adok értéket mondjuk M1.0 -nak és azt a következő blokkban lekérdezem és minden menni fog szépen...

De legalább ma is tanultam valami!

Szia!

Most gondolkodtam, ha az egyik FC-ben írok egy merker bitet, amit egy másikban csak olvasok azt is in-out-ba kell tenni?

És a másik kérdés, attól félek hogy nem sikerült maradéktalanul megérteni a program lefutásának a ciklikusságát.
Amit látsz azzal szeretném előállítani trigger jelet, ami lépteti a körasztalt a szimuláláshoz (itt csak a bytokat pakolom, ami a termékek színét jelenti a sorszámának megfelelő jigben.).

A T1-nek egyetlen ciklus erejéig 1 értékűnek kellene lennie és a pozitív élfigyeléssel indítani az adatok léptetését a 3-as Network-ben.
De ehelyett nem történik semmi. Valamit nagyon félreértettem? Vagy ez a PLCSim-nek egy elvi határa lenne?

[ Szerkesztve ]

Helló Pifu!

"Eddig azt hittem, elég ha a blokkban adok értéket mondjuk M1.0 -nak és azt a következő blokkban lekérdezem és minden menni fog szépen..."

Ezt teljesen jól hitted, ez így is van. Ezen a hiteden miattunk ne változtass!
Amit írtunk, az lokális változókra vonatozik (blokk interface részében a TEMP változók, alias L terület)
Az M1.0 vagyis a merker terület nem lokális, hanem globális. Azokra teljesen más szabályok vonatkoznak.

Hi!

"Most gondolkodtam, ha az egyik FC-ben írok egy merker bitet, amit egy másikban csak olvasok azt is in-out-ba kell tenni?"

Ha a paramétert a blokk csak írja, akkor OUT legyen. Ha csak olvassa, akkor IN legyen. Ha írja is és olvassa is (tehát fel is használja az állapotát) akkor INOUT legyen.
Hogy ez merker vagy nem merker az részlet kérdés, mivel a blokk belül nem "tudja" (és nem is érdekli) hogy te kívül a hívásnál az adott paraméterének milyen változóterületet adtál meg.

"A T1-nek egyetlen ciklus erejéig 1 értékűnek kellene lennie"

Az ilyen megoldást a timerrel kerülni kell (most már teis tudod) :-)
Így csináld:

A -(P)- re nincs szükség mert a timer alapból is csak egy ciklus ideig lesz TRUE (legalábbis ebben a megoldásban már igen) :-)

szia!

Köszönöm a timer-re vonatkozó tanácsot, már látom a lényegét.

De még kérdezek, mert nem világos minden.
Az hogy a merker adatterület globális az világos, de akkor minden esetben mikor két különböző blockban akarom ugyanazt a merkert használni ,definiálnom kell az In, Out, In-out részben?

Csak mert én azt hittem mivel globális ezért ezzel nem kell foglalkozni.

Helló Pifu!

A kérdésed nagyon jó! :-)
Nem kell feltétlenül dekrlarálnod, bármelyik FB OB, vagy FC blokkban felhasználhatod bármelyik merkerbitet, byte-ot szót, vagy duplaszót.

Az, hogy a programblokkok (FC és FB) paraméterezhetőek egyetlen komoly oka van: az univerzális felhasználhatóság.
Ezt nem feltétlenül kell kihasználni, ez csak egy lehetőség.
Egy berendezésre úgy is lehet programot írni, hogy semmilyen paraméter átadás nem történik.

A paraméterezhetőség lényege az, hogy univerzálisan felhasználható blokkot készíthetünk vele. Pl. egy csillag-delta indítást, egy analóg hőmérséklet mérést, vagy bármit.
Ilyen esetben a blokkon belül arra kell törekedni, hogy ne legyen benne közvetlen címzés, a blokk minden információt az IN és INOUT paramétereken keresztül kapjon meg és az OUT és INOUT paramétereken keresztül adjon át a "külvilág" felé.

Ha egyedi, nem univerzálisan (máshol is) felhasználható blokk készítése a cél, akkor a blokkon belül címezhető közvetlenül bármilyen merker vagy adatblokk. Ilyenkor rendszerint semmilyen blokk paramétert nem használunk (nincs IN, Out és INOUT sem).

szia!

Köszönöm a részletes választ, idővel majd ha olyan munkám lesz én is csinálok magamnak univerzálisan használható blokkokat.

De az egész abból indult ki, hogy az itthoni programocskámban nem ment át az egyik FC-ből a másikba a merkerbit állapota és nem találtam rá rendes indokot, deklarálás után működött rendesen.

Lehetséges, hogy a PLCSim hibázik néha? Vagy mindenképpen códban kell keresni a hibát?

Helló Pifu!

Ilyen indokot én sem tudok (szerintem nincs is).
Ha egy merker bitet (Mxxx.y) bekapcsolsz bármelyik blokkban, az minden más blokkban bekapcsolt állapotú lesz mindenféle deklarációs trükk nélkül is. Legyen az OB, FC, vagy FB.
Természetesen csak akkor, ha más blokk nem írja azt a bitet.

Ne a PLCSIM-ben keresd a hibát, az nagyon jól működik. Bár lehet benne hiba (én találtam is olyat, amikor az SFB4 IEC timer hibásan működik bizonyos PLCSIM verzióban) de sokkal nagyobb a valószínűsége annak, hogy a hibát te követted el valahol.

Ha elküldesz egy programrészletet ami reprodukálja a jelenséget, szívesen megnézem.
Nem lehet hogy keresztbe címzel? Pl. használod az M10.5-ös merker bitet és a programban valahol írod az MB10-et, MW10, MD10, MW9, MD9, MD8, MD7-et?

.

[ Szerkesztve ]

Szia.

Az az én álláspontom is, az a nap, amikor az ember lát v tanul valami újat, nem telt el hiába. Megvan a kis sikerélmény, ami pozitivvá teszi a mindennapi robotot.

Üdv!
Omron cj1m plc programozásával kapcsolatban lenne egy kis útbaigazításra szükségem.
Adott 3 tartály alsó- és felső szintérzékelővel, valamint tartályonként egy-egy ki és beresztő nyílással. A tartályokból folyik ki a víz, és ha valamelyik alsó szintérzékelő jelez, a kifolyást meg kell szüntetni, és el kell kezdeni tölteni. Egyszerre csak egy tartály tölthető, ezért ha valamely tartály töltése közben egy másik kiürül, akkor azt sorba kell állítani, mert a feltöltés a kiürülés sorrendjében történik.

A feladatot MOV utasítással kellene megoldanom, de nem igazán jutottam előre vele. Az alsó szintérzékelők egy számlálót léptetnek, aminek az értékét összeadva egy számmal beírom a D memóriaterületre. Ez határozza meg, hogy a MOV hova mozgasson.
Nekem viszont úgy lenne jó, hogy egy bitre léptesse be sorba a kiürülés sorrendje szerint, és ezt a bitet összehasonlítva már tudná, hogy épp melyik tartályt kell töltenie.
Hogyan lehetne ezt megoldani?

Helló skul0!

Nagyon úgy néz ki ez, mint egy olyan gyakorló feladat, aminek a megoldásához FIFO buffert kellene építeni. Ezt abból gondolom, hogy előírta a MOV használatát.

Én úgy csinálnám, hogy kijelölnék egy 3 elemű tártelütetet a buffer számára. Pl. D0-D2.
D0 lenne a FIFO teteje (bemenete) és D2 az alja (kimenete).

A FIFO úgy működne, hogy ha a D1 tartalma nulla, akkor beleírnám a D0 tartalmát és a D0-t törölném (0).
Utána ha a D2 tartalma nulla, akkor beleírnám a D1-et és a D1-et törölném. EZzel kész is a 3 elemű buffer.

Amikor egy tartály kiürül, a tartály számát bedobnám a FIFO tetejére (beírnám a D0-ba). Amennyiben a buffer üres, a fenti MOVE-ok (melyek minden PLC ciklusban lefutnak) a felül beírt érték leesne az aljára. Ha nem üres, akkor a benne lévő tetejére.
Így már nincs más dolgunk, mint a FIFO aljáról kiolvasni az értéket. Ha ott 1 van, akkor az 1-es tartályt töltjük, ha 2 van akkor a 2-est, ha 3 van, akkor a 3-ast.
Érdemes minden tartályhoz egy-egy RS tárolót (KEEP) használni, amit az adot ttartály leürülése bekapcsol, a megftelés pedig kikapcsol és a FIFO tetejére akkor bedobni a tartály számát, amikor ez az RS tároló bekapcsolt.

Így elkerülhető, hogy a folyadék lötyögése esetén többször is beíródjon a FIFO-ba ugyanannak a tartálynak a száma.

[ Szerkesztve ]

Szia!

Keresztbecímzésben lesz a hiba, innen legalább már erre is figyelek.

Szevasz Pifu!

"Keresztbecímzésben lesz a hiba, innen legalább már erre is figyelek."

Arra bizony nagyon oda kell figyelni, mert nagyon durván lehet szívni ilyen hibával!
Segít ezt elkerülni a keresztreferencia táblázat. De nem árt érteni amit mutat. Nem bonyolult, csak elsőre riasztó

Valamivel barátságosabb (kevesebb fölösleges infót ad ha csak egy cím érdekel) a Go To Location funkció.
A lényege az, hogy megmondja hol fordul még elő az a cím a programban. Csak azzal a címmel foglalkozik (míg a keresztreferenciában az összes benne van).
Egy listát kapsz az előfordulásokról amiből ha választasz, akkor oda ugrik.
Az ablakban van egy opció, aminek a neve "Overlapping access to memory areas".
Ha azt is bekapcsolod, akkor minden olyan címet is beletesz a listába, ami átfedésben van a keresett címmel.
Ez rendkívül hasznos!

A probléma akkor fokozódik, ha DB címekről van szó. Azokat ugyanis el lehet érni teljes címzés nélkül is. Pl. így:
OPN DB6
L DBW4

Mivel a fordító nem végez kód elemzést (nem is nagyon tehetne ilyet), nem tudja, hogy ha van egy L DBW4 az a DBW4 melyik DB blokkra vonatkozhat.
Azonban a GoTo Location ezeknek a megkeresésére is ad támogatást.
Ha csak a rövid címet adod meg, akkor felsorol minden olyan programsort, amiben az adott bit, byte word, dword címzése szerepel bármelyik DB-ben.
Hogy melyikben szerepel azt pedig megmutatja (ha tudja) ha kiválasztod az adott sort:

A probléma tovább fokozódik ha a keresett címet a program valahol indirekt módon is írja.
Az indirekt címzéssel e a keresztreferencia és így a GoTo Location sem tud semmit kezdeni, hiszen annak jellegéből adódóan a cím csak futás közben derül ki. Futás közben egy címet pedig számtalan körülmény befolyásolhat a kódtól függően, a fordító nem tudja előre hogy a lefordított kód milyen körülmények között milyen címet fog majd kiszámítani.

Üdv Emberek!

Múltkorjában még írtam ide OPTOVED es tanfolyamomon, elvégeztem azt is , meg leraktam egy automatika technikusit is. Sajnos igazából csak alapokra volt elég az egész, és nem sok időm volt foglalkozni vele a főiskola miatt (emiatt főleg csak olvaslak titeket). Most arra gondoltam ,hogy ebben a fórumban amúgy is hatalmas tudás lett összehalmozva, megpróbálnék egy katalogizált tudás bázist összedobni, amolyan hiba jegyzet szerűt, hátha sokaknak segítene, ha valakinek van hozzá ötlete szívesen fogadom

Helló dodzylla!

Jó ötletnek tűnik.
Az ilyesmit én támogatom. Akár a web oldalamon is adok neki helyet ha az a megoldás érdekel (természetesen a szerzők neveinek feltüntetésével).

Viszont arra számíts, hogy ha ezt komolyan akarod csinálni és nem csak egy kósza ötlet, ami elhal az első néhány próbálkozás után, akkor nagy munka!
A tartalom tekintetében egyelőre nem tudom pontosan mire is gondolsz, de ha tudok segítek.

Ajánlanám még figyelmedbe az ex prohardveres PLC fórumot, ami a googlegroups-on ébredt újra.
A jelenlévők által ott is komoly szakmai erőforrások vannak a háttérben.

Sziasztok!

Mivel még sosem programoztam gépet, csak tanulok de szeretnék kérdezni.
Végzett villamosmérnök vagyok, nagyjából ismerem a szabályokat (azért nagyjából mert az oktatásból ennyire futotta, azért kérdezek mert be akarom pótolni ami elmaradt)
A biztonságot szem előtt tartva, mik a kötelező szabályok amit nem szabad megszegni.

Gondolok olyanra, hogy Vész-stop megnyomásakor a motortól nemcsak a vezérlést, hanem a feszültséget is el kell venni. Vagy a vészkapcsolók NC gombokkal vannak kiépítve stb.

hasonló dogokat szeretnék tudni, gondolok én arra ,hogy a vész-kör sorosan van kiépítve és közvetlenül a plc vezérli, vagy mondjuk a biztonsági relé és csak az adja a jelet plc-nek.

Minden olyan fontos dolgot tudnom kellene ami a gépek programozásánál a biztonságot garantálja. Például addig nem indul a gép, míg van nyitott ajtó stb.

Nagyobb teljesítményű gépeknél kétkezes indítás van, azt kötelező biztonsági relével megoldani, vagy azt vezérelheti a plc?

Üdv Pifu!

Ez a téma nagyon messzire vezet. Elképesztően sok előírás, ajánlás és szabvány szabályozza a dolgot.
Szinte már politika az egész- Eszméletlen pénzek vannak a dolog mögött.
Minden eszköz ami safety kb. tízszer annyiba kerül.

Van néhány gyakorlati irányelv, ami ésszerű.
Pl. hogy a biztonsági kör a vezérlőtől (pl. PLC) függetlenül kell hogy letiltsa a berendezés beavatkozó szerveinek (motorok, szelepek, stb) energia ellátását.
Kivéve ha a vezérlő safety (biztonsági előírásoknak megfelel) aminek az ára kb. hússzoros.

Hogy milyen géphez milyen biztonsági intézkedések szükségesek (két kezes indítás, fényfüggöny, redundás vagy szimpla vész kör, deadman switch, stb) az tervezés során az ún. kockázat elemzés során dől el.

"Nagyobb teljesítményű gépeknél kétkezes indítás van, azt kötelező biztonsági relével megoldani, vagy azt vezérelheti a plc?"

Biztonsági funkciót csak safety képes PLC láthat el. Ha a PLC nem az, akkor a kétkezes indításhoz kétkezes indításra való biztonsági relé kell (tízszeres ár, a safety PLC-s meg még többszörös).

szia!

Köszön a választ, jól tudok témát választani.

Ez jelentheti azt, hogy ahol a vészkört biztonsági relével vezérlik, programozási szempontból csak a relé által adott jelet kell figyelnem?

Szia!

Így van.
Ezeknek a reléknek általában van egy bemenete amire jelet adunk, ha megszűnt az e-stop állapot.

Üdv Pifu!

Igen a biztonsági reléről természetesen lehet (és többnyire kell is) információt visszavezetni a PLC-be, hogy az intézkedni tudjon ilyen esetben (üzenet megjelenítése, technológiai (nem safety) beavatkozások elvégzése stb.).

A dolognak egyéb folyományai is vannak. Pl. ha terepi buszos hajtásvezérlők betáplálását választja le a1 biztonsági relé, akkor az eszköz eltűnik a buszról, aminek további következményei lehetnek. Ezzel is foglalkozni kell. Amire több lehetőség is van.

Hali!

Sikerült szereznem egy Siemens PLC bővítő modullal HMI-vel,viszont sajnos egy kábelt sem kaptam hozzá. Asztali gépen keresztül szeretnék itthon gyakorolgatni. Programozó kábel kellene,illetve még egy ugye amivel össze tudom kötni a CPU-t a HMI-vel.

Tudnátok segíteni milyen kábelek szükségesek/megoldások vannak,hogy minél olcsóbban életet tudjak lehelni a cuccba?

Esetleg valakinek eladó kábelek,vagy itthoni kábel építős megoldás?

CPU 224 DC/DC/DC (214-1AD23-0XB0)
EM 223 DC/DC (223-1BL22-0XA0)
TD 200

Előre is köszönöm!

"jobb adni,mint kapni" mondta a boxoló... :P

Sziasztok!

Köszönöm a segítőkészséget.

Szerintem a legfontosabb témát sikerült kiválasztanom, mert amíg a safety nincs a helyén addig semmi sincs.
Ez csak azért szomorú, mert elvégre végzett mérnök vagyok, de főiskola alatt még csak nem is esett szó a biztonsági reléről. De talán mentségemre szól, hogy azelőtt akarom bepótolni a hiányosságokat mielőtt még egyáltalán élesben kellene foglalkozni vele.

Ezt szem előtt tartva, tudnátok pár olyan fontos dolgot mondani, ami mondjuk egy állásinterjún is megfelelően hangzik és még után is tudnék nézni. például a cégnél mikor unatkoztam a preventa datasheeteket nézegettem, szerintem ez elég hasznos időtöltés.

A helyzet az, hogy mindennél jobban szeretnék egy célgépépítő cégnél dolgozni, de bekerülni ilyen helyre nagyon nehéz, most karbantartásban dolgozom, ahol leginkább gépészeti kihívások fogadnak amire egyszerűen nem vagyok felkészülve. Pl múltkor két napig állt a gép mire sikerült bebizonyítani a hozzá értőnek, hogy a szerszám tized mm kopása miatt nem megfelelő a beültetés, mondjuk ezzel nincs semmi gond, leolvassuk a szerszám rajzáról méreteket és a tűrést és utánanézünk, de a bajok ott kezdődnek, hogy meg kell találni azt amiről feltételezzük, hogy elkopott.
Egy szó mint száz, napjában többször hallom, hogy tized mm és tűrés, ellenben a byte szót még senki nem vette a szájára.

üdv
Pifu

Üdv Pifu!

"Szerintem a legfontosabb témát sikerült kiválasztanom, mert amíg a safety nincs a helyén addig semmi sincs."

Bizonyos szempontból. Konkrétan a hatósági ellenőrök, a munkavédelem szempontjából.
Egyébként meg az a lényeg, hogy a gép termeljen. És ezt most csupa nagy betűvel. BÁRMI ÁRON!

Na ezzel a kettővel kell kezdeni valamit "a életben".

halo !

a gépépítés tényleg jó.izgalmas meg minden.de egyvalami nincs : idő.gyakorolni se.

én dolgoztam ilyen cégnek, fura volt, hogy néha lassan indult be egy-egy projekt, majd valahogy hirtelen nagyon sürgőssé vált és tegnapra kellett a gép.
plusz a módosítások módosításának a módosítása ,mielőtt módosítanánk a módosításokat.
sok plusz kérés, stb.

sokszor egy termelő sor beépülő gépállomását csináltuk meg, azt például csak vasárnap lehetett installálni , de az éjszakás műszakra már termelnie kellett.
vagy meglévő berendezést kellett bővíteni, átépíteni és erre csak szombat és vasárnap estig volt lehetőség.
hányszor, de hányszor kértem csak 15 percet, hogy lássam mi történik , hogy dolgozik a gép amit módosítani, átépíteni, stb. szeretnénk.vagy bujkáltam a dolgozók között, lábuk alatt.legjobb barátom a szünet volt, amikor a dolgozók kimentek 10-15 percre.

volt olyan vasárnap, hogy épp végeztünk egy géppel, beépítettük a sorba.jó is lett.
egy másik gépet egy másik cég bővített két plusz munkahengerrel.de sem elektromos embert , sem PLC-s embert nem hoztak magukkal. kicsit elbeszéltek egymás mellett a megrendelővel.
már csak én voltam ott tőlünk, este 8 óra volt.akkor jött oda a helyi supervisor és megkérdezte be tudnám -e kötni a másik cég által beszerelt plusz alkatrészeket, illetve módosítanám-e a programot.de 22 órakor jön az első műszak, szóval működnie kellene.

az elektromos kollégát visszahívtam, mert igy már sok volt, vissza is jött és bekötötte az érzékelőket és a szelepeket, amíg én rájöttem mit is akar a gép csinálni, és átírtam a programot és a HMI-t, nem volt vészes.
22-re nem de 22:30-ra működött.én szerettem ezt csinálni, kár , hogy már nincs.

egyébként pl. (egy) japán érdekeltségű cégnél a biztonsági relé nem kötelező.saját elvárásai vannak, de azok ultra szigorúak. Master relé kell, de ez bármilyen lehet duplikálva. persze náluk más a leány fekvése: NPN logika, pozitív sarok földelés, 100-200v-os hálózatok, stb. persze a Master itt is hardveres kizárás, de nem kell biztonsági relé.

byte

[ Szerkesztve ]

Helló byte-by!

"a gépépítés tényleg jó.izgalmas meg minden.de egyvalami nincs : idő"

Van egy másik tényező is ami nincs rá: pénz.
Egyre inkább.
Az elvárások maximálisak, de a szakadék szálán kell táncolni. Pl. egyszerűbb gép esetén ne legyen benne PLC, csak relés vezérlés legyen, mert az iolcsóbb. HMI nem kell, csak kapcsolók, meg visszajelző lámpák.
Hiába mondjuk előre, hogy rendben van, lehet így is, de akkor az utólagos módosítgatás a működésbe sokkal fájdalmasabb lesz, mert egyrészt van fizikai vonzata, másrészt minden ilyen módosítást egyenként utólag be kell vezetni a tervbe. Ezek miatt a módosítás nagyságrendekkel több időbe és pénzbe kerül.

Vagy a PLC-s vezérlésbe a legolcsóbb szöveges HMI-t választják. De azon meg kell oldani, hogy mindent lehessen megnézni, mindent lehessen állítani, az egész föld térképét rá kellene tenni.

Ingyen legyen tegnapra, mindent tudjon!

halo !

" Van egy másik tényező is ami nincs rá: pénz.
Egyre inkább."

egyetértek.az sincs rá.
ez egyébként nagyon komoly problémákat okozhat. az olcsóbb anyagokból előállított alkatrészek kopásállósága értelemszerűen gyengébb, ez mindenre vonatkozik, csavarokra, lemezekre,támasztékokra, csapágyakra, sínekre, olcsóbb munkahengerekre ,stb.
csak egy példa : találkoztam olyannal, hogy az építő cég bevállalta , hogy egy emúlzióban alkatrészeket öblítő gép hengereinek érzékelőit nem ellenálló kivitelű érzékelőkkel szerelték, hátha szerencséjük lesz. persze a vezetékekről egy idő után simán levált a szigetelés, akkor is ha közvetlen kapcsolat nem volt a mosóközeg és a hengerek között, csak fröccsenés és a levegőben lévő mosópára.
az érzékelők nem mindíg érzékeltek, persze a megoldást tőlem várták: legyen élvezérlés,legyen elég ha csak elmegy előtte, az alaphelyzet nem is olyan fontos , időzítők használata - a biztonság minek,stb. anyádat.

sajnos ma már készülnek durva fostalicskák. tisztelet a kivételnek természetesen.
az biztos, hogy soha nem a gép a hülye, az csak azt teszi amire a tervezője képessé teszi és amire a programozója utasítja.

byte

Nem épp úgy tűnik, hogy újoncnak való szakma ez, de valahol el kell kezdeni.
Mondhatni úgy is, hogy sikerült kicsit rám ijeszteni
Ehhez képest az áramszolgáltatónál gyöngy életem volt, mikor 3-kor szépen elmentem haza az irodából...

halo !

semmiképp nem az volt a cél, hogy bárkire ráijesszünk.
senki nem született a felvett, megszerzett, megértett tudással.
újonc mindenki volt.
erőfeszítésbe kerül, de megéri.
ez az én véleményem, én is tanulom folyamatosan.

byte

Üdv, nem tudom, hogy jó helyen teszem-e fel a kérdést, ha nem akkor előre is elnézést. Esetleg nincs valakinek eladó programozó kábel Siemens S7 300-hoz(312-5AC82-0AB0)