- SzőkeKapitán: Világ vége túlélők topicja
- sziku69: Szólánc.
- bitpork: Phautós tali a Balcsinál 2025 Augusztus 2 napján (szombat)
- Luck Dragon: Asszociációs játék. :)
- sziku69: Fűzzük össze a szavakat :)
- gban: Ingyen kellene, de tegnapra
- Őskoczka
- Zicokuka: Minden változik,a Cod 2 örök
- Sub-ZeRo: Euro Truck Simulator 2 & American Truck Simulator 1 (esetleg 2 majd, ha lesz) :)
- D1Rect: Nagy "hülyétkapokazapróktól" topik
Új hozzászólás Aktív témák
-
#8855
Szirty
őstag
mark.david92
#8853
Szirty
őstag
válasz
mark.david92
#8853
üzenetére
Szia!
Javaslatok:
- Használj HSC-t a hozzájuk tartozó bemenetre kötött encoderrel (akkor nem számít a PLC ciklus ideje a számlálásnál)
- Esetleg használj HSC megszakítást
- Az encoder értéket ne egyenlőségre hasonlítsd, hanem > vagy < értékre vagy tartományra -
Szirty
őstag
válasz
spkkill
#8597
üzenetére
" Eljátszottam a gondolattal, hogy egy adott saját kis rendszert kialakítva lehetne egy alternatíva a GUI, a méregdrága ipari HMI-k helyett."
Ha ingyen csinálod, és/vagy ezredét tudja.
Ha piacképes HMI rendszert fejlesztesz akkor te is csinálsz egy "méregdrága" HMI rendszert.Az jut eszembe erről mint amikor valaki megismeri az arduinot és nem érti miért kerül másfél millióba egy S7 CPU319...
-
Szirty
őstag
Szia initio!
"Bocsánatot kérek, ha nem jó helyre kerül"
A kezdeményezésed a leírtak alapján tiszteletre méltó. Nekem is volt hasonló (nem video alapú) oldalam.
Ez a topic azonban PLC programozásról szól, az általad közölt tartalom azonban nagyon más.Nekem nincs lehetőségem a megfelelő helyre továbbítani, de remélhetőleg megtalálod azt az illetékes személyt aki megteszi.
-
Szirty
őstag
Nem vagyok egyik módszer ellen vagy mellett. Az adott helyzet dönti el melyik az értelmes megoldás.
Az impulzus számlálós módszernek is megvannak a nyilvánvaló korlátai.
De ha valaki megemlíti mennyire nagyot lehet azzal szívni, akkor én meg had említsem meg hogy a terepi buszokkal is igen nagyot lehet szívni. Sőt!
(Ha a kőkorszakos "beszólásod" nincs, elmegyek mellette)
-
Szirty
őstag
"Back to the stoneage?!"
Sajnos Occam mostanában ritkábban borotválkozik.
Arra utaltam hogy ha egy feladat adott körülmények között, a feltételek módosítása nélkül megoldható egyszerűn és bonyolultan is, akkor az egyszerűbbet érdemes választani.Használsz kést otthon a konyhában, vagy orrfűrésszel / láncfűrésszel / lézerrel szeled a kenyeret?
A kés őskori találmány nem?"Akinek kalapács van a kezében az hajlamos mindent szögnek nézni"
-
Szirty
őstag
válasz
spkkill
#8433
üzenetére
Szia!
Talán nem ment át amit leírtam: "tisztán logikai összefüggésekhez".
Mindent arra kell (érdemes) használni amire való. A LAD/FBD nem hatékony számolgatásokhoz, adatkezeléshez.
Az STL meg logikai összefüggések programozásához.Ezt én sem így oldom meg:
Hanem így:
L PIW 256
ITD
DTR
L 1.223400e+000
/R
RND
T #Out -
Szirty
őstag
-
Szirty
őstag
válasz
Tomika86
#8412
üzenetére
Szia!
Ha szimbolikus címzésmódot használsz akkor átcímzi.
A project fa Blocks elemén jobb katt, menüből Object Properties... kiválaszt.
A megjelenő ablakban válts az Address priority: fülre és kapcsold be a szimbolikus programozás módot:
Ezután ha címet módosítasz (ha a jobb alsót kapcsoltad be akkor bármilyet) akkor átírja a hivatkozást a program blokkban de sajnos csak akkor ha megnyitod és kimented azt a blokkot. Ilyenkor szól is:
Szerintem próbáld ki egy üres próba projecten és PLCSIM-ben esetleg mielőtt ezzel kapcsolatban újabb kérdést teszel fel, mert én spec. nem használom a szimbolikus módot
-
#8415
Szirty
őstag
BDominik2001
#8411
Szirty
őstag
válasz
BDominik2001
#8411
üzenetére
-
#8390
Szirty
őstag
Baliboy1979
#8387
Szirty
őstag
válasz
Baliboy1979
#8387
üzenetére
Eseteleg egy motorpoti
-
Szirty
őstag
válasz
ratkaics
#8342
üzenetére
Szia!
"Ehhez fontos, hogy a cél PLC is ugyan abban a projektbe legyen mint, ami forrás?"
Nem.
Fontos viszont hogy a PUT-ot használó CPU projectnél a NetPro-ban fel legyen véve a másik partner (hiszen enélkül az SFB-nek meg sem tudod mondani kivel akarsz kommunikálni).
Továbbá fontos hogy a PUT-ot használó CPU-ra rá is töltsd a NetPro beállításokat (download)! -
-
Szirty
őstag
válasz
Tomika86
#8292
üzenetére
Nem tudlak követni. Először a háttérszínnel volt a baj. Nem említettél nyugtázó gombbal kapcsolatos problémát és ilyen gombot a kérdéshez mellékelt képeiden sem látok.
"nem tudtam a Line típussal megoldani, hogy a sor végén lévő nyugtázó gomb feljebb legyen "
A Line stílusú alarm view-ben nem lehet ack button.
Használj külön gombot a nyugtázáshoz aminek beállítod a "Keyboard operation of screen objects / Alarm view acknowledge alarm" funkciót.
Azt már oda teszed ahova akarod (ahol nincs takarásban). -
Szirty
őstag
válasz
Tomika86
#8283
üzenetére
Kicsit körülményesen, de megoldható.
A csúnyább megoldás az, ha ráteszel egy gomb méretű és háttér színű téglalapot aminek a láthatóságát a másik bittel vezérled. A téglalappal így eltakarod a gombot.
A gond ezzel az lehet, hogy ha billentyűzetet csatlakoztatnak a panelhez és az eltakart gombra helyezik a fókuszt, akkor aktiválni lehet Enterrel.
Ez ellen lehet védekezni azzal, hogy a téglalapot megjelenítő bit egyben letiltja a gombot (Animation/Enable object)Esetleg az is megoldás lehet neked hogy nem tünteted el a gommbot, csak letiltod (hatástalan lesz) ezzel az Animation/Enable object lehetőséggel. Esetleg Apperance megfelelő használatával ki is szürkítheted hogy látszódjon hogy tiltva van.
A másik lehetőség hogy írsz rá egy scriptet.
Létrehozol egy boolean belső változót (internal tag), a gomb láthatóságát beállítod erre.
A scriptet function-ra állítod, adsz neki két paramétert, a scriptben megírod a logikai összefüggést az eredményt a belső változóba teszed.
A két Tag-nek amivel a gombot akarod eltüntetni pedig a change value eventjéhez hozzárendeled a scriptet.
Ne felejtsd el ennek a két tag-nek az adatgyűjtését folytonosra állítani (Acquistion mode = Cyclic continuous)! -
Szirty
őstag
válasz
Tomika86
#8281
üzenetére
Szia!
"DB értéke ha 0 akkor nem történik semmi, ha NEM 0 akkor meghívódik az FC, de csak akkor ha M13.0 FALSE"
Igen. Ez van a kódban.
A CALL FC62 csak akkor fut, ha DB15.DBW15 nem nulla ÉS M13.0=FALSE.
Minden más esetben ugrik és elkerüli a az FC62 hívását.
Nem tudom mi a szerepe az M13.0 bitnek és a DB15.DBW15 értékének, én csak azt látom amit ide beírtál.
Mellesleg a DB15.DBW15 tartalmát nullázza ha az nem nulla.
O helyett A is lehetne. Mivel az /FC status bit értéke itt 1, nem hajt végre sem ÉS sem VAGY műveletet. -
Szirty
őstag
válasz
Tomika86
#8278
üzenetére
Szia!
Az összehasonlítás szerint ugrik M001-re ha DB15.DBW15 tartalma nulla. Ha nem nulla akkor nem ugrik, megy tovább.
"M13. 0 miért O, miértnem A? "
Miért nem A? Ezt a kérdést nem értem.
"Elötte hol íródik az RLO?"
Itt: O M13.0
Mivel az O előtti utasítás, ami a status word /FC (first contact) bitjét 1-be rakja az a ==I összehasonlítás, az O M13.0 nem hajt végre OR műveletet semmivel, egyszerűen az RLO-ba helyezi az M13.0 értékét. -
Szirty
őstag
válasz
Tomika86
#8138
üzenetére
Fontos, hogy az idő BCD formátumban kell hogy legyen!!
No meg van egy gyakoriság (acquistion cycle) ami alapból 1 perc, tehát csak percenként szinkronizál, nem azonnal.
Ha van a projectetben olyan alarm view ami system message-re van állítva, akkor azt nézd meg. Igen hasznos dolog amúgy egy ilyen ablak, nekem sokszor segített már. Ide írja az OP ha valami kínja van, -
Szirty
őstag
válasz
crucified
#8114
üzenetére
Prop. szelepnek két elterjedt kivitele van elektromos szempontból (legalábbis ipari területen).
Az egyiknél a szeleptestben csak a tekercs van. Ehhez szükség van egy külön teljesítmény elektronikára ami PWM-es áramgenerátoros szabályzással intézi a tekercset rendszerint valamilyen analóg jellel arányosan.
A másik kivitelnél maga az elektronika is be van építve a szeleptestbe vagy fejbe. Ennek tápfeszültség kell meg analóg jel, esetleg ad hibajelet, vagy lehet analóg visszajelzése is. -
Szirty
őstag
válasz
Tomika86
#7978
üzenetére
Szia!
Igen!
Így kell csinálni. Fogadd meg ZetorGumi tanácsát.
Illetve lehet még úgy is vizsgálni (ha nem HW megszakítással csinálod, hanem szoftveresen) hogy azt figyeled hogy nagyobb vagy egyenlő (illetve kisebb vagy egyenlő csökkenő irány esetén).
Persze ha az encoder felbontása kicsi a forgás meg lassú, akkor lehet egyenlőségre vizsgálni de nagy felbontás és vagy gyors mozgás esetén ez szívás.
Szervóhajtások is tartományt vizsgálnak (ami állítható, de sosem egyenlőséget néznek).A HW-es megszakításos figyeléssel meg az a helyzet hogy kapsz egy jelet amikor a hajtás ott volt.
De hogy most is ott van arra nincs garancia -
Szirty
őstag
válasz
crucified
#7968
üzenetére
Szia!
Az ilyesminek semmilyen problémát nem szabadna okoznia ha megfelelően van kivitelezve.
A 24V DC bemeneteknek is megvan a specifikációja hogy pl. -30V-tól +5V-ig logikai 0 szint, +13-tól +30V-ig logikai 1 szint.
Abszolút nem érdekli a bemeneti modult hogy a bemenetre nem ugyanaz a tápegység adja a feszültséget mint amelyik egyébként energiával látja el (főleg hogy még galvanikusan le is van választva).Nálunk is van olyan megoldás ahol egy szekrényben négy darab 24V-os tápegység van.
Sőt kifejezetten előnyös ha a PLC modulok tápellátását nem ugyanaz a tápegység hajtja meg mint amelyik azoknak a szenzoroknak ad tápot amelyek a bemenetekre visszaküldik a feszültséget (ha jön a "ménkű" akkor legfeljebb csak a szenzorok és a bemenet repül, az egész rendszer nem). -
Szirty
őstag
válasz
Marci0607
#7956
üzenetére
Jó lenne ha leírnád milyen kábellel (interfésszel) próbálkozol mert az hogy "MPI kábel" elképesztően kevés infó. (Külön kérték hogy írd le pontosan).
Az is lehet hogy nem a 2-es címen van a CPU vagy nem 187.5 kbps-re van beállítva az adatsebesség az MPI porton.
Milyen programot használsz? Ha Simatic managert (klasszikus Step7) akkor próbálkozhatsz a "Display accessible nodes" menüponttal ami felderíti a hozzáférhető eszközöket.
Van-e valamilyen eszköz csatlakoztatva ahhoz a porthoz vagy csak a PC?
Hogyan van pontosan beálítva a PG/PC interface a gépeden? -
Szirty
őstag
válasz
ratkaics
#7941
üzenetére
Szia!
Azt javaslom a kWh számlálását (halmozását) semmiképpen se real típusú változóval csináld, hanem fix pontos ábrázolással.
A lebegőpontos szám (real) ugyanis annál pontatlanabb lesz minél nagyobb az érték. És mivel a végtelenségig akarod halmozni, az érték garantáltan nagy lesz egy idő után. A halmozandó érték amiket hozzáadogatsz pedig kicsi lesz.
Bizonyos idő után nem fog tovább nőni a halmozott érték amikor a halmozandó kisebb lesz mint a halmozott érték pontossága.
Akkor sem ha a közelében sem jársz az ábrázolási tartomány végének. -
Szirty
őstag
válasz
Tomika86
#7916
üzenetére
Nem kell enkóder a szalagra, mert nincs szükséged arra az információra hogy hol vannak az üvegek a tárcsa és a kilökő előtt.
Csak két információ kell. Hogy hány darab üveg van ott és sorrendben (nem fizikai pozíció szerint) melyik milyen tulajdonsággal bír (van kalapja/nincs kalapja.A Shift, azaz bitenkénti léptetés nem lesz jó, mert azzal az üres pozíciót is lépteted, amire itt nincs szükség.
Én másolással léptetném, ahogy leírtam.
Az "üvegek" tehát mindig a puffer alján gyűlnek össze az érkezés sorrendjében. Nincs közöttük üres bejegyzés.
-
Szirty
őstag
válasz
Tomika86
#7912
üzenetére
Szia!
Ne haragudj, elsiklottam a linked fölött. Pont olyan rajzot követeltem amit már megcsináltál!
"FIFO, erről olvasgattam de úgy konkrétan nem értem hogy működik."
Nem bonyolult és ilyen feladatra elég hatékony. Leírni sajnos kacifántosabb mint megcsinálni.
Képzelj el egy olyan tárolót (puffert) amiben több üveg tulajdonságait tudod tárolni (amilyen tulajdonságokat a tárcsán is nyilvántartasz).
A tárolónak van egy bemenete meg egy kimenete.
A bemenetére beírod az üveg adatait amikor elhagyja a tárcsát (az ábrádon "jelenleg" szöveggel jelölt pozíció) mivel a tárcsán követed a pozíciók (üveg) állapotát, ez nyilván nem probléma.
A bemenetre írt adat a tárolóban "leesik" az aljára (pl. másolással az utolsó szabad címre) A legutolsó cím az amit majd a kimenetre küldesz kiolvasáskor).
Amikor a "kilökő dugattyú" pozíciójába üveg érkezik (egy szenzorral triggereled) akkor kiolvasod ebből a tárolóból annak legalján (utolsó címén) lévő termék adatot és törlöd az utolsó címen lévő adatot, minek következtében a benne lévő többi adatot is egyel lejjebb lépteted.
A kiolvasott adat fogja megmondani a dugattyúhoz érkező üveg tulajdonságait, ki kell lökni vagy nem.
Lényeges dolog, hogy a tároló (mérete) legalább annyi elemű legyen amennyi üveg maximum elfér a tárcsa és a kilökő között. lehet 1-2 elem ráhagyással számolni esetleg.A hibakezeléssel kapcsolatban 3 dolgot kell figyelembe venni. Ha a puffer megtelik és a tárcsa felől újabb trigger jön.
vagy ha a tároló üres, de a kilökő felől mégis újabb trigger jön.
Illetve érdemes egy tároló teljes ürítés funkciót végrehajtani ha a szállító szalag minimum annyi ideig üzemel amennyi idő kell az üvegnek a tárcsa és a kilökő közötti út megtételéhez és a szalag üzemel. Ezt az időt érdemes legalább kétszeres ráhagyással meghatározni.Természetesen az adatok pufferben történő másolgatása helyett alkalmazható a mutatók mozgatása is (hol a teteje és hol a vége). Kinek melyiket az egyszerűbb programozni.
Én így oldanám meg...
-
Szirty
őstag
válasz
Tomika86
#7910
üzenetére
Szia!
"Ha a kupakellenőrzés utáni pozicióban van üveg és kupakhiány akkor megáll a gép."
Van értelme a kupakkal törődni ha nincs üveg?
Gondolom hogy ha nincs üveg, a semmin nem lehet kupakAbból amit leírtál arra gondolok, hogy a tárcsa után,a szalagon a tárcsától bizonyos távolságban akarod kezelni az üvegeket (ahol már nincsenek konkrét üveg pozíciók) mint a tárcsán.
Egy hevenyészett de lényegre törő rajz (akár kézzel rajzolt) sokat segíthet a feladat megértésében (számunkra, mert te nyilván tudod miről van szó).
De ha jól sejtem, akkor egy FIFO buffer a megoldás itt.
-
Szirty
őstag
válasz
crucified
#7898
üzenetére
Szia!
Annyi a különbség amennyi a LAD és az STL között.
A LAD/STL választása elsősorban feladat függő. Adatok kezelése, ide-oda rakosgatása hatékonyabb (és ha nincs nagyon szétcsúszva a kód) akkor átláthatóbb, mert Ilyen feladatot LAD-ban megírva sokkal hosszabb és átláthatatlanabb megoldás születik.
A szokás annyiban játszik szerepet hogy ki mennyire gyakorlott az egyik vagy másik nyelvben.
Aki szinte csak LAD-ban dolgozik annak a LAD lesz átláthatóbb és könnyebb, aki mindent STL-ben ír annak meg az STL természetesen.Az én véleményem az, hogy az optimális valahol a kettő között van. A hibakezelő blokkokban jellemzően adatokkal kell foglalkozni, kevesebbet tisztán logikai feltételekkel. Ezért én ott az STL-t választom általában.
-
Szirty
őstag
"a cif 01-mögé kell egy aten rs232-usb átalakító és menni fog."
Lehet hogy jó tipp az Aten ide, nem tudom. DE!!!
A saját véleményem és tapasztalataim alapján az Aten UC232 tervezőjét, gyártóját, forgalmazóját, anyját, összes felmenőjét anticsókoltatom!
Az ellenségemnek se kívánok Aten UC232 USB-RS232 átalakítót!Elnézést az elégedett Aten felhasználóktól, de tűzzel-vassal üldözzétek ha ilyet láttok ássátok el a kertben , öntsetek rá betont, rakjatok fölé máglyát, és kilométeres körben kerüljétek a helyet is ahol ez történt!
Nem akarok csúnyábbat írni, pedig TUDNÉK!Használjatok FTDI chipsetes átalakítót én azt javaslom...
-
#7867
Szirty
őstag
Squirrel97
#7866
Szirty
őstag
válasz
Squirrel97
#7866
üzenetére
Szevasz!
"Van egy számlálóm csak szimulációban törlődik."
Be kell kapcsolni a számláló paramétereinél a "Retentivity" kapcsolót!
Akkor meg fogja őrizni az állapotát.
Ezt szimulátorban is le lehet ellenőrizni, de lényeges hogy ha ellenőrzöd ne azt csináld hogy beléptetsz valamennyit a számlálóba majd leállítod a szimulátort és újraindítod a szimulátort!
Ilyenkor ugyanis mindenképp törlődik mivel a Logosoft comfort nem menti el a szimulációból való kilépéskor a szimulált Logo belső állapotait.
Viszont van a szimulátorban egy "Power" gomb amivel szimulálhatod a Logo ki és bekapcsolását."A gombok között meg csak a nyilakat találom."
Csak a nyilakat tudod programban használni. Az OK és ESC gombok használatára nincs lehetőség.
-
#7865
Szirty
őstag
Squirrel97
#7864
Szirty
őstag
válasz
Squirrel97
#7864
üzenetére
Szia!
Mondjuk jó lett volna ha leírod a Logo pontos típusát (különösképp a típusjelzés végére: 0BAx).
Meg azt is leírhattad volna pontosan hogyan próbáltad meg azt ami nem működik. -
Szirty
őstag
Szia!
And nagyon precízen leírta mi is a különbség (köszönet érte)!
"aki az egyiket megtanulja, az vszinuleg a tobbivel is fog tudni dolgozni, csak meg kell szokni "
Pontosan! Nem csak a fejlesztői környezetek különbségével hanem összességében is.
Nincs is ezzel gond, ez így működik, de pont ezt a "megszokást" nem akarja a munkáltató. Ezért keres célirányosan az adott rendszert gyakorlat szinten ismerő programozókat. -
Szirty
őstag
Szia!
"Egy LD program pl miben masabb egy Omronra mint egy Siemensre? "
Több okból más.
Egyrészt a rendszerszintű különbségek miatt, másrészt a fejlesztői környezet alapvető különbségei miatt.
Emiatt azt gondolni hogy a létradiagram mindegyiknél ugyanaz, nagy melléfogás lenne...Nézd csak meg ezt:
http://szirty.taviroda.com/lang/index.htmlEgy felületes lista a szemléltetéshez. Mondj ebből kettőt ami ugyanaz.
-
Szirty
őstag
Szia!
Még mindig akad kérdés:
Ajtó nyitás kérő nyomógomb csak a zsilipkamrán kívül vannak és belül nincsenek?
Ha belül is vannak akkor az adott ajtónál lévők párhuzamosan mennek ugyanarra a bemenetre vagy másik bemenetre megy?Ha ajtó nyitás gombok CSAK kívül vannak:
Alaphelyzet van (nincs légöblítés, ajtók zárva). Ekkor megnyomja valaki az 1-es ajtó nyitás kérő gombját, nyithatóvá válik X ideig az 1-es ajtó. Delikvens X időn belül kinyitja, bemegy és becsukja maga után.
Elindul a légöblítés mialatt mindkét ajtó zárva és annak nyitása sem kérhető kívülről.
Letelik az öblítési idő, majd nyithatóvá válik a 2-es ajtó. mennyi ideig marad nyitható?
Mert ha állandóan, akkor mikor záródik a retesz? Ha majd megint megnyomják az 1-es ajtó gombját kintről?
Vagy akkor ha kinyitották a 2-es ajtót?
Ha a 2-es ajtó nyitásáig marad nyitható a 2-es ajtó, mi van akkor ha a bent lévő delikvens NEM a 2-es ajtón akar kimenni hanem az 1-es ajtón (tehát vissza akar menni arra az oldalra ahonnan bejött)? Nem tud mert bent nyitáskérés. vagy kimegy az 1-es ajtón és eljátssza visszafele az egész procedúrát?Ha viszont egy ideig tartja nyitható állapotban, akkor mi van ha az idő leteltéig a delikvens nem hagyja el a kamrát?
Nem tud kijönni csak vészgombbal ha belül nincs normál nyitáskérő gomb, vagy megvárja amíg jön valaki és kintről kinyitja neki!Másik kérdés: Az ajtónyitás egy retesz oldás ha jól értem és nem az ajtó fizikai nyitása...
-
Szirty
őstag
Szia!
Szerintem jobb lenne ha nem csöpögtetnéd az információt a feladattal kapcsolatban, hanem kerek perec leírnád mi a cél és ezzel amit leírtál milyen problémát kellene megoldani. Ne azt írd hogy gomb ezt meg azt csinálja, hanem hogy mi az egésznek a célja.
Most sokadik üzenetváltásra kiderült hogy valamiféle ajtózárról van szó.5ms-os időzítést akarsz.
El sem tudom képzelni miféle ajtózár lehet az aminek számít öt ezredmásodperc. -
Szirty
őstag
Szia lappy!
Nem pontos a leírás.
1. Mikor kezdjen el telni az időzítő? A gomb megnyomásakor, vagy felengedésekor?2. A gomb felengedéséig az időzítő nem tilt? Ha a gombot nyomva tartod addig világít amíg nyomod az időzítőtől függetlenül?
3. A gomb felengedése után az idő letelte előtt újra megnyomva a gombot az időzítő tiltja a lámpát?
4. Mi történjen ha a gombot megnyomod (lámpa bekapcsol) majd felengeded (lámpa kikapcsol) és az idő letelte előtt újra megnyomod (lámpa nem kapcsol be az időzítő tiltása miatt) de a gombot nyomva tartod és letelik közben az idő? Ilyenkor az idő leteltével kapcsoljon be újra és kezdjen újra telni az iső, vagy ne kapcsoljon be újra csak ha a gombot felengeded majd újra megnyomod?
5. Mivel akarod megoldani? PLC programmal? Ha igen, milyen PLC-vel?
A nyitott kérdések miatt az általad megadott leírásnak számtalan működésmód megfelel.
Mindenesetre itt van két megoldás, hogy valami konkrétum is legyen:
A network-ök sorrendje lényeges (ha megcseréled a kettőt, nem működik)!
A kettő egyformán működik, de a 2. spec. időtagot tartalmaz.
-
Szirty
őstag
Szia!
Szerintem inkább az az oka, hogy a P_LT, P_EQ, P_GT flag-et használja a programban az összes összehasonlító utasítás.(ellentétben pl. a Siemens-el, ahol nincs külön összehasonlítási eredményt jelző flag, az összehasonlítás az RLO-t állítja be (logikai eredmény).
A monitorozás (debugger funkció) meg nincs arra felkészítve hogy az éppen monitorozott összehasonlításhoz tartozó eredményt megkülönböztesse a többitől.Erről meg tudsz győződni ha akarsz:
Megkeresed a programban az utolsó összehasonlító utasítást és azt monitorozva a helyes állapotot látod, akkor ez lehet a helyzet... -
#7797
Szirty
őstag
Miertvansote
#7795
Szirty
őstag
válasz
Miertvansote
#7795
üzenetére
A belső DC kör feszültsége ami a hálózati fesz. egyenirányítása után kialakul a pufferkondenzátorokon.
Busznak (szerintem) azért hívják, mert ezt a DC feszültséget sokszor kivezetik a készülék kapcsaira.
Több készülék esetén ezeket (megfelelő védelemmel) párhuzamosan lehet kapcsolni. Ennek célja a terhelés megosztás és az hogy az egyik motor által termelt energiát egy másik felhasználhassa (ne kelljen fékező ellenállásokkal elfűteni). -
Szirty
őstag
válasz
Tomika86
#7766
üzenetére
"- Keresztreferenciánál mi a regenerate és az update közti különbség."
Az update csak a változásokkal foglalkozik, a regenerate meg felépíti újra a teljes táblát (tovább tart, főleg ha nagy a program, sok a blokk)
"akkor a legelső inicializálási értékre áll be."
Azért van, mert egy DB-ben lévő változónak offline állapotban van egy aktuális értéke is, amit deklarációs nézetben nem látsz.
Adat nézetben azonban igen. (View menü, Data view pont, vagy Ctrl-4).
Az initial value értéket akkor veszi fel amikor a változót létrehozod. Ilyenkor az initial value beleíródik az actual value-ba.
Amikor a DB-t a PLC-re töltöd, akkor a PLC-be az actual value értékek kerülnek!
Ha időközben az actual value módosult az offline blokkban (pl. mert a PLC átírta és te meg visszatöltötted az offline projectbe) akkor az új érték kerül vissza a PLC-be ha megint rátöltöd.Az actual value az offline blokkban is módosítható, de ahhoz adat nézetbe kell átváltanod.
-
Szirty
őstag
válasz
Tomika86
#7761
üzenetére
Szia!
Be is írhatod, de ahogy spkkill írta változón jobb katt is működik ha azt akarod megnézni hogy egyott cím hol szerepel még (vagy Ctr-Alt-Q én ezt használom, gyorsabb).
Beírhatsz nem teljes DB címet is a go to location ablakba.
Pl. ha azt írod be hogy DBX6.0 akkor felhozza az összes olyan DB-t amelyiket a program ezen a címen szólítja meg.
De vigyázni kell, mert mivel ez a keresztreferencia szerint keres, az indirekt, vagy a nem teljes DB címmel címzett változót nem fogja megtalálni (mivel ezek konkrét címe futás közben derül ki).A teljesebb kép kedvéért olvasd el ezt a hozzászólást is!
Továbbá a keresett címeket táblázat formájában is böngészheted a keresztref. tábla megjelenítésével megfelelő filterek beállításával (a kattintás onnan is a hivatkozáshoz repít).
-
Szirty
őstag
válasz
byte-by
#7742
üzenetére
"nem kétséges a siemens szereti a pénzt"
A Wago is szereti. Most kértünk árajánlatot profibus DP I/O eszközökre. Furcsa mód alap esetben a Siemens bizonyult olcsóbbnak.
De a pénzt szereti a Keyence is, nézd csak mi pénzt kérnek egy hatos anyáért!
Vagy vehetjük a Fanuc-ot is.
A Sew-ről, Danfoss-ról már ne is beszéljünk.
Drága dolgok ezek... -
Szirty
őstag
válasz
Tomika86
#7734
üzenetére
Szia!
"Honnét tudom hogy így nem jó a normalizálás a faktor és az offset értéke"
Ha nem használod a normalizálást (vagyis PVPER_ON bemenetnek 0 értéket adsz akkor tökéletesen mindegy milyen értéket adsz PV_FAC és PV_OFS paraméternek, mert olyankor nincs semmi hatása.
A normalizálásnak egyetlen, de annál fontosabb értelme van: Az, hogy a beállított és a mért értéked azonos dimenzióban legyen!!
Nyilván ha hőmérsékletet mérsz, akkor az alapjel (SP_INT) célszerűen celsius.
A mért értéket (PV) meg azért kell skálázni, mert ha a hőmérsékletet egy analóg bemenettel méred, ami mondjuk egy 0-10V-os jel, akkor neked NEM celsius fog bejönni a periféria szóra, hanem egy 0...27648 tartományba eső érték, ami arányos a hőmérséklettel, a végérték pedig a méréshatárnak fog megfelelni.
Pl. ha a méréstartományod 0...50 C fok, és 25 fokot mérsz, akkor 13824-et fogsz kapni.
Ha ezt nyeresen odaküldöd a PV_IN-re, az alapjelhez meg beállítasz 25 C fokot, akkor a PID azonnal elkezdi tekerni a kimenetet csutkára, mert 13824-et lát és 25 kéne. Valójában meg a kettő azonos, csak nincs egy dimenzióban.
De ha mondjuk Pt100-as bemenettel méred a hőmérsékletet, akkor meg nem 0...27648-at olvasol, hanem magát a hőmérsékletet tized C fokban (ez esetben a 25 fok 250-es értéket ad).
A skálázás tehát arra való hogy alkalmazni lehessen különböző jelforrásokhoz."Azt mivel tudom kiküszöbölni hogy az LMN érték ne ugráljon ennyire"
Fogalmam sincs hogy a P, I D tagok közül melyiket használod.
Ha az I tagot használod, akkor növeld az integrálási időt.
A P tagnál csökkentsd az erősítést (gain).
Ha használod a D tagot, azt egyelőre kapcsold ki, állítsd be anélkül a rendszert és ha ragaszkodsz a D taghoz azt csak utoljára aktiváld és nézd meg hogyan reagál a zavaró tényezőkre, majd aszerint állítsd be. -
Szirty
őstag
válasz
Tomika86
#7730
üzenetére
Szia!
Tehát PVPER_ON paraméter fixen 0 és te a PV_IN bemenetre egy 0...100 tartományú értéket küldesz, ahol 100 felel meg 50 C foknak?
Lehet így is, de akkor a setpointnak (SP_INT bemenet) is ugyanebbe a 0...100 tartományba kell tartoznia, Ilyenkor ide sem küldhetsz C fokot (0...50).
Tehát ebben az esetben neked kell "kívül" skálázni és a skálázott értékkel kell etetni a PID-et.A PV_PER arra jó, hogy egy az egyben oda küldheted a periféráról (analóg bemenetről) olvasott nyers értéket (az leggyakrabban 0...27648 tartományban van). Ilyenkor skálázza neked 0...100%-ra a PV_OFF és PV_FAC paraméterek segítségével.
Ilyenkor a PID LMN kimenetén is százalékot fogsz kapni.
De ha analóg kimenetre akarod küldeni a jelet, akkor használhatsz megint egy skálázást (CRP_OUT) és egy 0...27648 tartományú perifériára küldhető értéket kapsz.Ha az LMN kimenetet használod, akkor ezt a skálázást neked kell elvégezni külön.
-
Szirty
őstag
válasz
ratkaics
#7700
üzenetére
Szia!
Ha a Lock-olt FC alatt know-how protectiont értesz, akkor kilistázza.
A Go-to location a keresztreferencia tábla alapján dolgozik. A know-how blokkokban lévő hozzáférések is belekerülnek a keresztreferencia táblába.
Tehát ha egy védett FC írja pl. az M100.0 bitet akkor azt a go-to location megjeleníti, csak megnyitni nem engedi.Fontos azonban megjegyezni, hogy:
1.
A keresztreferencia táblázat kizárólag abszolút címekkel történő hivatkozásokat tartalmaz.
Az indirekt címzésekkel történő hozzáférések nincsenek benne. Nem is lehetnek, mivel azoknál a címék futás közben derülnek ki.2.
Ha nem teljes DB címeket használ a program, hanem rövid DB címeket te pedig teljes címet keresel, azt sem fogja megtalálni.
Írok egy példát.
= DB100.DBX6.0
Ez egy teljes abszolút cím, ez a keresztref táblába kerül, a go-to megtalálja.
OPN DB 100
= DBX6.0
Ugyanazt csinálja, de ez egy rövid hivatkozás, ha teljes címet keresel, akkor a go-to nem találja meg, de azzal lehet keresni rövid címet is (DBX6.0) de akkor minden más DB ezzel azonos bit címét felhozza a listába, tehát neked kell szelektálnod.3.
Egy címet írhat külső eszköz is. A külső eszköz (PL: HMI, másik PLC) által írt címek sem kerülnek a keresztref. táblába, nem is tudnának hiszen nem a Step7 hatáskörébe tartoznak. -
Szirty
őstag
válasz
ratkaics
#7665
üzenetére
Szia!
Van itt egy kis keveredés...
SD kártyáról írsz, de a PLC-ben MMC kártya van vagy MC kártya (a régiekben).MC:
A régebbi CPU-k egy részénél (amik a fenti MC-vel működnek) lehet copy RAM to ROM funkciót végrehajtani.
Ez valóban a memóriakártyára másolja a blokkokat amik akkor töltődnek vissza a működő projectbe amikor memória hiba van (ellenőrző összeg).
A copy RAM to ROM funkció CPU STOP módban hajtható végre, a PLC program ezért nem tudja megcsinálni, de sok értelme se lenne. -
Szirty
őstag
Szia!
Ha a munkáltató hajlandó időt adni neked akkor ez simán működhet. Persze kell néhány jóindulatú, segítőkész kolléga is.
Több éves tapasztalat automatizálásban komoly fegyvertény bármilyen PLC-t is ismersz.Neked eleinte kicsit nehéz lesz, mert szidni fogod a Siemens-et hogy Keyence-nél mennyivel jobban vagy másképp van ez vagy az megoldva. De ha ezt letudod akkor nem lesz ott gond!
-
#7642
Szirty
őstag
Rigor Mortis
#7641
Szirty
őstag
válasz
Rigor Mortis
#7641
üzenetére
Szia!
No még egy kis sztorizás aztán dugulok:
Nálunk az osztrákokra jellemző hogy rendkívül nagyvonalú olaszos lezserséggel lapátolnak össze programokat korábbi projektekből sok eurós óradíj fejében.
Pl. komplett robot kezelés van olyan újonnan telepített gyártósoron aminek a közelében sincs robot.
Van egy bugyijuk azt ráhúzzák mindenre.
Ezzel biztosan gyorsan lehet sokat keresne, de komoly aknák maradnak a helyi hibakereső balszerencséjére.
Rengeteg olyan programblokk ami fut, de nem csinál semmit mert pl. olyan IO címekre hivatkozik ami nincs is. Jópár blokk ami benne van a projectben de nem fut (nem hívja meg, kiszedték, nincs rá szükség)
Így sok vizet nem zavar a működés során de így a program tele van szeméttel és mondanom se kell hogy ha keresel valamit akkor a keresztreferencia szépen felhozza és eleinte úgy bevezet az erdőbe hogy öröm nézni.Egyszer programot kellett bővíteni ami miatt egy új DB blokkot hoztam létre, hogy ne pancsoljak a meglévő DB-kbe.
Később kiderült, hogy az egyik funkció nélküli de lefutó osztrák blokk egy rendszerhívással mindig megvizsgálta hogy XY DB létezik-e és ha nem létezik akkor nem törődött vele (beállított bizonyos szintén nem használt hibajelző biteket).
Nekem pont azt a számú DB-t sikerült létrehoznom az illető blokk meg azonnal lecsapott rá és telefirkálta.
Mindezt index regiszteres indirekt címzéssel hogy könnyebb legyen megtalálni -
#7640
Szirty
őstag
Rigor Mortis
#7639
Szirty
őstag
válasz
Rigor Mortis
#7639
üzenetére
Szia!
Az esetről az jutott eszembe, hogy a DB regiszterek használatával is csínján kell bánni (illetve ismerni kell a hmm.. "működésüket") különben giga nagy szívás tud lenni amikor rövid címeket használunk egy blokkban.
Pl.:OPN DB10
L DBW20
....
T DBW22Ha a pontozott részen van egy teljes című DB elérés ami másik DB-t szólít meg (Pl. L DB22.DBD40) az átírja a DB regisztert ezért az utolsó T DBW22 nem a DB10-be fogja írni az Accu1-et hanem a DB22-be!
-
#7591
Szirty
őstag
villamos bá
#7590
Szirty
őstag
válasz
villamos bá
#7590
üzenetére
Szia!
Márpedig szerintem másolgatni kell
Milyen PLC-re kellene a megoldás? -
Szirty
őstag
-
Szirty
őstag
válasz
byte-by
#7580
üzenetére
"az Ethernet egy fizikai réteg a protokoll a lényeg"
Nem. A lényeg az hogy determinisztikus legyen.
Akármilyen funkcióblokkot írsz akármilyen ellenőrzéssel, ha TCP alapú kommunikációval pl. megnő a pinged bármilyen okból (pl. Pistike torrentezni kezd) akkor így járás, nem lesz adatod és pont.
Persze információd az lesz arról hogy nem lesz adatod, de adatod az nem lesz.Persze ez nem minden esetben kritikus, de úgy tűnik itt arról van szó.
-
-
#7557
Szirty
őstag
villamos bá
#7556
Szirty
őstag
válasz
villamos bá
#7556
üzenetére
A kérdésed pontosítást igényel.
A memória tartalma a leggyakrabban PLC ciklusonként is változik (tehát másodpercenként több százszor).
Persze nem a flash, de kikapcsoláskor a RAM-ot szépen beletapossa a flash memóriába.Mi a kérdés mögött rejlő cél?
-
Szirty
őstag
válasz
H.Bencike
#7552
üzenetére
Szia!
Némi infó itt:
Blokk hívás, változók és paraméter átadás
Az S7 PLC programozásaNéhány kérdésedre rövid válasz:
"az FC hívhat FB-t? Vagy fordítva?"
Igen, és fordítva is
"Programfutás szempontjából melyik előnyösebb?"
FB-t akkor érdemes használni ha a blokknak kell saját "nem felejtő" változó terület (ez egy DB blokkban valósul meg).
"A második, amikor lokális változókkal programozok akkor a programban használt számlálók/időzítőknek(C1-T1) lehet lokális változóterületet kijelölni?"
Itt nem tudom pontosan mire gondolsz.
A Timer és Counter utasításnak adhatsz át lokális változóban adatot és hajlandóak is abba adatot belerakni.
De maga a timer és counter mindig globális adatterületen van.
Ugyanakkor nagyon fontos (és sokan elkövetik azt a hibát hogy ezt rosszul értelmezik) a lokális változók (TEMP) minden adatot elfelejtenek ahogy a blokk lefutott.
Ezért ökölszabály, hogy egy blokkon belül ha TEMP változót használsz, akkor MINDIG értéket kell adni mielőtt a tartalmát felhasználod!
Ha tehát mondjuk az FC100-ban a #Value változóba beírsz egy értéket, majd hagyod lefutni a blokkot, akkor legközelebbi ciklusban a #Value változó memóriaszemetet fog tartalmazni.
Illetve meg is maradhat benne az érték, ha a többi blokk nem bántja a saját lokális változó területét (TEMP).
A dolog magyarázata az, hogy az összes blokk ugyanazt a stack memóriaterültet használja a saját TEMP változóinak a tárolására."Illetve a merkerek lokális vagy globális változónak minősülnek?"
Természetesen globális. Ha az egyik blokkban mondjuk bekapcsolod az M10.6-os merker bitet, a többi blokkon belül is azt tapasztalod hogy be van kapcsolva.
-
Szirty
őstag
válasz
molntomi
#7545
üzenetére
Szia!
Örülök hogy sikerült!
"...itt az MPI/DP egybe van."
Azért van egyben, mert az interfész tudja az MPI-t és a profibus DP-t i. De egyszerre csak az egyiket (amelyiket beállítod neki).
Ugyanígy (és ugyanezért) pl. az S7-300 CPU 315-2 DP PLC-n is a bal oldali interfész tud MPI-t és DP-t is. De ha DP-re van beállítva akkor azon MPI kommunikáció nem fog menni és viszont (már eleve eltérő adatsebesség az alapértelmezés a kettőnél). -
Szirty
őstag
válasz
molntomi
#7542
üzenetére
Sajnálom, azt hiszem nem tudok segíteni.
Vagy MPI, vagy DP amellett hogy egy interfész tudja ezt is meg azt is, beállítás kérdése hogy vagy csak MPI vagy csak DP. De utána szigorúan csak az egyik. Esetleg én értek félre valamit...
A képet sajnos nem tudom értelmezni (félre ne érts, ez csak annyit tesz hogy nem tudom mit ábrázol). -
Szirty
őstag
válasz
molntomi
#7540
üzenetére
Nincs esélyed hogy kapcsolatba kerülj a HMI-vel ha az profibuszon van te meg MPI-n próbálkozol (nem csak beállítást tekintve, hanem fizikailag IS).
"Köszönöm a választ, de mint írtam,"
Nem írtál arról hogy mi mivel hogyan van összekötve.
Annyit lehet látni, hogy profibus DP profil van beállítva, ennek ellenére MPI kábelt próbálsz és MPI van a HMI-n beállítva. -
Szirty
őstag
válasz
Tomika86
#7531
üzenetére
Szia!
Működhet.
A buktató az hogy lépcsőzetes ingadozás lesz a nyomás értékben. Hogy ez gond vagy nem, azt a technológia dönti el.
A másik buktató hogy nehezebb lesz megírni a programot rá, mert figyelned kell hogy a határérték sávok ne kerüljenek egymással átfedésbe és ne legyen közöttük lefedetlen rés.
A beállítása is körülményes lesz a sok megadható érték miatt.Ha már úgy is fokozatmentes a beavatkozó jel és a mérés, ésszerűbb lenne talán egy arányos szabályzást csinálni (P).
Ehhez nem kell feltétlen a beépített PID-et használni, egyszerűen kivonod egymásból a beállított (tartani kívánt) nyomást és a mért nyomást, azt megszorzod egy értékkel (amit célszerű állíthatóvá tenni (gain)) az eredményt meg küldheted az analóg kimenetre. Legfeljebb kell még egy korlát hogy ne menjen 0 alá és 100 fölé. -
Szirty
őstag
válasz
Tomika86
#7508
üzenetére
Szia!
Alapvetően ez a szabályzó hőmérséklet szabályzásra való, így célszerűen C és F fokkal dolgozik ha hőmérő bemenetet használsz.De ez is állítható hogy melyik legyen.
A periféria konverzióra akkor van szükség ha a mérést távadó valósítja meg és nem hőmérő bemenet.Nem tudok most mélyebben belefolyni, de erről maga a Step7 is telepít doksit a gépre, amit alap esetben a start menüben megtalálsz.
A PDF neve: S7tmpcob.pdfa "Process Value Options (PVPER_ON)", "Process Value Format Conversion CRP_IN (PER_MODE)" valamint "Process Value Normalization PV_NORM (PF_FAC, PV_OFFS)" c. részeknél nézz szét.
-
Szirty
őstag
"Tehát az SP és a PV teljesen mindegy milyen mértékegység?"
Tulajdonképpen mindegy, de nagyon fontos hogy egyforma dimenziónak kell lenniük.
Célszerű azonban normalizálni az értékeket pl. %-ra mert beavatkozó értékként az eredeti mértékegység nem mindig értelmezhető.
Ez bármilyen mérés (nyomás, hőmérséklet, vagy bármi) esetén a méréstartomány százaléka lesz. Így már egyformán kezelhető és a PID beavatkozó értéke is % lesz.Ha a PID-nek közvetlenül egy analóg bemenet értékét adod meg (akár a PIW periféria címet) akkor a PV_PER és PVPER_ON segít a normalizálásban.
Ha folyamatos szabályzót használnál, akkor a kimeneten a beavatkozó jelet közvetlen analóg kimenet számára az LMN_PER kimeneten kapnád megfelelő paraméterezéssel.
-
Szirty
őstag
válasz
miclucky
#7488
üzenetére
"már megint ismeretlen vizekre tévedtem"
Ilyen ez a szekér.
Nekem az jut eszembe amikor egy Lenze vonalkód olvasóval hozott össze a sors. Konfigolni kellett.
Van rajta egy USB csatlakozás.
A hozzá adott szoftver USB drivere megvalósít egy virtuális soros porot a PC-n.
A virtuális soros portra ráül egy virtuális NIC (hálózati adapter) aminek lesz egy "légből kapott" IP címe (amit mint később kiderült nem érdemes piszkálni).
A virtuális COM porton működő virtuális hálózati adapteren keresztül egy TELNET kapcsolatot hoz létre a vonalkód olvasóval.
Tehát kvázi parancssoros szöveges parancsokkal lehet vezérelni.
De erre felépítettek egy grafikus szoftvert, ami egy Web szervert telepít, ami kiadja a Telnet parancsokat.
Így böngészőn keresztül konfigolható (már ha minden taktra összejön).Szerintem ilyen az amikor friss diplomás Linux kockák fejlesztenek multinak.
Új hozzászólás Aktív témák
- PROHARDVER! feedback: bugok, problémák, ötletek
- Mini-ITX
- RAM topik
- Autós topik látogatók beszélgetős, offolós topikja
- SzőkeKapitán: Világ vége túlélők topicja
- sziku69: Szólánc.
- Teljes verziós játékok letöltése ingyen
- Horgász topik
- Autós topik
- Samsung Galaxy Z Flip7 - kis fogyás is sokat számít
- További aktív témák...
- ÚJ Apple Macbook Air 15,3 M4 10C CPU/10C GPU/16GB/256GB - Ezüst mw1g3mg/a - 3 év gari - MAGYAR
- AM2 és AM"+ Ritka darabok!
- Új Google Pixel Buds Pro 2 bluetooth fülhallgató csak ki lett bontva 2026.09.04 ig gari
- Újszerű Apple Macbook Air 15,3" M3 8C CPU/10C GPU/16GB/256GB-(MC9E4MG/A) Ezüst -3 év gari
- i5-6400
- Game Pass Ultimate előfizetés azonnal, élettartam garanciával, problémamentesen! Immáron 8 éve!
- Egyedi ékszerdobozka
- Asus ZenBook Duo UX8406 -14" 3K OLED 120Hz Érintő - Ultra 7 155H - 16GB - 1TB - Win11- 3 év garancia
- ÁRCSÖKKENTÉS ASUS HD6870 videókártya
- Laptop felvásárlás , egy darab, több darab, új , használt ! Korrekt áron !