Hirdetés
- Magga: PLEX: multimédia az egész lakásban
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Luck Dragon: Alza kuponok – aktuális kedvezmények, tippek és tapasztalatok (külön igényre)
- sziku69: Szólánc.
- sziku69: Fűzzük össze a szavakat :)
- GoodSpeed: Te hány éves vagy?
- weiss: Autó költségek
- Geri Bátyó: Agglegénykonyha különkiadás – Bors
- Luck Dragon: Asszociációs játék. :)
- Klaus Duran: Minden drágul. Vajon a fizetések 2026-ban követi minimálisan?
Új hozzászólás Aktív témák
-
Shirchy
tag
Üdv,
Az analog bemenet skálázásához a simemens beépített fc105-t használtam fel és most tesztelésnél számomra érthetetlen értékeket számol ki. Elvileg a bemeneten 0-27648-ig mehet majd a bemenő jel integerként. Próbának beírtam 13824-et ami a fele,így 4-et kellene kapnom real-ban,de totál nullát ad. Ugyan ez a helyzet 27648-as értéknél is ahol meg 8-at kellene adnia.
Nem értem mi a hiba.
-
Szirty
őstag
Helló rsf!
"Temp változókat nem nagyon szoktam használni és most teljesen elvitte a gondolataimat, hogy az STL-ben van elrontva vmi. Ugyanis STL-ben totál kezdő vagyok ez az első "művem"."
Nem gond amíg baj nem lesz belőle, ezért érdemes kipróbálni amit lehet.
Legalább megjegyzed. Mit gonolsz én hogy tanultam meg ennyire a TEMP tulajdonságait, hogy ezt mindenkinek az orra alá tolom? :-) -
rsf
senior tag
Hali,
Azt, hogy minden blokk ugyanazt a memória területet használja a Temp változókra nem tudtam!
Ezért nem értettem, hogy ha egyedül fut akkor működik ha meg fut a másik akkor nem.
Temp változókat nem nagyon szoktam használni és most teljesen elvitte a gondolataimat, hogy az STL-ben van elrontva vmi. Ugyanis STL-ben totál kezdő vagyok ez az első "művem".
Holnap átgyúrom kissé a progit.
Köszi a segítséget.
Üdv. -
Shirchy
tag
Sziasztok!
Lehet láma kérdés,de...
S7 300 Analog bemeneti kártyára érkező jelet, szoftveresen hogyan lehet szimulálni? Szeretném ellenőrizni,hogy a skálázás jól megy-e. Mikor VAT-ban akarok írni neki egy értéket,kiírja hibaként,hogy periféria bemenetnek nem lehet értéket adni.
-
Szirty
őstag
Üdv!
"> FB1 NW11-en a #PLC_Msg_Count_Tmp -be mindig belekerül a 35 (Ha elötte az
> olvasás át van ugorva akkor is)
> FB1 NW13-on a #PLC_Msg_RCount_Tmp -be mindig belekerül a 416(Ha elötte az
> olvasás át van ugorva akkor is)"Az ökölszabályt be kell tartani! Mindig! Nincs kivétel!
1. Avagy a TEMP változók tartalmát nem szabad felhasználni az értékadás előtt a blokk lefutása során!
2. A TEMP változók tartalma minden alkalommal elveszettnek tekintendő, amikor a blokk lefutott!Ok.: Minden blokk ugyanazt a memóriaterületet használja a TEMP változók tárolására (Stack).
Volt már róla szó.Ha egy TEMP változót olvasol értékadás előtt, akkor az azelőtt lefutott blokk memória szemetét találod benne! Ha nem fut másik blokk vagy az nem használja azt az L címet, akkor ugyanaz van benne amit a blokk beleírt, de ez igen csalóka és rettentő nagy szívás oka lehet!
Hiába adtál te valamikor értéket az FB1-ben #PLC_Msg_Count_Tmp-nek, ahogy a blokk lefutott, huss, az értéknek annyi lesz, elvész. Amikor az FB2 megint fut, már szemét van benne!
Az #PLC_Msg_Count_Tmp az FB1-ben történetesen a 4-es lokális címen van:
Az FB2-ben a 4-es címet az S_ANY pointer 4. byte-ja foglalja el, ami a DB száma:
L #PC_DBNum // Source DB
T LW 4#PC_DBNum meg az FB2 inputja, aminek éppen 35-ös értéket adsz híváskor:
Az LW4 tartalma marad az LW4-ben amikor az FB2 lefut, legközelebb fut az FB1, ahol az LW4-re épp a #PLC_Msg_Count_Tmp változó kerül. Ezért amíg az FB1 nem írja (nem ad neki értéket) a 35 ott ül benne!
Soha, de SOHA nem szabad TEMP változó értékét felhasználni azelőtt, hogy értéket adtunk neki amikor a blokk lefut. Az előző futáskori értékadás itt nem számít. Ahogy a blokk kilép, le van futva, TEMP változó el van veszve!
Emiatt arra is nagyon kell figyelni, hogy ha egy TMP változó értékadása feltételtől függ (pl. elágazás van előtte) de az tartalmának a feldolgozása feltételtől független vagy más feltételtől függ, akkor az elágazás(ok) teljesülésétől fog függni a szívás, vagyis az hogy épp szemét van benne vagy hasznos érték!
Erre NAGYON oda kell figyelni! -
-
KLR
csendes tag
Kössz a választ, épp erre jutottam én is.
Átnézve a programot, az első Section-ban konfigurálom az analóg modulokat, ott a 200 ms timer is, meg olvasom is az analóg bemeneteket az idő elteltével. De ki emlékszik pár Section-nal később, hogy az analóg kimenet írását is blokkolni kéne ugyanezzel a timer-rel 200 ms-ig
.
Kár, hogy a PLC 100 km odébb van, így nem tudom kiprobálni.
Remélem, nem lett a modulnak semmi baja... -
Szirty
őstag
Üdv KLR!
Így már jónak kellene lennie!
Annyit még, hogy az első ciklusban az n+1 és n+2 címekre küldött konfigurációs #80CC után mindenképpen várj minimum 200ms-ot mielőtt elküldöd ugyanide a konverziós adatokat!Különben előfordulhat, hogy kimegy ugyan a CIO word-be a #80CC, hiszen kiírja a program, de ha már azelőtt írsz oda mást, pl. a következő programsorban (#1770-et) akkor csak azt fogja megkapni a modul és "azt hiszi" hogy az a konfigurációs beállítás!
-
KLR
csendes tag
Tegnap este már valószínű nem voltam magamnál, ezért nem írtam érthetően. A W462-E1-07 Omron utasítást átrágása után írtam a programot (432 - 440 oldal). Ez alapján, az első két kimeneti címen konfigurálom az egész modult, amit az első ciklusban írok be, utána pedig szabadon írhatók a kimenetek 0-6000 (#0 - #1770). Az első ciklusban a 104 kimenetre #80CC (ami 1000 0000 1100 1100) küldök - ami 4 - 20 mA kéne hogy legyen az 1. és 2. kimeneten, a 105 kimenetre pedig #8000 írok mert nem használom őket. Utána programból írtam #1770-et a 104 és 105 kimenetre is, ami 20 mA-nak felelne meg, de nem küld semmit.
Próbálkoztam azzal is, hogy átkonfigurálom a kimeneteket 0-10 V (#8099 = 1000 0000 1001 1001), de nem jelenik meg feszültség Vout és Com között.
Sajnos, semmilyen jelzés nincs, azt se tudom él-e a modul. Ezért gondolom, hogy valamit elcímeztem...
-
Szirty
őstag
Helló KLR!
"de nem tudok kimérni semmit, pedig küldök #1770 a CIO 104/ CIO 105 kimenetre. "
A #1770 nem hiszem hogy jó lesz!
Ugyanis a 104 és 105 word-ök 3-as és 7-es bitjének jelentése ha tartalmuk nulla ->Output use: NO!
#1770 binárisan 1011101110000 tehát a 3-as és 7-es bit is 0 értékű, ami annyit tesz, hogy mind a négy kimenetet kikapcsoltad!
-
KLR
csendes tag
Sziasztok!
Omronban kérnék egy kis segítséget. Adott az alábbi konfiguráció:
1. CP1L-M30DR
2. CP1W-AD041
3. CP1W-DA041Az a fő gondom, hogy az analóg kimeneti modulon nem jön ki semmi. Átnyálaztam már egy párszor az utasítást, de nem jövök rá a hibára, biztos elnézek valamit. Kicsit furcsa, hogy Omronnál nincs HW konfig, hanem az ember maga számítgatja a címeket. Lehet, hogy ezt számítottam el?
Az én számításom szerint:
00.00-00.11 CPU bemenet CIO 0
1.00-1.05 CPU bemenet CIO 1
100.00-100.07 CPU kimenet CIO 100
101.00-101.03 CPU kimenet CIO 101
CIO 102 Analóg be 1-2 konfiguráció
CIO 103 Analóg be 3-4 konfiguráció
CIO 2 Analóg bemenet 1
CIO 3 Analóg bemenet 2
CIO 4 Analóg bemenet 3
CIO 5 Analóg bemenet 4 (nem használom)
CIO 104 Analóg kimenet 1-2 konfiguráció (csak első ciklusban) + Analóg kimenet 1
CIO 105 Analóg kimenet 3-4 konfiguráció (csak első ciklusban) + Analóg kimenet 2
CIO 106 Analóg kimenet 3 (nem használom)
CIO 107 Analóg kimenet 4 (nem használom)Az analóg bemeneteket olvasom gond nélkül ( 4-20 mA, beállítva #80EE és #800E). Az analóg kimeneteket próbáltam beállítani 4-20mA (#80CC) meg 0-10V-ra is (#8099) de nem tudok kimérni semmit, pedig küldök #1770 a CIO 104/ CIO 105 kimenetre. Az utasítás szerint, ezek aktív kimenetek, nem igényelnek külön tápot. Néztem az utasítást, hátha találok diagnosztikai regisztert a modulon, de semmi...vagy csak olyan fáradt vagyok, hogy nem látok.
-
moseras
tag
Szia!
Annyira nem értek a Siemens-hez, de az nem lehet, hogy túlcímzed a pointert, és olyan helyre mutat, ami már nem a saját lokális változói, hanem mondjuk a mögötte lévő terület (ami mondjuk épp a másik blokk lokális változói) ?
Ha a 2 név különbözik, akkor jól működik ?
Imi.
-
rsf
senior tag
Sziasztok
Az létezik Siemensnél, hogy FB blokkokban nem lehet ugyanolyan néven lokális változókat használni mint egy másik FB blokkban?
Van két blokkom ami mást csinál, mindkettő működik egyenként, de ha mindkettőt meghívom egyszerre akkor az egyik meghülyíti a másikat. STL-ben vannak írva.
Olyan érték kerül az egyikbe amit a másikban számolok any pointernek.
Mi okozhatja ezt? Mire figyeljek hogy ne szívassam magam fölöslegesen?
Köszi. -
Szirty
őstag
válasz
sörösló
#4370
üzenetére
Üdv!
Egyébként valóban! Ha gyakorlatiasak akarunk lenni, akkor bőven elég a következő:
1 db felső szint kapcsoló, 1 db alsó szint kapcsoló, egy darab mágneskapcsoló.
Ha a szint az alsó alatt van a szivattyút bekapcsoljuk ha a felső szint fölött van, a szivattyút kikapcsoljuk.
Egy darab mágneskapcsolót igényel a dolog (öntartás) és kész is.
Se PLC, se analóg mérés se frekvenciaváltó ehhez nem szükséges! -
sörösló
aktív tag
válasz
Shirchy
#4365
üzenetére
Ha ez elméleti, iskolai feladat, akkor feltétlenül a Szirty által javasolt megoldás a nyerő. Én a túltöltés figyeléséhez ebben az esetben "bevillantanék" egy ultrahangos szintmérővel is.
Ha valós, gyakorlatban használt a feladat, akkor viszont szerintem felesleges a frekiváltóval görcsölni. 200 m3-es tartály töltéséhez elég combos szivornya kell, ehhez a frekiváltó sem 2 forint. Elkezded a töltést egy szivattyúval, aztán ha adott idő alatt nem nő a kívánt mértékkel a szint, ráindítod a másikat is. 20-30 m3 víz töltése nem egy olyan rövid idő hogy a szivattyúkat túl gyakran kellene kapcsolgatni. Ez csak az én véleményem, de ha 50 m3-ig csökkenhet a szint, akkor nem lehet túlságosan igényes a fogyasztás folyamata sem.
-
Szirty
őstag
válasz
soldi3r
#4368
üzenetére
Üdv soldi3r!
Igen, de én inkább azt mondanám,hogy minden S7-1200 programozása megoldható UTP/STP ethernet kábellel. Mivel mindegyiken van ilyen csatlakozás. (sőt mással tulajdonképpen nem is, hacsak úgy nem hogy van profibusz is rajta).
Más szóval: A kábel minőségére nem hinném hogy érzékeny lenne, ha programozás ideje alatt csak egy néhány méteres kábelt használunk. Az lehet CAT3, CAT4, CAT5, CAT5e, CAT6, mindegy neki, mivel 10/100 Mbps ethernet interfész van benne.
Persze ha beépített kábelezésen keresztül akarod programozni (a PLC fixen csatlakozik lokális hálóra) akkor a kábelezés minőségének meg kell felelnie a körülményeknek és a használt adatsebességnek. De a CAT5 jó eséllyel annak is megfelel.
-
Szirty
őstag
válasz
Shirchy
#4365
üzenetére
Üdv Shirchy!
Én úgy csinálnám, hogy meghatároznék egy szintet ami alatt a szivattyú 100%-al megy és egy ennél magasabb (teljesen tele) szintet amit ha elér a tartály, akkor a szivattyú leáll.
A szivattyú sebességét e két szint által meghatározott tartománnyal adnám meg.
Meg tennék egy úszókapcsolót a túltöltés figyelésére. -
Shirchy
tag
Köszönöm a linkeket,ma este neki is ugrok..
Legalább egy szivattyút kell vezérelni,de ha az elsőt sikerül megoldani akkor kettő lenne aminél,ha egy keveset szállít akkor kapcsoljon be a második. Ne csak ki/be kapcsolgasson,hanem a finomabb szabályozás miatt kell a frekenciaváltó. (Nagyobb vízelvétel esetén többet szállítson,kisebb elvétel esetén kevesebbet)
A konkrét példa egy 200 köbméteres tartály feltöltése,majd ennek a tartálynak a szint szabályozása. Üzem közben 180 köbmétert kellene tartani,két kikötés van még:
- nem lehet 50 köbméternél kevesebb víz a tartályban
- túltöltés ellen védeni kell -
Szirty
őstag
válasz
Shirchy
#4363
üzenetére
Üdv Shirchy!
Ezeket ajánlom átnézésre, hátha találsz bennük számodra használható információt:
Tartály töltés
Analóg jelek kezelése
Analóg jelek kezelése S7-300/400 PLC-vel"Illetve ugye valahogy vezérelni kellene a frekvencia váltót is."
Akkor vezéreld valahogy!
Erre milyen választ lehetne adni? Mire kell vezérelni? Hogyan? Mi az igény?
Mi a célja a frekvenciaváltónak itt (mi az ok amiért van a rendszerben egy frekvenciaváltó)? -
Shirchy
tag
Sziasztok!
Szeretnék segítséget kérni. S7 315-2 DP-s CPU-s tartálytöltő rendszert kellene csinálnom,majd HMI-s felületet készíteni hozzá. A problémám az,hogy frekvenciaváltós szivattyú vezérlés,illetve analóg szintmérés kellene,és jelenleg fogalmam sincs,hogy kell lekezelni az analóg ki és bemeneti jeleket.
Vízszint méréshez nyomásmérőre gondoltam 4-20mA-es bemeneti jelet adna. Illetve ugye valahogy vezérelni kellene a frekvencia váltót is.
Szóval ez ügyben tudna valaki segíteni?
-
Szirty
őstag
Üdv oli83!
Igen erre a doksira hivatkoztam az előző üzenetben. Benne van a helpben is és a Step7 is feltelepíti ezeket:
Eredetileg ide teszi: Start menü / Simatic / Documentation / English / STEP 7 - Programming with STEP 7"A 15.8-as fejezet lapjának alján, mintha azt írná, hogy használjunk szimbolikus, illetve direkt címzést (nem dbx0.1-et, hanem pl. db10.dbx0.1-et)."
Igen ez az a rész amit említettem.
Arról szól, hogy sérülés vagy anyagi kár veszélye forog fenn, amikor:
1. FC FB blokkot hívásakor (illetve "többszörös példányt" tartalmazó blokkban)
2. DB blokk tartalmához a teljes abszolút címmel férsz hozzá
3. Komplex típusú változóhoz férsz hozzá (DATE_AND_TIME, STRING, ARRAY, STRUCT és UDT)
Ezekben az esetekben módosulhat a DB regiszterek tartalma (DI, DB), a címregiszterek tartalma (AR1, AR2) és az akkumulátorok tartalma (ACCU1, ACCU2).
Továbbá leírja, hogy ilyen esetben amennyiben ezeket a regisztereket használod, el kell menteni, majd tartalmukat vissza kell állítani."A "Hiba" változom az szimbolikus megnevezésnek kellene lennie nem?"
Ezt a kérdést nem értem.
-
oli83
tag
Ha valakinek kell:
angolul:
http://www.automation.siemens.com/doconweb/pdf/SINUMERIK_SINAMICS_02_2012_E/S7P.pdf?p=1
németül:
http://www.automation.siemens.com/doconweb/pdf/SINUMERIK_SINAMICS_02_2012_d/S7P.pdf?p=1
úgy érzem, ezt még át kell rágnom...
A 15.8-as fejezet lapjának alján, mintha azt írná, hogy használjunk szimbolikus, illetve direkt címzést (nem dbx0.1-et, hanem pl. db10.dbx0.1-et).
A "Hiba" változom az szimbolikus megnevezésnek kellene lennie nem? -
oli83
tag
Oh, erre nem gondoltam volna.
Köszönöm a segítséget.
Szóval el kellene menteni, majd vissza kellene adni neki az AR2-t.
Próbáltam csinálni egy megoldást, de ez sajnos nem jött be. Szóval még küzdeni kell vele egy kicsit.
Ezt a leírást, amit becsatoltál meg lehet valahol találni németül? Angolba vannak sajnos hiányosságaim.
üdv.: oli83
-
oli83
tag
Máris csatolom.
Temp:
Stat:
A statos változóknál először a Roh, és Normal változókat "Array [1..15] of Char" formátumban adtam meg.
A folyamat lefutásában ez nem változtatott semmit. Épp úgy hibára futunk.
Korábban láttam olyat, hogyha a változókat csupa nagybetűvel azonosítjuk "ARRAY [1..15] OF CHAR" akkor arra nem tudunk már szimbolikusan hivatkozni.üdv.: oli83
-
Szirty
őstag
Helló oli83!
1. Mutasd meg CPU stop utáni diag buffert! (hiba esetén hibaüzenetet nem hagyunk figyelmen kívül)!
2. Mutasd meg az FB133 blokk interface részét az összes használt változódefinícióval!Ha ennek a kettőnek eleget teszel az jelentősen növelheti az esélyeimet egy valamire való válaszra.
-
dokikaaa
csendes tag
Üdv!
Van egy ib il temp 2 rtd Phoenix-es ellenállás hőmérős modul, ami egy phoenix-es I/O szigetre van rákötve. A Phoenix-es io sziget profibuszon kommunikál egy siemens PLC-vel. A kérdésem az volna, hogy valamit konfigurálni kell ezeken az ellenállás hőmérő modulokon, vagy ha egyáltalán lehet, akkor hogyan paraméterezhető? A katalógus szerint van neki Controll Wordje, de a siemenses hardver configba csak statusz word van (PIW258), ami elvileg előjelesen adja vissza az analóg értéket. Ez a vissza adott analóg érték szoba hőmérsékleten 60-120 között megállás nélkül az ob35 ciklusaitól függően ugrál a két érték között. Ha a mérendő szakaszt felfűtöm(kb 100fokra), akkor 160-230 érték között szintén ugrál. (2 vezetékes bekötés)
Valakinek van valami ötlete hogy ezt hogyan lehetne használni? vagy nem jól működik a modul? (Másik 2 PT100-assal is ugyan ez a jelenség tapasztalható)
-
oli83
tag
Sziasztok!
Siemensesek segítsetek.
Írtam egy programot, amiben van egy hiba, és sehogy sem találom, mi a hiba forrása.
A progi hiba része egyszerűsítve így nézne ki:
A hiba az FB133-ban van.
Ha M10.0 bebillentem stop állapotba kerülünk.Tettem a progiba kikommnetezéseket (//), ezekben az esetekben M10.0 hatására nem kerülünk stop állapotba,
Mi lehet a gond?
Szükségem lenne mindkét címregiszterre, valamint statikus INT tárolóra.üdv.: oli83
-
Szirty
őstag
válasz
moseras
#4340
üzenetére
Üdv moseras!
"Akik PLC világból jönnek, ragaszkodnak a hagyományos PLC-s nyelvekhez, aki C++ világból jön, az ahhoz, akik WEB-es világból csöppen bele, az javascipt-ben akar PLC-t programozni"
Ez így van, ebből mindig van vita.
Ez a tény azonban a legkevésbé sem támasztja alá azt, a törekvést hogy PLC-t programozzunk pl. java scriptben.
Az ilyen vita szűklátókörűségből ered és hitvita jelleget szokott ölteni és átcsap veszekedésbe.A programozási nyelvek nem azért sokfélék, hogy mindenki használja azt ami neki a legjobban tetszik, hanem azért, mert specializáltak. A specializáció célorientáltságot jelent. Célja az, hogy az adott feladatot hatékonyabban és könnyebben lehessen megoldani, leprogramozni.
A feladat jellegéből adódóan a kilométeres logikai összefüggések programozására orientálódott nyelv a LAD és az FBD (az előbbi megdobva egy kis áramút terves múlttal is).
Meg lehet csinálni ugyanazt C nyelven is, de az kevésbé hatékony erre a kifejezett célra. A C ugyanis univerzális célú nyelv és mint tudjuk az univerzális dolgok sok mindenre jók egy kicsit. (Mint az ásólapát. Se ásni, se lapátolni nem lehet vele normálisan.)Aki meg létradiagramban akar PC-re grafikus felületű MP3 lejátszót írni, vagy PLC-t javascripttel programozni vagy operációs rendszert python-ban írni az szerintem meg is érdemli...
-
moseras
tag
válasz
dodzylla
#4337
üzenetére
Üdv!
Szóba jöhet még gondolkodásra alkalmasnak a matiec nevű fordító:
A benne lévő iec2c fordító tud ST-ből, IL-ből vagy SFC-ből C kódot generálni. Tehát ha valaki a PLC-nél megszokott programozási nyelvekben akarja leírni a kódot, akkor abból ezzel a fordítóval tud C kódot generálni, azt meg már mikrokontrollerhez vagy Raspberry-hez kis munkával tudja adaptálni. Persze a kommunikációt (legyen most OPC) ez a fordító nem fogja megvalósítani, azt továbbra is neked kell leprogramozni.
Mindettől függetlenül szerintem, az, hogy milyen nyelven programozzunk PLC-t (vagy milyen nyelven írjuk a Windows-on futó Soft PLC-t), az egy örök vita kérdése. Akik PLC világból jönnek, ragaszkodnak a hagyományos PLC-s nyelvekhez, aki C++ világból jön, az ahhoz, akik WEB-es világból csöppen bele, az javascipt-ben akar PLC-t programozni, vagy mondjuk mikrokontrollert:
[Javascript mikrokontrollerre]
Pl. a beckhoff új PLC-s fejlesztőkörnyezte (Twincat 3) a Microsoft Visual Studio-val van összeintegrálva, és a hagyományos ST, IL, SFC mellett lehetővé teszi C++ kódok írását is.
Imi.
-
-
Szirty
őstag
válasz
Mazsika
#4336
üzenetére
Üdv!
"Ez a megoldás már csak azért sem jó, mert így túl lassú lenne a folyamatod, mire átmegy opcn az adat +feldolgozás"
Sok olyan folyamat is van (főleg szabályzások) ahol 10-20 másodperces vagy akár perces beavatkozási gyakoriság is elég.
"Ráadásul egy s7nek is kell egy hw config tehat nem ugy van hogy kiveszed a dobozbol es megy..."
Úgy gondolom ennyire nem volt konkrét a kérdése. Nem írta hogy S7-ben gondolkozik. (az mellesleg pláne pazarlás lenne). A sok compact CPU nem igényel konfigurálást.
-
Mazsika
őstag
-
dodzylla
csendes tag
c++ magas szintű nyelv
assembly alacsony szint, de az nagyon körülményes mondjuk én nagyon szeretem de erre szerintem nem a legjobb bár gondolom a PLC is valami hasonlógépi kódra fordul le, mert végülis a PLC is egy mikrokontroller
Itt beszélnek hasonlóról bár itt RaspberryPI vel dolgoznak, az egy elég jó kis cucc, bár kezdésnek arduino jobb szerintem.
Itt olvashatsz.
http://www.raspberrypi.org/forums/viewtopic.php?f=72&t=54117 -
moseras
tag
válasz
n0rbert0
#4328
üzenetére
Üdv!
Az mennyire elképzelhető, hogy egy prg nyelvben, mint pl c++ egy szabályzás/vezérlés lenne megvalósítva, ami OPC szerveren keresztül a PLC memóriáját, IO-jait írja/olvassa?
Ez megvalósítható. Csináltunk hasonlót, csak nem OPC-n keresztül, hanem az egyik esetben MODBUS TCP-n keresztül ment a kommunikáció, a másik esetben pedig CANopen-en keresztül, szintén C++-al. Vannak ilyen megoldások nagy cégeknél is, pl. a Codesys-nél Real Time SoftPLC-nek hívják. Windows alatt fut, van egy Real Time beépülő modul, illetve emlékeim szerint az ethernet kártya driverének Windows kezelőjét is kicseréli, így "próbál meg" Real Time lenni. A demo-ját próbáltam, működik, de hogy mennyire Real Time, arra már nem emlékszem. Van free cucc is, az a neve, hogy ClassicLadder. Linux alatt is fut, ott az RTLinux patch-et használja. Használtam node.js-ben működő MODBUS TCP-n kommunikáló soft plc-t is, az is működik, a real time akkor nem volt fontos.
Szóval működik, véleményem szerint inkább a kiszolgáló op. rendszer, illetve az alatta lévő HW megbízhatóságával vannak problémák, és kérdések.
Imi.
-
n0rbert0
senior tag
Értem, akkor egy kicsit tovább megyek...
Az mennyire elképzelhető, hogy egy prg nyelvben, mint pl c++ egy szabályzás/vezérlés lenne megvalósítva, ami OPC szerveren keresztül a PLC memóriáját, IO-jait írja/olvassa?
Teszem azt, valaki vesz egy PLC-t használtan (pici pénzért), otthoni célra, de nem vesz hozzá szoftvert mert nincs hozzá kedvepénze, ezért fogja a c++ tudását és megvalósítja a vezérlést abban. (még mindig elméleti síkon...)Ez jó, így még nem hallottam ezt az aforizmát.
-
Szirty
őstag
válasz
n0rbert0
#4326
üzenetére
Üdv n0rbert0!
Nem vagyok nagy OPC tudor, de véleményem szerint az OPC kommunikáció mint szabvány, (legalábbis az MS azt szeretné) nincs felkészítve arra, hogy a PLC-ben futó programkódot megváltoztassa.
Jelen ismereteim szerint az OPC szerver feladata hogy hidat biztosítson a Microsoft windows és az automatizálás/folyamatvezérlés hardvere közötti adat átjáráshoz. Vagyis egy szabványos (ismert) és egységes kommunikációs (adatformátum) szintre emeli a különböző fajta vezérlőkből (pl. PLC-kből, így a gyártási folyamatokból) származó adatokat. Ezáltal ezek az adatok elérhetővé válnak a Microsoft windows rendszeren futó alkalmazások számára.
Nem célja az ipari automatizálásban, folyamatirányításban működő teljesen különböző vezérlő egységek programozásának egységesítése.(A személyes véleményem egyébként hogy jó az uniformis, mert mindegyiknek ugyanott van a zsebe, de van akire annyira illik, mint tehénre a gatya...)
-
n0rbert0
senior tag
Azt tudom, hogy általában az általad felsorolt esetekben szokták alkalmazni, de lehetne OPC szerver + valamilyen prg. nyelv alkalmazásával PLC szabályzást/vezérlést írni? (természetesen csak elméleti síkon)
Igen rosszul fogalmaztam alacsonyabb/hardware közelibb prg. nyelv (mint pl. egy interpretált java vagy phyton).
-
Szirty
őstag
Üdv bozig!
"Siemens-ről tudom, hogy a Simatic Step 7 kezeli a 61850-et, viszont azzal ugye csak Siemens PLC-t lehet programozni, ha jól tudom."
Nem tudom van-e félreértés, de ez a szabvány szerintem arra törekszik (arról szól) hogy az ember számára egységessé tegye a különböző PLC-k programozásnak legalább az alapjait és nem arról, hogy az ilyen szabványt használó szoftver képes legyen minden az összes olyan PLC programozására amelyik támogatja ezt a szabványt.
-
Mazsika
őstag
Persze ezeken kívül is még nagyon sok minden befolyásolja a megírt programot, persze az olvashatóság is fontos lenne, bár ez nem minden esetben jön össze...
Más: NTP szervert szeretnék használni, S7-300-asnál, viszont annyi baj van vele, hogy két órával korábbanra frissíti az időt. Gondolom valami időzóna téma, lehet ezt valahogy állítani a PLC-be?
-
moseras
tag
Üdv!
Ha valódi "objektum orientált" nyelvre gondolsz, amivel PLC-t is lehet programozni, akkor a Codesys V3.xx tud ilyent (a V2.xx nem!). A WAGO bizonyos PLC-it lehet Codesys V3-ban programozni (de nem mindegyiket, sőt a többségét nem).
Az is kérdés, hogy pontosan mit értesz objektum alatt. Mert ha elég az, hogy külön az adat "struktúra", és külön a kód, akkor az IEC 61131-3 is elég.
Ha valódi osztályokra gondolsz, akkor pl. Codesys V3, vagy esetleg olyan környezetek, amelyek megengedik C++ kód futtatását, és megengedik a C++ osztályait.
A Codesys nem nyílt forrású !
Imi.
-
bozig
tag
Sziasztok!
Az a kérdésem, hogy létezik-e, illetve ismertek-e olyan, lehetőleg nyílt forráskodú program nyelvet, amiben én tudok szabadon objektumokat definiálni, és adott esetben több gyártó PLC-it tartalmazza. Előrebocsátanám, hogy nem a saját agyszüleményem ennek keresése, tehát ha nagyon irreálisat kérdeztem, kérlek ne torkolljatok le. -
Szirty
őstag
Üdv tibi-d!
"Egy 32 bites memória területet elkülönítettek a vezérlés állapotnak."
Ismerős ez a megoldás is.
Gyönyörű, amikor egy ilyen (vagy számlálós-léptetős) szekvenciális programot újabb lépésekkel kell bővíteni.
Vagy átírod az egészet más számokhoz rendelve ugyanazokat a lépéseket, vagy a nem használt számokat veszed igénybe. Innentől 1,2,3,4,5,6,7,8,9 helyett majd az 1,2,10,11,3,4,12,13,5,6,7,8,9 fog egy sornak számítani.
De van olyan is, ahol erre gondoltak és egy integer mondja meg az aktuális lépés számát, amit nem egyesével növel, hanem tízesével. Így lehetőség van új lépések beszúrására. A rend így is felborul, mert kevésbé lesz követhető melyik lépés után melyik jön. Ráadásul az integer léptetése tele lesz komparátorokkal, mert 10 után 20 jön, de 20 után 21, majd 22, és csak utána 30. -
tibi-d
tag
Nálunk a Sirty által vázolt vezérlési logikát tovább bonyolították. Egy 32 bites memória területet elkülönítettek a vezérlés állapotnak. Ebből az első 10 (0-9) bit a berendezés kiindulási állapota, attól függően, hogy milyen üzemmód van kiválasztva. Ha a berendezés megkapja az indító parancsot, a 10-es bit aktivizálódik, (bárhol is volt előtte "0-9"). Ha az első parancsot végrehajtotta, lép a 11-re, stb. Előfordulhat olyan eset is, hogy pl. 12-es állapotról bizonyos esetben nem 13-ra, hanem 15-re lép. (Pl. ilyenkor nem balra mozdul, hanem jobbra). Majd onnan folytatja. De olyan is előfordulhat, hogy 21-ről 15-re lép vissza. Ez az éppen bekövetkező események függvénye. Ez a logika arra is jó, hogy csak ezt a 32 bitet regisztrálva vissza lehet követni a berendezés működési lépéseit.
-
tibi-d
tag
Sziasztok!
Pár gondolatot had írjak le, hogy egy főként ipari berendezés vezérlését hogyan lehet áttekinthetően megírni. Én a berendezés működését két alapvető tényezőre szoktam bontani. Egyiket feltétel rendszernek hívom, a másik az utasítás rendszer. Az első hivatott azt garantálni, hogy a berendezés soha ne kerülhessen olyan állapotba, ami a berendezés tönkremeneteléhez vezetne. A másik gondoskodik a működtetésről. Itt lehet programozni a kézi, automata, szerviz üzemmódokat, stb. Az automatikus üzemmódnál nálunk is alkalmazzák Szirty logikáját. A berendezés csak akkor végez feladatot, ha mindkét feltétel teljesül. -
Szirty
őstag
válasz
KB.Pifu
#4306
üzenetére
Üdv KB.Pifu!
"Kézi üzemmódban, a gépnél kiválasztunk egy állomást és gombnyomásra egyesével "végigléptetjük" a munkafolyamatot, ott már feltétlenül szükséges a számláló jelenléte, nem?"
Most attól eltekintve hogy mit gondolok a kézi üzemmódról, azt tudom erre mondani, hogy feltétlenül mindenképpen ide sem szükséges számláló. (az hogy most a lépési feltétel forrása tényleg számláló (C) vagy egy inkrementált merker word tartalma, az jelen esetben mindegy).
Pl. egyszerűen kell egy "lépés vége" merker, ami bebillen minden mozzanat végén és a léptetés gombbal lehet törölni. És ezt a merkert be kell rakni minden továbblépés feltételsorába. Ezzel ugyanúgy léptethetővé válik.A léptetőlánc nélküli programra van itt egy a közlekedési lámpánál valamivel komplexebb kidolgozott kommentezett feladat.
Ha gondolod nézd át: Tolópad szimuláció S7-300/400-ra -
byte-by
tag
válasz
KB.Pifu
#4307
üzenetére
halo !
ha a rendben befejezett munkafolyamat is feltétele a számláló léptethetőségének, akkor nyomkodhatod, nem fog történni semmi, amíg rendben végig nem csinálta az adott léptetést.de a számláló így sem szerencsés.
sok gépsor sajátja a "félautomata" üzem, volt szerencsém párhoz. van olyan gépsor ahol frankó távirányítóval kiválasztod az állomást , majd lépteted a folyamatot.mondjuk pont ez a gép nem volt a tervezés etalonja.
viszont a "kézi üzem" valóban a komponensek egymástól akár független működtetéséről szól, persze a megfelelő feltétel rendszer mellett. ez bizonyosan nem szekvenciális.ha esetleg szekvenciáról van szó számlálót én sem használok.leginkább egy merker szót szoktam használni amibe értéket írok ha a feltétel sor igaz.egy comparátorral ez adja a következő network első feltételét, aztán ha a többi is igaz lesz ,egy másik érték íródik bele.ezzel szekventált programblokkonként 1 merker word-öt használok el.
"félautomata" léptetéshez is használható, a befejezett hibátlan programsor fogja csak átírni a merker szót,majd újabb gombnyomás. ha közben is nyomogatják a gombot nem fog történni semmi.ez SZIGORÚAN szekvenciális gyártógépekre vagy állomásokra igaz.
egyébként sajnos tényleg igaz, hogy szinte csak a léptetős programírást oktatják.visznek kis kivágógép vagy mártogatógép modellt és mindenféle léptetős munkára bírják.persze látványos meg sikerélmény annak aki még semmi ilyesmit nem csinált,de kissé csalóka.sehol egy szabályzás, PID, regiszter kezelés, stb. de legalább felhívnák a figyelmet a továbbképzés szükségességére.
byte
-
Szirty
őstag
válasz
KB.Pifu
#4306
üzenetére
Üdv!
Az én értelmezésemben a "kézi üzemmód" azt jelenti, hogy kézzel kapcsolok be és ki mindent.
Tehát kiválasztom a hajtást/munkahengert és azt irányítóm. Ki/be kapcsolom két gombbal vagy előre/hátra vagy le/fel mozgatom.Az hogy egy automatikus folyamat állapotait léptetem nyomógombbal azt inkább félautomata módnak tekintem.
-
KB.Pifu
tag
Szia!
Köszi!
ezért vagyok ezen a fórumon, hogy másféle látásmódom legyen mint amit oktattak.
adott egy gép, mondjuk egy több állomásos összeszerelő automata..
Kézi üzemmódban, a gépnél kiválasztunk egy állomást és gombnyomásra egyesével "végigléptetjük" a munkafolyamatot, ott már feltétlenül szükséges a számláló jelenléte, nem?
Én ezt a feladatot saját meggondolásból számlálóval és pozitív élfigyeléssel tudnám csak megoldani. -
Szirty
őstag
válasz
KB.Pifu
#4303
üzenetére
Üdv KB.Pifu!
Ok.Tehát ha jól értem a kérdést akkor ez a válasz rá...
Nem szoktam számlálót léptetni amikor egy gép elér egy állapotot és megint léptetni amikor elér egy másik állapotot és így tovább. Az adott mozgásokat meg a számláló pillanatnyi értékéhez kötni.
Pl.: ha a számláló tartalma 1, akkor emelés szelep meghúz. Ha felért, számlálót léptetem. Ha számláló tartalma 2, akkor rögzítő szelep nyit, időtag indul. Ha időtag letelt, számlálót léptetem, ha a számláló tartalma 3 akkor... és így tovább.Kimondott léptetőláncot sem szoktam építeni, ami úgy működik mint a "futófény". Azaz van sok-sok merker bit, amik egymást billentik be egyéb feltételek teljesülése esetén. Amelyik bebillent az törli azt amelyik az imént bebillentette. Így lesz egy merker sor, amiben egy bit mindig 1 állapotú a többi meg 0. Az 01-es állapot "végig sétál" a láncon. ha 1-es lépés aktív, akkor akkor emelés szelep meghúz. Ha felért, láncot léptetem. Ha 2-es bit értékre 1, akkor rögzítő szelep nyit, időtag indul. Ha időtag letelt, láncot léptetem, stb, stb, stb.
Vannak gépek amik mozgása kifejezetten lépésekre bontható. Jól definiálható állapotok vannak amik mindig azonos sorrendben követik egymást és vannak amiké egyáltalán nem bontható ilyen állapotokra vagy ezek az állapotok véletlenszerű sorrendben követik egymás (pl. a technológiai állapottól függően).
Olyan esetekben ahol ilyen ismétlőfő lépések meghatározhatók én jelzőbiteket használok. Amikor egy művelet megtörtént, bebillentek egy jelzést és a következő műveletnek ez is feltétele (az egyéb véghelyzetekkel, időtagokkal együtt).
Ez funkcionálisan tekinthető léptető láncnak is, mert hasonlóan működik, de a program felépítése nem léptetőláncra épül.Más gépeknél (ahol nincsenek előre definiálható állapotok amik egymást követik) nem is alkalmazható ilyen módszer.
Ezért pl. kifejezetten haragszok amikor ilyet oktatnak. Illetve amikor csak ilyet oktatnak (pl. OKJ-s tanfolyamon, de egyetemen is. lásd futófény, közlekedési lámpa példaprogramok).Aztán a delikvens szembe találja magát pl. a kézi üzemmóddal vagy egy szabályzással, vagy olyan feladattal ahol rengeteg párhuzamos folyamat fut amik sorrendisége nem határozható meg előre, akkor csak lesnek mint hal a szatyorban...
-
Szirty
őstag
Helló hukhl!
Te már a komplett feladatot tekinted én meg az alapvető egységeket.
A létradiagramban és a relés vezérlésben is van érintkező, ami kétféle lehet: nyitó és záró. Meg "tekercs" ami kapcsolja ezeket
Illetve van érintkező amit kapcsoló vagy nyomógomb működtet (létradiagramban bemenet)."Illetve több feladatot is "ütemekre" bontva Counter és Comparator segítségével könnyedén megtudok csinálni addig ezt relékkel nem."
A komparátor és a counter valóban nem relé-konform
Sokszor megjegyeztem már ezzel kapcsolatban az aggályaimat.
Futófényt és közlekedési lámpát nem csinálunk a gyakorlatban ipari PLC-vel bármilyen meglepő is. Ettől még lehet kihívás a feladat, de a legkevésbé sem gyakorlatias példa.
A létradiagramos lépésenkénti (szekvenciális) programozás, ahol egymástól jól elkülöníthető és pontosan meghatározható állapotokból álló lépések vannak egy módszer.
De!
1. Erre önálló programozási nyelvek vannak (grafcet, graph)
2. Nem minden folyamat írható le elkülöníthető lépések sorozatával!Én pl. szinte soha nem használok ilyen számlálót, aminek az értékéhez állapotokat rendelek.
-
hukhl
csendes tag
Köszönöm a további segítséget!
Szirty: Igen itt valószínűleg valami alapvető értelmezési gondom lesz ,mert tényleg nagyon hasonló a két logika.Érdekes módon több szaktársamnál is az van ,hogy vagy a relés kapcsolást vagy LAD-ot értik ,de olyan hogy mindkettőt érti az már csak nagyon elvétve van. Itt szimbólumok egymásnak megfeleltetése jelenti a gondot pl. reléknél a kapcsoló,nyomógomb,időrelé kapcsoló stb. létezik addig LAD-nál simán van NO és azt címzem meg. Illetve több feladatot is "ütemekre" bontva Counter és Comparator segítségével könnyedén megtudok csinálni addig ezt relékkel nem.Jövő héten vége lesz a szorgalmi időszaknak ,akkor újra neki állok az elejétől fogva és tüzetesen átvizsgálom a dolgot.
dodzylla: Én is csak megerősíteni tudom ezt az oktatási színvonalat/rendszert ,de nagyon nem örülök ennek a "cég filozófiának" se. Egyszer csak elfogynak(kiöregednek vagy elmennek küldföldre) a régen végzett még megfelelő szaktudással rendelkező mérnökök/technikusok aztán marad a mi generációnk akiket meg sz@rnak most gyakornokként is fogadni.
.
pár percet rálehet szánni, ha tudod ,hogy nem jó az is + tudás
Új hozzászólás Aktív témák
- Samsung Galaxy S25 Ultra - titán keret, acélos teljesítmény
- iPhone topik
- One otthoni szolgáltatások (TV, internet, telefon)
- Magga: PLEX: multimédia az egész lakásban
- Esik a hóóó!!
- Folyószámla, bankszámla, bankváltás, külföldi kártyahasználat
- Azonnali alaplapos kérdések órája
- Éjszakai műszak
- MIUI / HyperOS topik
- CES 2026: Új autót mutatott be a Sony Honda Mobility
- További aktív témák...
- Azonnali készpénzes GAMER / üzleti notebook felvásárlás személyesen / csomagküldéssel korrekt áron
- ÁRGARANCIA!Épített KomPhone Ryzen 7 9800X3D 64GB RAM RTX 5090 32GB GAMER PC termékbeszámítással
- ÁRGARANCIA!Épített KomPhone i5 12400F 16/32/64GB RAM RTX 5060 Ti 16GB GAMER PC termékbeszámítással
- Eladó ÚJ BONTATLAN Samsung Galaxy A17 5G 8/256GB / 24 hó jótállás
- LG 77C3 - 77" OLED evo - 4K 120Hz 1ms - NVIDIA G-Sync - FreeSync Premium - HDMI 2.1 - PS5 és Xbox!
Állásajánlatok
Cég: Laptopszaki Kft.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest