- Karácsonyfaként világíthat a Thermaltake új CPU-hűtője
- Az USA vizsgálja a RISC-V kínai terjedésének kockázatát
- Kicsit extrémre sikerült a Hyte belépője a készre szerelt vízhűtések világába
- Egészen nagy teljesítményspektrumon fedné le a mobil piacot az AMD
- Kihívás a középkategóriában: teszten a Radeon RX 7600 XT
- ThinkPad (NEM IdeaPad)
- iPad topik
- OLED TV topic
- Amlogic S905, S912 processzoros készülékek
- VR topik (Oculus Rift, stb.)
- Vezetékes FEJhallgatók
- HiFi műszaki szemmel - sztereó hangrendszerek
- NVIDIA GeForce RTX 4060 / 4070 S/Ti/TiS (AD104/103)
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Épített vízhűtés (nem kompakt) topic
Hirdetés
-
Karácsonyfaként világíthat a Thermaltake új CPU-hűtője
ph Az ASTRIA 600 ARGB ráadásul a hűtési teljesítmény szempontjából sem szégyenkezhet.
-
Toyota Corolla Touring Sport 2.0 teszt és az autóipar
lo Némi autóipari kitekintés után egy középkategóriás autót mutatok be, ami az észszerűség műhelyében készül.
-
Súlyos adatvédelmi botrányba kerülhet a ChatGPT az EU-ban
it Egyre nagyobb probléma az AI hallucinálása – most az osztrák adatvédelmi hatóság veheti elő a ChatGPT miatt az OpenAI-t, alapvetően a GDPR megsértése miatt.
Új hozzászólás Aktív témák
-
Szirty
őstag
válasz Mazsika #4215 üzenetére
Heló Mazsika!
Ez egy eddig zavartalanul működő berendezés volt, vagy új telepítésű, ami még nem működött hibátlanul?
Ha az előbbi, akkor szerintem a következőket lehet tenni:
- Diag buffer nézegetése, melyik eszköz okozza a hibát
- A busz lezárások ellenőrzése, le van-e zárva mindkét végpont és csaj az van-e lezárva.
- A kábelezés vizsgálata. Lekötni összes eszközt, méréseket végezni
- ET200 állomások cseréje (esetleg egymással,hogy a hiba átmegy-e másikra)
- Busz sebesség átmeneti felezése, hibajelenség figyelése
- Repeater ideiglenes beépítése, szegmentálás. hibajelenség figyelése
- Profibusz diagnosztikai készülékkel a a busz megfigyelése -
byte-by
tag
válasz Mazsika #4217 üzenetére
halo !
a profibus jó, ha minden jó.
de ha valami nem jó akkor kicsinálja az embert.csak tapasztalat , illetve eset megosztás:
a cégnél 4 kuka robot egységből álló raklapozó , görgősor, zsugorfóliázó , cim kéző , kirakó egység.
jó nagy terület elkerítve. minden profibuson.állandó hibaüzeneteket kaptunk , de hiába nézegettük a diag -ot nem volt egyértelmű.
vezetékek ellenörzése, csatlakozók átvizsgálása, stb.
kínunkban gondoltuk visszavágunk minden vezetéket 50 mm-rel. akkor szembesültünk vele. csak akkor látszott amikor jelentősen megtörtük a vezetékeket.szinte az összes ilyen volt.,németek rakták össze a sorokat, de ilyen trehány munkát ritkán látni.
át kellett vizsgálni a rendszerhez tartozó összes szekrényt és jól tettük, mert sok helyen teláltuk ilyen és ehhez hasonló problémákat.
az összes vezeték meg volt vágva. kicseréltük az összes csatlakozót és újra kötöttünk mindent.most már használható a rendszer.byte
[ Szerkesztve ]
-
Szirty
őstag
válasz Mazsika #4229 üzenetére
Helló!
"Vagy lehet külön NWbe írni!? Ha ENOt irja trueba akkor egy másik híváskor problémát okozhat nem?"
Ha egy FC hívással kapcsolatban tisztában van az ember azzal, hogy mit csinál az ENO, akkor annak megfelelően használja. Így nem érhet ilyen meglepetés.
Két lehetőség gyakori.
1. Az ENO mindig felveszi az EN állapotát. Azaz ha a kérdéses blokk lefut, akkor az ENO mindig TRUE állapotú lesz. Bár nem FC/FB, de pl. a MOVE utasítás ilyen. Szépen fel lehet őket fűzni egymás után, ha az első lefut, akkor mind le fog futni. Ilyen FC/FB blokkot akkor készítek, ha nincs olyan funkciója, ami boolean eredményt ad, vagy azt másképp akarom átadni a "környezetének".2. Az ENO valamilyen állapotot jelez. Ez a blokk funkciójától függ (mire való). Lehet vele jelezni sikeres/sikertelen (hiba keletkezett) lefutást jelezni, vagy ha a blokk feldolgozási eredménye két állapotú, akkor ezt az eredményt adhatja az ENO-n.
-
Szirty
őstag
válasz Mazsika #4260 üzenetére
Üdv Mazsika!
"A bec akkor lenne jo ha kulon nw-t csinal"
A kérdésben nem jelölte meg feltételként, hogy nem csinál külön network-öt! A BEC egyébként nem a network-ből lép ki, hanem a blokkból.
Szóval én csak (aljas módon) a kérdésre válaszoltam ami így szólt:
"...egy vagy több network (STL-ben amiben több művelet van és a vége egy Transfer) ne hajtódjon végre egy bit állapotának függvényében."
Ha előtte BEC van, akkor nem hajtódik végre a bit állapotától függően. Ez a válasz a kérdésre. A bit pedig az RLO (de ezt se kötötte ki a kérdésben) :-)
-
Szirty
őstag
válasz Mazsika #4276 üzenetére
Üdv!
És hogyan másolna egy ilyen aminek csak DB-t adod meg egymásba két teljesen eltérő struktúrájú, vagy ami még jobb(!!) eltérő méretű DB tartalmat? Oldja meg? No és ha nem úgy "oldja meg" ahogy te szeretnéd (mivel nem közlöd vele hogyan csinálja csak azt hogy mit, az utóbbit neki kellene kitalálni).
Vagy arra gondoltál, hogy lenne egy olyan másoló utasítás, ami arra való, hogy kimondottan CSAK azonos méretű blokkokat másol egymásba?
Ilyen blokkot lehet írni könnyen ha az kell. Csak a forrás és a cél DB címét adod meg neki."blkmov-val kicsit 'körülményes' több tíz db-nél! de akkor gépelés lesz ebből.."
Leraksz egy BLKMOV-ot és paraméterezed kb így:
Aztán ezt lemásolod tízszer és mindegyiknél átírod a DB számát és kész. Az miért több gépelés mint az, hogy olyan másoló blokkot hívsz aminek csak a DB számát kell megadni?
Vagy nem egyforma az összes DB mérte?Kifejtenéd a problémát részletesebben?
Nagyon nem mindegy mi van a DB-ben és az mekkora, de erről semmilyen infót nem közöltél. Így csak vaktában tudok tippeket adni, de azt utálom, mert fölösleges köröket futunk miatta napokig... -
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.
-
Shirchy
tag
válasz Mazsika #4406 üzenetére
Megvan mi a baj. A DB-ben töröltem egy REAL változót,majd a helyére INT tipusut akartam tenni. Ezután a művelet után a változó látszólag ott volt a DB-ben,de amikor hivatkozni akartam rá akkor piros színnel írta a ki a program a változó nevét és menteni sem tudtam mert érvénytelennek látta a változót.
Most újraírtam a db-t,de esetleg van más megoldás hasonló probléma esetén?
A DB változóit utólag már nem lehet módosítani csak az első megíráskor?"jobb adni,mint kapni" mondta a boxoló... :P
-
Szirty
őstag
válasz Mazsika #4505 üzenetére
Helló Mazsika!
Csökkenteni kell a program work memory igényét!
Hogy pontosan a te programod esetében ez mivel járna arról fogalmam sincs, mert nem láttam a programot. De van néhány hatékony módszer:- Csökkenteni kell a lokális változók számát (TEMP).
- Csökkenteni kell a blokk hívások egymásba ágyazásának mélységét -
Szirty
őstag
válasz Mazsika #4513 üzenetére
Üdv!
30 nem olyan sok, de nagyban függ a dolog a kódtól. Egyetlen egy blokk is el tudja használni az összes work memory-t!
Miben íródtak a blokkok pl az sem mindegy. Ha magas szintű nyelven (SCL GRAPH, HiGRaph) akkor a memóriahasználat drasztikusan nő.
Nálunk van olyan PLC, amiben 150 FB blokk van (LAD) és 171 DB blokk. Ez 330956 byte work memóriát igényel.
Meg olyan is, amiben 73 FB blokk van (SCL) 1188 DB és 1800078 byte work memóriát használ.
A CPU 315-ben (6ES7 315-2EH13-0AB0) 262144 byte work memória van.
Vegyetek 319-2 PN/DP-t. Abban ötször ennyi van: (1433600 byte) :-) -
-
Szirty
őstag
válasz Mazsika #4525 üzenetére
Üdv Mazsika!
"VB skript??? Itt már elvesztettem a fonalat... "
Miért? Nem találkoztál velük?
Itt egy példa file írására:'Aprító üzemidő kiírása TXT file-ba:
Dim CSV, CSVFile
'A mentést kezdeményező érték visszaírása nullába a mentés végén
SmartTags("WinCC_Adatcsere.CSVWRT")=0
Set CSV = CreateObject("Scripting.FileSystemObject")
'csv file megnyitása.
'Ha nem létezik létrehozza és első sorba beírja a fejléc szövegeit. Ha létezik, hozzáfűzi a végéhez az adatokat.
If (CSV.FileExists(Filename)) Then
Set CSVFile = CSV.OpenTextFile(Filename, 8, True)
Else
Set CSVFile = CSV.OpenTextFile(Filename, 8, True)
CSVFile.WriteLine(Chr(34)+"Dátum (év.hó.nap. ó:p:mp)"+Chr(34)+";"+Chr(34)+"Üzemidő kifele (ó:p)"+Chr(34)+";"+Chr(34)+"Üzemidő befele (ó:p)"+Chr(34)+";"+Chr(34)+"2. r. töltések száma"+Chr(34)+";"+Chr(34)+"2/2 sz. előre irányba állás számláló"+Chr(34)+";")
End If
'Adatok kiírása a file-ba:
CSVFile.Write(Now&";"&FormatDateTime(SmartTags("WinCC_Adatcsere.HKE"),4)&";"&FormatDateTime(SmartTags("WinCC_Adatcsere.HBE"),4)&";"&SmartTags("WinCC_Adatcsere.T18")&";")
CSVFile.Write(SmartTags("WinCC_Adatcsere.T20")&";")
CSVFile.WriteLine()
CSVFile.CloseEz amikor a "WinCC_Adatcsere.CSVWRT" változó (INT) értéke nullától eltérő lesz (ezt a PLC kapcsolja be naponta egyszer) kiírja egy file-ba egy sorba 4 változó értékét.
-
Szirty
őstag
válasz Mazsika #4527 üzenetére
Üdv Mazsika!
Nincs leírás. Próbáld ki!
Azt fontos tudni, hogy nem mindegyik panel tud scriptelni, ahogy CSV-be menteni sem. (Pl. KTP BASIC paneleket).
De PC RT tud.
A lényeg, hogy a scriptek a gyári funkciók közé kerülnek be és ugyanúgy eseményekkel lehet őket futtatni mint azokat.
A script funkcionalitása korlátozva van, nem lehet akármit csinálni benne (pl. win ablakot nyitni), de komplett help van erről. -
Szirty
őstag
válasz Mazsika #4533 üzenetére
Üdv!
Leraksz egy screenre egy Alarm view-et és beállítod így:
Aztán raksz egy gombot pl. a menübe ami megjeleníti ezt a screent. Azzal bármikor meg lehet nézni a rendszer üzeneteit. Ha így állítod be, akkor csak azok lesznek benne.
Ez igen hasznos főleg ha 5-6 PLC-vel is kapcsolatban van a HMI, láthatod melyikel nem sikerül kommunikálnia és melyikkel igen.
Fejlesztésnél is hasznos, mert ha valami baja van pl. TAG-ekkel, (pl. nem tud olvasni egy változót) vagy baja van egy scripttel (run time hiba), nem tud írni vagy olvasni file-t (pl. arhívokat, vagy receptet) akkor azt a panaszát is ide írja. -
Szirty
őstag
válasz Mazsika #4549 üzenetére
Üdv!
Ezeket nézd át:
− MSZ EN 201: 2001 Gumi és műanyagipari gépek. Fröccsöntő gépek. Biztonsági követelmények.
− MSZ EN 292-1-2: 1993 Gépek biztonsága. Alapfogalmak, kialakítás általános elvei. I–II. rész.
− MSZ EN 292-2: 1991/A1: 1997 Gépek biztonsága. Alapfogalmak.
− MSZ EN 294: 1994 Gépek biztonsága. Biztonsági távolságok.
− MSZ 187: 1980 Faipari termelő berendezések általános biztonságtechnikai követelményei.
− MSZ EN 860: 1998 Famegmunkáló gépek biztonsága. Vastagoló gyalugépek.
− MSZ EN 940-1998 Famegmunkáló gépek biztonsága kombinált famegmunkáló gépek.
− MSZ EN 953: 1999 Gépek biztonsága. Védőburkolatok. A rögzített és a nyitható védőburkolatok kialakításának és beépítésének általános követelményei.
− MSZ EN 954-1. 1999. Gépek biztonsága. Vezérlőrendszerek biztonságával összefüggő szerkezeti részek.
− MSZ EN 999: 2000 Gépek biztonsága. A biztonsági berendezések elrendezése.
− MSZ EN 1726-1: 2001 Targoncák biztonsága. Gépi hajtású targoncák.
− MSZ EN 12047-2: 2001 Daruk biztonsága.
− MSZ EN 60204-1:1995 Gépi berendezések biztonsága Gépek villamos szerkezetei.
− MSZ EN 1570:2001 Emelőasztalok biztonsági követelményei.
− MSZ EN 474 1.-7: 1999 Földmunkagépek biztonsága.
− MSZ 16457-1:1985 Alakítógépek biztonságtechnikai követelményei.
− MSZ EN 61310-1:1999 Gépi berendezések biztonsága. Jelzés, megjelölés és működtetés.
− MSZ EN 563:1997 Gépek biztonsága. Megérinthető felületek hőmérséklete.
− MSZ ISO 4254-1: 1992 Mezőgazdasági és erdészeti traktorok és gépek műszaki biztonsági esz-közei. Általános előírások.
− MSZ EN 1088: 1997 Gépek biztonsága. Védőburkolatokkal összekapcsolt reteszelő berendezé-sek. -
Dezsi82
tag
válasz Mazsika #4708 üzenetére
Üdv!
Egy rövid keresés után én ezt találtam
http://cache.automation.siemens.com/dnl/DUyNDEwOQAA_23330722_DL/23330722_Getting_LED_Status.pdf -
Dezsi82
tag
-
Szirty
őstag
válasz Mazsika #4776 üzenetére
Helló Mazsika!
"Jo lenne valami egyértelmű szabvány ezekre a dolgokra, csak nem találok sehol."
Azért nem találtál, mert egész egyszerűen legalább 20 éve ilyen nem létezik!
A szabvány messze-messze nem egyértelmű. Sokrétű, szerteágazó, ezer feltételtől függ melyik kitétele hogyan értelmezendő és alkalmazandó.Már-már olyan, mint a biblia: úgy értelmezed ahogy akarod. Egyre inkább bármit bele lehet magyarázni utólag Csak azt nem hogy jól lett megvalósítva valami).
-
moseras
tag
válasz Mazsika #4873 üzenetére
Üdv!
Érdekes amit írsz, mert azt írod, hogy már alig volt nyitva a beavatkozó, hiszen már csak tartani kellett, melegíteni már nem kellett. Aztán ugye jön a "sokk", ráeresztjük a hideg vízet, gyorsan elkezd hűlni, ilyenkor a PID-nek nagy sebességgel el kellene kezdeni nyitni (paraméterektől függően). Mért kezd el még zárni ??? És zárás után úgy is marad, nem kezd el később nyitni ? Ha ebben az állapotban hagyod, akkor zárva is marad ?
Imi.
-
byte-by
tag
válasz Mazsika #4880 üzenetére
halo !
nem hiszem, hogy a gyári blokk hibás.
"Ahogy neztem a fb parametereit a hibajel kimenet negativ ertek. Illetve azt hiszem a prop tag erteke is."
jó lenne tudni, hogy a prop gain pozitív vagy negatív konkrétan.
egyébként a hirtelen változás (pl. ez esetben a hidegvíz azonnali feltöltése) az úgynevezett "tűske", idézhet elő lengéseket, és a paraméterektől függően nyeri vissza a PID az irányítást, ha minden beállítás korrekt.
kis időt még kellett volna neki adni, hátha látsz valami változást, persze megértem, ha nem volt rá lehetőség.ha túl nagy az erősítés goromba beavatkozó jel keletkezik amit a rendszer ki akar egyenlíteni , ez akár a beavatkozó jel csökkenésével is járhat, bár nem hinném , hogy erről van szó.
használtam már negatív erősítést vákuumtartály abszolút nyomásának kiegyenlítésére, ami egy kopoltyút nyitogatott friss levegőnek.
jó lenne látni a blokkot ,monitorozva pláne.
byte
-
Szirty
őstag
válasz Mazsika #4883 üzenetére
Üdv Mazsika!
Nem írtad le konkrétan melyik PID szabályzót használod (van ám sok), de ha jól értem akkor a standard PID controllerek közül a FB41 “CONT_C”-t.
Erre fog vonatkozni a válaszom is. Ha nem ezt a PID controllert használod, akkor így járás, de utálok fölöslegesen irkálni.A szabályzó újraindítására a COM_RST (complete restart) paraméter szolgál. Ha ez TRUE értékű. Ez mindössze annyit csinál, hogy a belső változók és kimenő paraméterek értékét visszaállítja alapértékre.
Hogy melyiknek mi az alap értéke az kiderül az FB41 instance DB-jéből. Megnyitod és megnézed mi van a DB "Initial value" oszlopban. Erre áll be. A COM_RST nem élvezérelt, az init value mindaddig benne lesz a változókban amíg állapota TRUE. Természetesen amint FALSE lesz, az összes olyan változó aminek a programban értéket adsz azonnal felülíródik!!!Erre írok egy példát.
Ha a beállított értéked 20 (SP_INT) a mért értéked pedig 50 (PV_IN) és az integráló tag be van kapcsolva (P_SEL=TRUE) az erősítés 1 (GAIN) akkor lesz egy -30-as hibajeled és természetesen egy ezzel azonos beavatkozó értéked (LMN).
Ha most a COM_RST taposod (TRUE) akkor minden nulla lesz amíg ez TRUE, de abban a pillanatban ahogy felengeded (FALSE) minden azonnal visszaáll a fenti értékekre, mert kívülről (az FB41 paramétereivel) azonnal felülíródik. Tehát ez teljesen természetes, más nem is történhet, ezen nem kell csodálkozni!
Ami nem íródik felül azonnal az az integráló tag aktuális értéke, ami szintén 0 lesz egy COM_RST alatt. Hiszen üzem közben az LMN_I szépen ballag lefele a padlóig, vagy felfele a plafonig a hibajel és az integrálási idő által meghatározott mértékben, vagy beáll valahova. A COM_RST hatására nulláról újrakezdi ezt a "ballagást". Ez persze nagyon gyors is lehet rövid integrálási idő beállítása mellett vagy extrém hibajel esetén. Az integráló tag egyébként külön is alaphelyzetbe állítható az I_ITLVAL=0 és I_ITL_ON=TRUE állapottal.A legjobban úgy lehet tetten érni hogy a szabályzód miért akad ki, ha figyeled a hibajelet, és a 3 beavatkozó értéket (LMN_P. LMN_I ás LMN_D). Azonnal látni fogod melyik tag viszi el a beavatkozó értéket.
Egyébként PID élesztést lépésenként érdemes csinálni. ELőször kis GAIN (akár 0-val kezdve) és csak a P tag legyen bekapcsolva, az I lés D kikapcsolva!Van pár alapszabály a PID blokk paraméterezését és használatát illetően. Pl. hogy az értékeket normalizálni kell (vagy legalábbis célszerű) kézenfekvően %-ra.
Nagyon sok helyen elbukhat a dolog kezdve azzal, hogy pl. bekapcsolod a PVPER_ON-t, de a PV_IN-en eteted nem a PV_PER-en keresztül. EZ nagyon ostoba hiba szokott lenni.
Vagy a PV_PER-en eteted, de rosszul (vagy sehogy) van megadva a normalizáláshoz szükséges PV_FAC, PV_OFF értéke. Ha már a hibajel kiakad valamelyik végtelenbe (+ vagy -), akkor bizony itt van a baj!Ráadásul a PID blokkot nem, tudom hogyan hívtad meg, de ha P vagy D tagot is használod benne, akkor nagyon fontos hogy pontos időközönként legyen meghívva és ezt az időközt pontosan közölni kell vele a CYCLE paraméterben. ha ezek közül egyik feltétel sem teljesül, akkor a D és az I tag hülyeséget fog csinálni, mert a blokknak fogalma sem lesz arról mennyi idő telt el az előző lefutása óta.
[ Szerkesztve ]
-
Szirty
őstag
válasz Mazsika #4888 üzenetére
Helló!
Szerintem először csak a P tagot kapcsold be! A D-t és I-t ne!
"A blokkon a PV_IN-en keresztül etetem egyből a hőfokkal"
A PID kimenetén megjelenő értéket hogyan használod fel?
Ha ugyanis (mint írtad) nem normalizálod a hőmérsékletet a bemeneten (nyilván annak érdekében hogy a beállított értéket is hőmérsékletben lehessen megadni neki) akkor a beavatkozó érték is hőmérséklet lesz, ami nem biztos hogy megfelelő értéktartomány egy propszelep vezérléséhez... :-)[ Szerkesztve ]
-
Szirty
őstag
válasz Mazsika #4893 üzenetére
Helló Mazsika!
Az LMN_PER jó lehet, de az azt feltételezi, hogy az értékeket százalékra normalizáltad, mivel:
Kimenő érték = Beavatkozó érték * (27648 / 100)
számítást végzi.Ami miatt az eredmény akkor ad 100%-os analóg jelet, ha a beavatkozó értéked 100.
Ez akár jó is lehet, de nem árt átgondolni."Az I és D tagot időzítve kapcsoljam, vagy valamilyen feltételhez kellene kötni?"
Nem! Én arról beszélek, hogy a hibakeresés során kapcsold ki őket.
Egyébként szerintem nem szükséges őket kapcsolgatni, a szabályzás felfüggeszthető az INT_HOLD bemenettel is, ha használod az I tagot.
De ha azt akarod, hogy nulla legyen a beavatkozó érték bizonyos esetben, akkor ez is egy megoldás. -
zumi24
csendes tag
válasz Mazsika #4953 üzenetére
Szia Mazsika!
Az az igazság,hogy nem szívesen törölném a meglévő HW configot,mert nem tudom,hogy milyen rejtett beállítások lehetnek még.Már én is gondoltam erre a megoldásra ,ha nagyon muszáj lesz akkor ezt fogom csinálni,de örülnék,ha tudnátok valami megoldást a kártya csatoláshoz.