- Mikrokontrollerek Arduino környezetben (programozás, építés, tippek)
- Tetőfokára hág a tavasz, és ezt a hardverek is érzik
- Egérpad topik
- Intel Core i5 / i7 / i9 "Alder Lake-Raptor Lake/Refresh" (LGA1700)
- Kezdő fotósok digitális fényképei
- TCL LCD és LED TV-k
- Milyen HASZNÁLT notebookot vegyek?
- Gaming notebook topik
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Google Chromecast topic
Hirdetés
-
Spyra: nagynyomású, akkus, automata vízipuska
lo Type-C port, egy töltéssel 2200 lövés, több, mint 2 kg-os súly, automata víz felszívás... Start the epic! :)
-
Anyagi katasztrófára figyelmezteti az Apple-t a brit média
it AI-alapú adatvédelmi funkciót (reklámblokkolót) kaphat a Safari böngésző az iOS 18-ban, de brit médiacsoportok arra figyelmeztetik az Apple-t, hogy ez anyagi katasztrófát okozhat az ágazatban.
-
67 wattos gyorstöltés és Leica kamerák a Xiaomi kagylóján?
ma Megkérdőjelezhető hitelességű fotó és valós hitelesítési adatok a Mix Flipről.
Új hozzászólás Aktív témák
-
Szirty
őstag
-
Szirty
őstag
Hali vopi86!
000000: A 0.00 bemenet 1 állapota elindítja a TIM1 timert, ami 2 másodpercig telik (#20). Tudom te 5-öt akarsz, majd annyit írsz be.
000001: A 253.13 egy belső flag, ami állandóan bekapcsolt állapotú (always on). Azért van rá szükség, mert a CMP utasítás nem rakható le úgy, hogy nincs előtte feltétel, ezzel a flaggel lehet elhelyezni hogy mindig elvégezze az összehasonlítás.
A CMP(20) az összehasonlító utasitás, ami operandus 1-et 8ami jelen esetben a TIM1 tartalma) összehasonlítja operandus 2-vel (ami jelen esetben egy BSD konstans, konkrétan a #1 érték). Az összehasonlítás eredménye beállítja a GR, EQ és LE, azaz a nagyobb mint, egyenlő és kisebb mint jelzőbiteket.000002: Ha a 255.06-os bit =1 (történetesen ez az egyenlő jelzőbit, amit az előbbi CMP(20) állít be) akkor bekapcsolja a 10.00 kimenetet, egyébként nem kapcsolja be.
A következő két sor ugyanez, csak nem #1-el, hanem #2-vel hasonlít és nem a 10.00, hanem a 10.01 kimenet kapcsol amikor a timerben #2-van.
Egyszer már ajánlottam neked ezt a leírást.
A 207. oldalon ékes magyar nyelven magyarázza példával a CMP(20) COMPARE utasítás működését.Ui.: Mivel a standard timer 100ms időalappal működik, egy tizedmásodpercig fogja csak bekapcsolni neked a kimeneteket ez a program!
[ Szerkesztve ]
-
Szirty
őstag
válasz byte-by #2685 üzenetére
Helló byte-by!
"Ha minden comparátor ugyanazt a special bit-et (255.06) használja, akkor a rákötött kimenetek mind aktívak lesznek , ha ez 1-ben lesz nem ?"
Nem. Bár tudjuk, hogy a létradiagram a huzalozott vezérlések kiváltására jött létre így azt utánozza és ahhoz hasonlít. Ha ezt a létrát lehuzaloznád, akkor úgy volna ahogy feltételezed.
De mégis csak egy processzor hajtja végre a programot, ami nem egy időben hajt végre minden utasítást, hanem sorban elemzi ki a logikai műveleteket és sorban kapja meg az egyes eredményeket. Létra esetén konkrétan soronként fentről lefele és a soron belül balról jobbra történik.Ha a létrában bekapcsolsz egy bitet valahol a programban, az onnantól lefele be lesz kapcsolva egészen addig, amíg valami valahol (esetleg ugyanaz a sor a követező ciklusban) ki nem kapcsolja. Annyi csavar van még a dologban, hogy ha ez a bit egy fizikai kimenet, akkor a kimenetre a programon belül történt ki vagy bekapcsolás állapota minden ciklusban csak egyszer, a PLC ciklus végén jut el, mert a kimenet amit a program ki vagy bekapcsol nem a fizikai kimeneti bit, azt csak a PLC operációs rendszere írja ki a ciklusok végén.
No de visszatérve a kétségeidre:
Ha írunk egy ilyen programot:Akkor az a következő eredményt adja. Ha a 0.00 bemenet OFF, akkor a 10.00 OFF, a 10.01 ON, a 10.02 OFF, a 10.03 ON állapotú lesz. Ha bekapcsoljuk a 0.00 bemenetet, akkor 10.00 ON, 10.01 OFF stb lesz.
Így működik a korábbi példában lévő összes flag, így az összehasonlítás eredményét tároló flagek is. A programban ahogy az sorban fut, minden CMP utasítás a saját eredménye szerint beállítja ezeket a flageket. Az összehasonlítás eredménye a programban bárhol felhasználható, de csak a következő CMP utasítás előttig, mert az felülírja őket a saját eredményével.
A CMP flagek tehát mindig a legutóbb végrehajtott összehasonlítás szerint állnak be. Ebből következően fontos az alábbi két szabály:
1. Összehasonlítás végrehajtása nélkül nem értékeljük ki a flagek eredményét
2. A flagek eredményét bármennyiszer felhasználhatjuk, de csak a következő összehasonlításig. Onnantól már a másik CMP eredményét tartalmazzák... -
Szirty
őstag
válasz byte-by #2687 üzenetére
Hali byte-by!
Amikor a komparátor "kimenetére" tesszük a kimenetet vagy a további feltételeket, belül (alacsony szinten) akkor is minden komparátornak ugyanazokat a jelzőbiteket állítja be és ugyanazt használja a feltételeknél.
Ez S7-nél tetten érhető azzal, hogy megnézzük STL-ben a létrában írt összehasonlításokat. Ott az RLO-ba kerül az összehasonlítás eredménye (mindamellett,hogy ott is van kisebb, nagyobb egyenlő stb jelzőbit, amikbe szintén bekerül az eredmény).
Az ilyen létrárban csak a megjelenítés módja tér el (magasabb szintű) így nem merül fel az ellentmondás. -
Szirty
őstag
Hali vopi86!
Ha tudnám milyen a PLC-d (azon kívül, hogy CPM1, mert abból is van vagy öt fajta) esetleg kiderülne, hogy olyan fajta-e amin történetesen alapból van két db potenciométer. Konkrétan a CPM1-10CDR, CPM1-10CDRT, PM1A-10CDT1-D pl. ilyen, de lehet hogy mind, azt most nem fogom megnézni.
Ha ilyen, akkor ennek a két potméternek az állását egy-egy belső szóból kiolvashatod (IR250 és IR251) amiket a programban arra használsz, amire akarsz, Pl. időtag SV (Set Value) értéke is lehet. Ennél egyszerűbb nincs, mert ez már adott.
A másik lehet egy (vagy több) külső BCD kapcsoló.
Ezek azonban elfoglalnak digitenként négy bemenetet (ha multiplexeled, akkor 4 bemenetet, +digitenként egy kimenetet. Persze multiplexelés nem jöhet szóba relés kimenetű PLC-vel.
Vagy készítesz valami egyedi megoldást az időtag állítására. Pl. egy "növel" és egy "csökkent" gombbal teszed állíthatóvá, esetleg előre fixen beállított időértékek között választasz bemenetek állapota alapján, stb.
"...beviteli eszközt,kijelzőt, ami olcsóbb mint egy hmi"
Minden ilyen eszköz alapvetően HMI
-
Szirty
őstag
Helló vopi86!
Attól függ pontosan hány BCD kapcsolót kötsz be és pontosan hogyan szeretnéd az időt állítani.
Ha csak egyet, azon egy számjegy állítható be. A timernek meg #0000-#9999 érték adható. Akkor állítod tízesével, százasával, vagy hogy (pl. a kapcsolón a 5 #50-et jelent a timernek, ami 5 másodperc, a 4 #40-et, ami 4 másodperc)?Ha négyet raksz, akkor hogyan kötöd be? Multiplexeled, vagy nem, ha nem, akkor 16 bemenet kell hozzá. Stb..
Szóval megmondom hogyan kell programozni ha megmondod mit.
-
Szirty
őstag
Helló vopi86!
Nos feltéve hogy a BCD kapcsoló a 0.00-0.03 bemenetekre van kötve úgy, hogy 0.00=bit0, 0.01=bit1, 0.02=bit2 és 0.03=bit3, akkor a program a következő:
Az első MOV nullát ír a DM0 memória címre, előkészítve a terepet a TIM SV elhelyezésére.
A MOVD digit mozgató utasítás. Az első operandusa a forrás, (honnan vegye a digitet). Ez itt 0 vagyis a 0. csatorna, ami egy 16 bites (4 digitet tartalmazó) WORD és a 0.00-0.15 bemenetek bitjeit tartalmazza.A MOVD második operandusa a vezérlő szó, ez mondja meg a MOVD-nek honnan hova hány digitet mozgasson. Ez itt #0100 konstans érték ami azt jelenti, hogy a 0 csatorna 0. digitjétől kezdve 1 digitet átmásol a célterület 1. digitjébe.
A 3 operandus a D0, ami a DM adatmemória terület első címe. Ez is egy Word (A DM terület szabadon használható a programban) ide fogja mozgatni a digitet.Ha tehát a 0.00-0.03 bemenetekre kötött kapcsolón pl ötöt állítasz be, aminek bináris mintája 101, akkor azt a MOVD a DM0 bit4-bit7 bitjeibe (2. digit) másolja aminek eredményeképpen ott előáll a 1010000 bináris érték, ami megfelel a BCD 50-nek, ami 5 másodperc időzítést fog jelenteni.
Végül a DM0 a TIM1 SV operandusa, a TIM1 tehát addig telik amekkora idő van a DM0 memóriacímen.
-
Szirty
őstag
válasz Csakénvagyok #2705 üzenetére
Helló Csakénvagyok!
"azt viszont nehezebb összehozni hogy a proci a egy tetszőleges képernyőt jelenítsen meg,"
Ilyesmire viszonylag ritkán van szükség...
-
Szirty
őstag
válasz Royality20 #2716 üzenetére
Helló Royality20!
"visualizációval egy input értékét nem lehet megváltoztatni igaz? ezt ugy értem hogy lerakok vizuba egygombot megcimezem pl Ix0.0 és ha a gombot megnyomom azt a inputot egynek nézné."
Végig gondoltad hogyan tudna működni egy ilyen megoldás? Hogyan oldanád fel azt az ellentmondást, amit ezzel a megoldással hoznál létre?
Egy digitális bemeneti bit állapotát a PLC fizikai bemenetére kapcsolt feszültség határozza meg. Ha nincs fesz. a bit=0 ha van fesz a bit=1. Tehát MINDIG vagy nulla vagy egy!
Ekkor jösz te a gonboddal és megnyomod. Nyilván azért, hogy az amúgy éppen nullában lévő bitet 1-be állítsd (hisz ezért raktad oda). Ekkor szerencsétlen bitet egyszerre kellene nullába (mert a bemenet inaktív) és 1-be (mert nyomod a gombot) állítani. Na ilyenkor mi legyen?
Vagy mi legyen ha nem nyomod a gombot de a bemeneten feszültség van? Csak akkor billentse 1-be amikor nyomod és ne bántsa ha nem nyomod, vagy akkor nullázza amikor nem nyomod és hagyja érvényesülni amikor nyomod? stb.
Tudom (gondolom) hogy te az összes variáció közül, ami az elvi lehetőségek kombinációjából következik csaj az egyik szeretnéd, de honnan tudja a PLC hogy melyik lenne az?Az ellentmondás feloldására vannak bevált módszerek.
Az egyik és (részemről) leginkább ajánlott az, hogy soha nem csinálunk ilyet
Ha valamit bemenettel és HMI gombbal is kapcsolni kell, akkor tegyünk külön változót a gombnak és a PLC programjában írjuk meg mikor melyik bit (a gomb bitje ill. a bemeneti bit) mit kapcsoljon hova.A másik hogy mégis így oldjuk meg: a bemeneti bitet kapcsolunk a HMI gombjával. Sok PLC-nél ezt meg lehet tenni (mert a HMI megengedi), csak nem nagyon van értelme, mert akárhogy is nyomkodjuk azt a gombot, a bemeneti bit állapotát a PLC minden ciklusban (néhányszor 10 ezred másodpercenként) felülírja a bemenet fizikai állapotának megfelelően.
A harmadik módszer a FORCE mód. Ezt bizonyos PLC-k támogatják (pl. Omron, Siemens). A lényege az, hogy ebben a módban bizonyos be vagy kimenetek állapotának vezérlését át lehet venni a PLC programtól és pl. a programozó eszközről lehet őket vezérelni. Ez a mód azonban hibakeresési tesztelési céllal létezik. Nem javasolnám üzemszerű használatra. Főleg mert rettenetesen be tudja vinni az embert az erdőbe aki erről mondjuk nem tud és keresi a hibát...
-
Szirty
őstag
válasz lakatosturbo #2719 üzenetére
Helló lakatosturbo!
"Most az a nagy gondom hogy amikor a tartálytöltés szimulációt beadom neki megnyitom wincc-vel akkor a vizet engedi csak nem töltődik a tartály meg a szelepet se tudom megnyitni mert arra meg olyasmi hibát dob, hogy nem tudja beolvasni az értéket."
Jó volna tudni mit üzen a runtime indulás után.
Ezt kellene ott látnod:Ha a "kapcsolat felépítve" helyett az van hogy "kapcsolat leépítve" akkor nincs kapcsolat a PLCSIM és a flex runtime között, az a baj. Ennek oka az is lehet, hogy a PLCSIM-et a flex RT után indítottad el. (előtte kell).
A másik ok a nem megfelelően beállított PC/PG interface (ezen keresztül akar kapcsolódni a runtime a PLC-hez).Ha van kapcsolat (a változó hibákra való utalás alapján erre következtetek) akor nem töltötted fel a DB255-ös adatblokkot (abban vannak a változók).
Továbbá a töltés után a PLCSIM-et RUN módba kell átkapcsolni! -
Szirty
őstag
válasz Royality20 #2728 üzenetére
Helló Royality20!
Nem ismerem a codesyst, de a problémád megoldására az egyik lehetséges mószer a kerekítés
Biztosan van benne ilyen utasítás (Round, RND stb).
A kérdéses real típusú értéket megszorzod 10-el, kerekíted majd elosztod tízzel. Az eredmény 1 tizedes jegyre kerekített érték lesz
(Ha két tizedes jegyre akarsz kerekíteni, akkor 100-zal kell operálni) -
Szirty
őstag
Hali w3dzz!
"Az ehet baj, ha a WinCC-ben a panel kiválasztásakor Version of device: 7.2.1.0 és 7.2.0.0 lehetőség van a panel menüjében pedig Image: 6.0.3.2?"
Nem. Azzal csak akkor lesz baja, amikor sikerül neki a kapcsolat és elvégzi a version check-et.
Valószínűleg kérni fog egy OS update-et.A kapcsolat sikertelenségének az oka meg lehet pl. az, hogy a panelen nem állítottad be mit is szeretnél.
Ott ugyanis be kell állítani hogy milyen csatornán szeretnél feltölteni rá és azt is, hogy automatikusan induljon a transfer ha megszólítod, vagy csak transfer módban:Ha az Enable channel be sincs kapcsolva azon az interfészen, akkor nem fogad onnan project feltöltési kérelmet!
Ha az be van, de a Remote control nincs bekapcsolva, akkor fogad ugyan project feltöltést, de csak akkor, ha a panelt előbb tarnsfer módba helyezed.
Ha ez enabled, akkor automatikusan fogadja, nem kell transfer mód.Továbbá a panelen be kell állítani a panel címét is ha MPI/DP vagy ethernetes feltöltési módot akarsz (most had ne emlékezzek rá, hogy az IF2 melyik) és a WinCC Flexben az itt beállított címen kell megcélozni a panelt a Transfer menüben...
[ Szerkesztve ]
-
Szirty
őstag
Helló w3dzz!
Csinálj egy loopback tesztet a soros porton hogy kiderüljön jó-e.
-
Szirty
őstag
válasz DP_Joci #2742 üzenetére
Helló DP_Joci!
Én sem teljesen értem, de ennyi alapján én azt mondanám, hogy ha egy mérés van, de két beavatkozó (fűtés és hűtés) akkor egy PID-et használnék. Ha a beavatkozó jel negatív akkor az egyik, ha pozitív akkor a másik beavatkozó eszközt vezérelném.
Egy PID-del is lehet szívni (beállításkor), de ha egynél több is van és ezek hatással vannak egymásra, akkor könnyen lesz a beállítása rémálom.
-
Szirty
őstag
válasz DP_Joci #2745 üzenetére
Hali DP_Joci!
Alakul, de még mindig vannak kérdések:
Miféle samson szelep? (gyártanak/árulnak vagy 20-40-60 félét). Ez valamiféle propszelep lesz?"folyadéknak a hőmérsékletét kell szabályozni a visszatérő ágban mért hőmérséklet alapján"
Először előremenő ágat írtál. Tehát ott mérjük a fűtéshez a hőmérsékletet, ahol a tartály palástból kilép a fűtőközeg?
"Ha nagyon felforrósodna a gőz (95fok fölé), akkor a gőzt el kell zárni"
A gőz? Van 95 foknál hidegebb gőz? Vagy a másodlagos fűtőközegre értendő, (amit a gőz fűt és ami a tartály palástba belép és azt illetve nyilván a tartalmát fűti?A másodlagos fűtő közeg, ami a palástban áramlik és a gőz fűti, az zárt körben áramlik?
A hűtőfolyadék szelep propszelep?
Én nem használnék csak egy PID-et. Nem a kézi üzemmódba kényszerítéssel állítanám le ha 95 foknál melegebb, hanem a kimenete után venném el a beavatkozó Jelet és a PID-nek küldenék erre az időre egy INT_HOLD jelet.
A kézi üzemmódot meghagynám, hasznos lehet szervizeléshez, teszteléshez.
A web oldalamon találsz néhány infót S7 PID-del kapcsolatban esetleg az is segíthet... -
Szirty
őstag
válasz DP_Joci #2747 üzenetére
Szia Joci!
"A fűtéshez én is egy PID-et gondoltam használni, valamint egy másik PID-et a vákuum szabályozáshoz."
Az így korrekt szerintem.
"Mi a véleményed arról, ha a hűtőközeg hőmérséklet emelkedése esetén a samson szeleppel sorba épített szeleppel elzárom a gőzt, a szabályozót pedig hagyom szabályozni tovább (gondolom ez folytatni fogja a zárást). "
Hát ha jól van beállítva. De lássuk be, a gépkezelők leleményessége szinte végtelen.
A sorba épített szelep jó ötletnek tűnik, mert sok propszelep nem képes a 100%-os zárásra egy idő után (nálunk is van ilyen megoldás gőzre).
Én ilyen esetben a PID-et felfüggeszteném INT_HOLD és nulláznám az integráló tagot (már ha lesz integráló tag használva persze).
Mert esetleg gőz nélkül rossz beállítás vagy egyéb miatt az integráló tag elballag 100%-ig és akkor a visszahűlés miatt rányit a másik szelep, esetleg gond lehet.
Vagy tenni kell egy rámpagenerátort a PID és a szelep közé"Gondolom lesznek meglepetések ha a hőmérséklet elkezd növekedni és a tartályban keletkeznek gázok, ezek biztos megzavarják a vákuum szabályzós PID-et. Mit gondolsz erről?"
Erről azt gondolom, hogy a PID szabályzó alapvető feladata a beállított érték tartása éppen a zavaró körülmények ellenére.
Ha egy szabályzókörben nem volnának zavaró körülmények, szabályzóra se nagyon volna szükség. Csak beállítanánk valamennyi beavatkozó értéket és készen is van
Abban viszont igazad van, hogy valószínűleg ugyanakkor épp ez lesz a feladat egyik nehézségeA fordulat eltéréses elméleti fejtegetés szerintem helytálló.
Csak nem mindegy hogyan figyeled (számolod) a motor fordulatát. Lehetőleg a kimenő frekvenciát kell alapul venni, hogy a kapott érték helyessége a lehető legkevesebb egyéb beállítástól vagy körülménytől legyen függő.
A másik tanácsom, hogy a jeladó által adott impulzus hossza a legextrémebb esetben se legyen rövidebb, mint a PLC legnagyobb ciklus idejének a duplája. persze ha lassan forog, akkor ezzel nem nagyon kell foglalkozni. Az impulzus figyelésnél használj él figyelést és legyen néhány (10-20%) tolerancia a védelem megszólalásában, esetleg néhány másodperc időzítés (legalább két impulzus idő). -
Szirty
őstag
válasz Dezsi82 #2753 üzenetére
Helló Dezsi82!
Vízre gondoltam, az atmoszferikus nyomásnál sokkal jelentősebb nyomáson a vázolt feladatot figyelembe véve.
Az iparban a gőzfűtést ugyanis jellemzően ilyen fizikai körülmények között oldják meg.
Ezért így ott nem fordulhat elő pl. 80 fokos vízgőz.Mellesleg mi ez az előítélet, hogy vegyületre gondoltam? És ha nem vegyületre, hanem kémiai elemre? :>
-
Szirty
őstag
válasz Dezsi82 #2755 üzenetére
Hali Dezsi82!
"(bele is írtam), de az is elég egyértelmű volt, hogy a kérdező sem arra gondolt."
Nem mindig van bekapcsolva a varázsgömböm. Olyankor arra ragálok amit leírnak és nem arra amit írás közben gondolnak. Nem kell zokon venni, nincs mögötte gonosz szándék (ráadásul nem is neked szólt).
"Kiemeltél egy logikai bukfencet, én is ezt tettem."
Igen. Egy másik "logikai bukfenccel". Miért? (erre nem kell válaszolni, tudom :>)
"Senki sem mondta, hogy Celsius fokról beszélünk. Lehetne Fahrenheit vagy Kelvin."
Így van! Látom kezded érteni mi itt a lényeg...
"Említs meg légyszíves nemesgázokon kívül elemeket, amelyek elemként előfordulnak és nem alkotnak vegyületet."
Miért pont azokon kívül?
-
Szirty
őstag
válasz 01101010111 #2762 üzenetére
Helló 01101010111!
"Teljesen, más: soros portos laptopok közül melyiket érdemes megvenni szerintetek?"
Én használtam Toshiba TECRA 8200-at, jól működött minden eszközzel a soros portja amiket próbáltam. Ez sajnos már elég régi típus, (800MHz Mobil I pentium, 512MB RAM).
Most egy Dell Latitude D630-at használok. Nagyon strapabíró, soros porttal nincs kompatibilitási gond (sokmindenbe bedugdosom). Ez már izmosabb kicsit, bár ez sem mai típus (Intel Core2 duo T8100 2.1GHz 4GB RAM). Jelenleg a munkához teljesen megfelel (bár kapott egy nagyobb HDD-t).
-
Szirty
őstag
válasz 01101010111 #2776 üzenetére
Hali 01101010111!
"( Supply és load votage között magyarul hogyan lehetne különbséget tenni? Mindegyik tápfeszültséget jelent, nem?)"
Be és kimeneteknél meg szoktuk különböztetni az eszköz (buszos elektronika) táplálását és a kimenetekre kapcsolt eszközök táplálását (kimenetek közös (COM) csatlakozása).
Az előbbit az eszköz állandóan kapja, az utóbbit pedig huzalozott feltételeken keresztül, főleg biztonsági relék, vészleállítás általi leválasztással.
Így lehet megoldani biztonságosan hogy egy szelep, mágneskapcsoló, stb ne kapcsolhasson be vészleállítás esetén akkor sem, ha a PLC kimenet (távoli out) mondjuk bekapcsolva marad.
Ez fontos biztonsági intézkedés![ Szerkesztve ]
-
Szirty
őstag
-
Szirty
őstag
válasz DP_Joci #2783 üzenetére
Hali DP_Joci!
A távadó méréshatára és a D/A-ról érkező értéktartomány a mérvadó a fizikai mennyiség kiszámításánál..
Ha az analóg bemeneten 0 olvasható be 4mA áramnál és 27648 20mA áramnál,
és a távadó méréstartomány -10...200 fok C, akkor 0 beolvasott érték tartoztik -10 celsiushoz és 27648 200 fokhoz.
Ha a távadó 0-400 fokos, akkor 0=0, 27648=400 -
-
Szirty
őstag
válasz isvarga #2795 üzenetére
Hali isvarga!
Nocsak. Egy mikrovezérlős PLC fejlesztési projecttel már találkoztam a HE oldalain.
Gratulálok, ez szép munka!Pár megjegyzést teszek (elvégre ezt kérted).
A hivatkozott oldalon van egy ilyen megjegyzés "(érdekes idáig azt hittem a PLC-garantál valami futás teljesítményt az egyes program elemekre )"Igen a PLC determinisztikus. Vagyis garantált hogy egy programciklust véges és ismert időn belül befejez (vagy végrehajtja, vagy ha az nem lehetséges, akkor jelzést ad).
(Már ha erre gondoltál)Pár kérdés, ami eszembe jut:
A ki és bemenetek galvanikusan le vannak választva? Ez rendkívül fontos az üzembiztonság szempontjából. (az ipari PLC-k ilyenek).Amennyire látom az eszközt közvetlenül a mikrovezérlő nyelvén lehet programozni, vagyis nincs semmilyen szoftver környezet, oprendszer benne.
Ez nagyobb rendszerek hatákony fejlesztésénél, ami erre az eszközre épül, komoly akadály lesz. Bár lehet nem is arra szántad.
Emiatt a készülék inkább célvezérlő, mint univerzális ipari PLC.Mindenképpen derék amit létrehoztál!
-
Szirty
őstag
válasz isvarga #2798 üzenetére
Hali isvarga!
"Az adott alkalmazások időbeni garantált lefutására gondoltam .(nálam is adott felhasználástól függ )"
Én pont azt szerettem volna kiemelni, hogy a PLC MINDIG determinisztikus. Ez nem függ semmitől, az alkalmazástól meg pláne nem.
Egy ciklus garantáltan véget ér egy megadott időn belül (ált. max. 100ms körüli értéket szoktak megengedni, de nagyobb PLC-knél ezt lehet állítani is).Ha mégsem képes lefutni (hogy képes-e vagy sem az a kódtól függ, mert lássuk be: egy végtelen ciklusra annyira nem jellemző hogy meghatározott időn belül lefutna) akkor a rendszert biztonságosan leállítja (vagy egyéb olyan akciót hajt végre, amivel a probléma biztonságosan kezelhető).
-
Szirty
őstag
válasz isvarga #2800 üzenetére
Helló István!
"Úgy emlékszem 1-100ms között írta az értéket ,csak akkor ezek szerint állítható )
Talán akkor ez a legnagyobb különbség a 2 megközelítésben.(bár számomra ez mosolyogtató érték)"1-100ms nem vicces, hanem egy rendkívül jó gyakorlati érték.
Te a mikrovezérlők irányából jösz és furcsa, mert ott nano meg mikroszekundumok vannak.
Nálunk 20ms ciklus idővel közepes teljesítményű S7 PLC-vel teljes gyártósor üzemel.
Rajta profibuszon: 27 pozícionáló szervóhajtás, két Fanuc robot, 10 decentralizált frekvenciaváltó, 5 további frekvenciaváltó.
Ugyanezen a PLC-n profineten egy Cognex alakzat felismerő kamera és egy operátor panel.
Ugyanezen a PLC-n egy Interbus interfész, amin 800 db digitális I/O pont dolgozik.
A PLC ethernet hálózaton kapcsolatban áll több más PLC-vel (a gyártás más gyártósorait vezérlik) és Oracle szerverrel, ami a termékkövetést intézi.
Ilyen egy közepes testhez álló feladat egy PLC számára ipari környezetben.
Tehát buszos eszközök százai, szervók, hajtások, (buszos mind) lézeres távoslág mérők, nyomás távadók, szintmérők, mérleg modulok, stb, stb, stb..."3 fórumot találtam ahol foglalkoznak a témával (2 aktív) ,végig olvastam a beszélgetéseket ."
Az általam ismert és aktív PLC-s fórumok az alábbiak:
Hobby Elektronika
Ez a fórum
PLC fórum
És PLC levelező lista"Egy plc használata semmivel sem egyszerűbb ,mint mondjuk a mikró számítógépek. Az egyetlen előnyét abban tudnám megfogalmazni ,hogy "konyhakész" termékek ,és ha az én céljaimra megfeleltek volna biztos abba az irányba indulok."
A PLC-k célorientált, a feladatra specializált eszközök annak megfelelő programozási lehetőségekkel és tudással. Ennélfogva ilyen feladatra nagyon hatékonyak (az általános célúaknál hatékonyabbak).
"Az én véleményem szerint a megfelelő eszközt a megfelelő munkára ."
A legnagyobb mértékben egyetértek
[ Szerkesztve ]
-
Szirty
őstag
válasz isvarga #2802 üzenetére
Hali isvarga!
Látom a válaszodból, hogy nem igazán fogadod el amit írtam.
Én terepi buszos szorvókat említettem, nem egy bemenete van, amivel megmondod hogy A vagy B pontba menjen, hanem profibuszos kapcsolat van és sok száz bit a szervó és a PLC közötti kommunikáció.
Aktuális pozíció, aktuáli ssebesség, felfutó rámpa, lefutó rámpa, előírt sebesség, paraméter készlet, státus szó (32 bit) vezérlő szó (32 bit) üzemmód, célpozíció, stb, stb, stb. Ez szorozva annyival, amennyi szervóhajtás van a rendszerben.Az említett (példaként hivatkozott, valóságban is működő) rendszer PLC programja százezer sor (az adat struktúra definíciók és adatblokkok tartalma nélkül, csak a program kód). Ezzel próbáltam szemléltetni egy közepes bonyolultságú PLC vezérlésű alkalmazást.
Sajnálom ha nem sikerült."A PLC verzióban nincs gyorsulás -sem számolt lassulás ,tehát egy sokkal lassabb ,rugalmatlanabb eszközt kapok."
Tévedés! A lényeg ennek éppen az ellenkezője.
Meg kellene nézed és meg is ismerned egy ilyen rendszert ahhoz, hogy korrekt véleményed lehessen róla.
[ Szerkesztve ]
-
Szirty
őstag
válasz isvarga #2804 üzenetére
Helló István!
Reméltem hogy nem lesz rá szükség, de akkor az egyértelműség kedvéért leírom mi volt a célom a példával és mi nem.
Nem volt célom vele a PLC népszerűsítése, az eredményeid lekicsinylése és nem volt célom magamat dicsőíteni sem. Igyekeztem úgy fogalmazni, hogy ez a vád ne merüljön fel, és azt hiszen nem is merült fel.Egyszerűen csak leírtam címszavakban egy közepes méretű (bonyolultságú) PLC-s vezérlés műszaki tartalmát, hogy világos legyen mire használnak az iparban PLC-t.
Azért, mert korábbi üzenetekben tettél néhány olyan kijelentést, amiből arra következtettem, hogy nem ismersz ilyen rendszereket kellő mélységben ahhoz, hogy tárgyilagosan nyilatkozz róluk.
Nem volt bántó szándék sem mögötte."(aki ismeri a léptetőmotor vezérlőket az tudja miről van szó)"
Használtam már léptetőmotort PLC-s rendszerben. Külön vezérlő van hozzá (FM353 volt).
Nem hinném hogy ettől rugalmatlanabb lassabb lenne. Különösképpen azért sem, mert ennek a megoldásnak pontosan az a lényege, hogy a lehető legrugalmasabb és legsokoldalúbb legyen, de az alkalmazhatóságát ez ne rontsa. (nem egyszerű ezt megvalósítani, a két dolog hatása ugyanis éppen ellentétes egymással). -
Szirty
őstag
válasz byte-by #2806 üzenetére
Hali!
"ha valaki időt és energiát fektet bele, a PLC azt is "elárulja" mi a hiba, hol a probléma, sőt , mit kell tenni, vagy csak megteszi amit kell.csak program kérdése.
nem tudom a micro-val ez megtehető-e."Sajnos nem jutott eszembe megemlíteni a fejlesztői környezet és a diagnosztizálhatóság (hibakeresés) fontosságát. Szerencsére Te megtetted.
István!
Ennek hiánya mérhetetlenül aláássa a rugalmasságot és a hatékonyságot.
Pl. futásközben a vezérelt gép működése közben módosítható program, a belső állapotok, változók, memóriatartalmak megfigyelhetősége működés közben olyan tulajdonságok, amik fontosak egy PLC-ben.
Nem tudom ilyesmi mennyire lenne megvalósítható egy PIC-es vezérlésben... -
Szirty
őstag
válasz isvarga #2808 üzenetére
Üdv István!
"Csak remélni merem ,hogy ezek után kifejted bővebben is ,mert nagyon érdekelne a dolog."
Én ezt már kifejtettem, szerintem ilyesmire gondolt:
Gyakorlati tanácsok gépek programozáshoz és tervezéshez
A hibakezelő OB-k
Hibakezelés: az OB86 (Rack Failure) -
Szirty
őstag
válasz isvarga #2809 üzenetére
Üdv istván!
Mivel egyre egyértelműbb, hogy álláspontjaink ennél jobban már nem fognak közeledni egymáshoz, összefoglalom a magam részéről a témát:
A mikrovezérlőnek és a PLC-nek is megvan a maga létjogosultsága (én az utóbbira próbáltam rávilágítani, de az előbbivel is tisztában vagyok).
Mind a kettő hatékony a maga területén.
Ahova jó választás egy mikrovezérlő, oda botorság PLC-t rakni, ám egy mikrovezérlőt PLC-s feladatra használni semmivel sem kevésbé ostobaság.
Ugyanakkor tudom, hogy a két terület között a határ nem penge éles, van átfedés. De ha mindkét terület közepéből veszünk mintát (nem véletlenül emlegettem közepes PLC feladatot végig) akkor teljesen egyértelmű, hogy nagy különbség van a kétféle megoldás szintje között (és itt nem minőségi szintről van szó).Ha te olyan eszközt akarsz építeni, ami minden tekintetben (HW és szoftveres szempontból egyaránt) megfelel olyan feladatoknak amire a PLC, akkor te egy ugyanolyan PLC-t fogsz építeni, ami ellen jelen pillanatban tiltakozol. (talán jó példa erre az Unitronics)
Miért? Mert az évek során a fejlesztések abba az irányba vittek és jelenleg általánosságban az a megoldás a leghatékonyabb ipari folyamatok irányítására. A vitát megelőzve, amit ebben a mondatomban sejtek sietve kijelentem, hogy: nem azt írtam, hogy mással lehetetlen megoldani!Valószínűleg egyedül otthon NYÁK-olgatva nincs esélyed utolérni a fejlesztésben olyan gyártókat, akik évtizedekig, sok tagú mérnök csapattal a háttérben dollármilliókért fejlesztették ki mai PLC-iket. Bár látom, hogy igazából nem is ez a cél (igaz amit írsz az nem mindig van összhangban azzal amit látok, vagy én értek félre néha valamit)...
-
Szirty
őstag
válasz isvarga #2812 üzenetére
Hali!
"Az én fejemmel ennek semmi köze nincs a programozáshoz (fölkészülni minden eshetőségre)"
Ilyen hibakezelésekből szokott állni nem kevés program jelentős része! Amelyikben ilyen egyáltalán nincs, az régen rossz.
Sok-sok óra fejlesztés megy rá ilyesmire.
Ha egy berendezés hibás működési állapotainak program által történő felismerésének megvalósítása nem programozás, akkor nem tudom mi. (Bár itt mi is inkább favágásnak hívjuk).
De ha szigorúan vesszük a programozás az én értelmezésem szerint valamilyen programnyelven program írása (utasítások egymásután helyezése, ami egy adott algoritmus megvalósítását célozza).
A hibás állapotok észlelése, kezelése, üzenetek megjelenítése is ezen a "programozás"-nak nevezett tevékenység által valósul meg.A paraméter állításokat programozásnak nevező megrendelő esete nem tudom hogy kapcsolódik a témához (így nem tudom példaként vagy ellenpéldaként értelmezni)
-
Szirty
őstag
válasz isvarga #2819 üzenetére
Üdv István!
"Egyébként a láttam olyan PLC leírást ahol 1:1 assembly utasítások is voltak a parancsok között."
A legtöbb PLC-nek (illetve fejlesztői környezetnek) van több szintű nyelve. alacsonyabb, magasabb. pl. Siemens S7-nek is van assembly-szerű nyelve (ami szintén célorientált).
"Olyan ez mint amikor a HMI megszólítja Janit , "már megint sörözni voltál te tróger " a HMI -nek dunsztja sincs mit ír ki ,csak aki ezt megcsinálta."
Az a cikk, aminek a linkjét idéztem amikor először emlegettél sci-fi-t (és ezek szerint nem olvastad el) a hibakezeléssel kapcsolatban pont ezt a témát feszegeti.
"Az ,hogy kitaláltak maguknak saját elnevezéseket , kommunikációt , csak a saját piac védelme miatt van."
Ezt nagyon rosszul látod! Ez csak részben igaz.
Avagy: nem azért találnak ki saját megoldásokat, hogy a saját piacukat védjék, hanem mert a dolog egyértelműen megkívánja, hogy dolgokat kitaláljanak (fejlesszenek).
És miután kifejlesztik (sok idő és pénz) már persze hogy védik!
Emberbaráti jóindulatból nem lehet megélni. Ezért gondolom nem fogsz te sem évekig heti 40 órában fejleszteni egy összetett kommunikációs módszert, majd azt teljesen ingyen mindenki rendelkezésére bocsátani."Van ez a profibus kommunikáció : (idáig én csak rs485-nek ismertem aztán modbusnak)"
A modbusnak semmi köze a Profibuszhoz. Azt egy másik cég fejlesztette ki (Schneider a Modicon PLC-ihez).
Az RS485-nem és a profibusznak meg annyi köze van egymáshoz, hogy az előbbi egy fizikai hordozó "réteg", míg a másik protokoll.
A profibus DP nagyon univerzális (ezért szükségszerűen nagyon összetett is) terepi busz kommunikációs protokoll ipari vezérlések, folyamatirányítás számára. Ez az RS485 vagy fizikai réteget használja (vagy száloptikát). (a ProfiNET pedig ennek az ethernetes implementációja). Ciklikus, Master-Slave alapú, token-ring szerű, fél duplex kommunikáció jellemzi. Megengedi a multi-master módot.A Profibus PA azt hiszem csak a fizikai hordozóban tér el. Itt két busz-szerű vezeték van, ami az eszközök tápellátását is biztosítja. A vezeték speciális, kialakítása olyan, hogy az eszközöket egyszerű bárhova ráfűzni a vezeték megbontása nélkül (vámpírcsatlakozós megoldás). Robotoknál NC gépeknél nem hiszem hogy gyakori az előfordulása. Inkább process automation (folyamatirányítás) a fő csapásiránya (arra lett kitalálva a fizikai kialakítása). tehát nagyobb távolságra lévő műszerek, távadók buszra fűzése pl.
ha jól emlékszem a megengedett max. adatátviteli sebessége jóval alacsonyabb mint DP esetében...A profibusz több céghez kötődik, tulajdonképpen ipari szabvány, amit a PI (Profinet-Profibus) konzorcium koordinál.
Sok infó van róla a neten. mellesleg a profinet.com cím is oda visz... -
Szirty
őstag
válasz DP_Joci #2821 üzenetére
Helló DP_Joci!
.fwx-et? Sajnos nem, semmiképpen.
Az sajnos már bináris és csak a futtató környezet számára szükséges adatok szerepelnek benne, a szerkesztő számára elengedhetetlen infók nem.
Ebből a szempontból olyasmi mint a bináris .exe, amiből már nem lehet visszanyerni az eredeti forrásprogramot. -
Szirty
őstag
válasz bodnarg #2828 üzenetére
Helló bodnarg!
A maximum és a minimum meghatározása elég egyszerű. Két változóra van szükség és minden mérési ciklusban a mért eredményre.
Nézzük a MAX-ot.Kell egy változó, amiben az addig mért legnagyobb értéked lesz majd (MAX). Ebbe kezdetben nullát töltesz. Amikor mérsz egyet megvizsgálod, hogy mért érték nagyobb-e mint MAX. Ha nem, akkor nem bántod, ha nagyobb, akkor a mért értéket beleteszed MAX-ba. Ezzel kész is. Ez akár milliárd mérés közül is tárolja az addigi maximumot. Egészen addig, amíg le nem nullázod újra (vagy feltétel nélkül bele nem töltöd a mért értéket).
A minimum meghatározása ugyanez, csak kisebbre hasonlítasz.Az átlag rafináltabb. Több módszer is van, nemrég volt szó róla a PLC levelező listán is. Szerintem olvasd el ott mit hoztak ki belőle.
-
Szirty
őstag
válasz bodnarg #2834 üzenetére
Helló bodnarg!
"mivel 8 jelet kell átlagoljak, előggé feltornázta ciklus időt"
Csinálj egy ring buffert, amibe egy mutatóval írsz, (Amikor a mutató eléri a buffer végét, az elejére állítod, így a címzés megy körbe-körbe)
Amikor mérsz egyet, akkor a mérési eredményt hozzáadod egy változóhoz, kiolvasod a ring buffer mutatója által mutaott elemét, amit kivonsz az iménti változóból, majd lépteted a buffer mutatóját, utána oda beírod a mért értéket.
Az átlagot ezután úgy kapod meg, hogy a változód tartalmát elosztod a ring buffer méretével.Előnye, hogy minden méréskor csak 3-4 műveletre van szükség és nem kell annyi amennyi elemű a buffer. vagyis sokkal kevésbé erőforrás igényes.
Új hozzászólás Aktív témák
- Xiaomi 14 Ultra - Leica hercegnő
- Mikrokontrollerek Arduino környezetben (programozás, építés, tippek)
- PC-re tart a God of War Ragnarök?
- Már nem hisz a nagy európai EV-forradalomban a Ford
- ASUS routerek
- Ford topik
- Nők, nőügyek (18+)
- Apple iPhone 15 Pro Max - Attack on Titan
- Dragon Age: Origins
- Fortnite - Battle Royale & Save the World (PC, XO, PS4, Switch, Mobil)
- További aktív témák...
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: Alpha Laptopszerviz Kft.
Város: Pécs