- Xiaomi 13 Pro - szerencsés szám
- Apple iPhone 16 Pro - rutinvizsga
- Xiaomi 13T és 13T Pro - nincs tétlenkedés
- Magisk
- Honor 400 Pro - gép a képben
- Milyen okostelefont vegyek?
- Xiaomi 15 - kicsi telefon nagy energiával
- Az Oppo Find X8 Ultra lett a legvékonyabb kameramobil
- Honor 200 - kétszázért pont jó lenne
- Apple Watch Ultra - első nekifutás
Új hozzászólás Aktív témák
-
byte-by
tag
válasz
Dezsi82
#6494
üzenetére
"De teljesen megértem azokat a cégeket, akik levédik a kódjaikat"
megérteni én is megértem őket, de atomot rájuk ....
egyébként saját tapasztalatom szerint valóban az olaszok és a nemetek a legelvetemültebbek
ebben a dologban, vagy inkább az olaszok másoljak a német szokást.előre bocsájtom , hogy én magam sem védem soha le a programot.
ezen a fórumon mar régebben volt ebben a témában nem is egy kör.
akkor jeleztem, hogy pl. van olyan megrendelőnk akinél elvárás a helyi karbantartok hozzáférése a programhoz, vagyis akármikor találkozhatunk belenyúlással. soha nem volt ebből konfrontációnk. a cél, hogy a gép vagy akar gépsor termeljen, ne álljon.
ha partnerek vagyunk , azt megháláljak. a próbaüzemek alatt úgyis kijön pár dolog, kisebb nagyobb módositás ezalatt általában szükséges.
szerintem nagyon merev álláspont az ha mindig a garanciális körülményekre hivatkozunk.
úgy gondolom, ennél jóval rugalmasabbnak kell lenni.pl. mi van akkor ha egy gépsort vagy gépet át kell alakítani vagy magasabb szinten automatizálni?
több példa volt erre, amikor nem a saját gépsorból kiszereltünk egy teljes állomást és mechanikai-elektromos bővitéssel , nagy arányú (hmi-beépités is) plc-program bővitéssel vittük vissza, és installáltuk.
ekkor a másik gyártó cég programját használtuk, bővítettük amit azért tehettünk meg,
mert ők is átadtak a teljes verziót.a mi gépeinket is molesztálják adott esetben, de nekem meg nem jutott eszembe ezert kötözködni.
sőt inkább megbeszéljük mit is szerettek volna, vagy mi volt a terv.
ez ugyanannál a távol-keleti partnerünknél jellemző, persze ott más a hozzá állas is.véleményem szerint a "hajnali kettőkor is , gari alatt " elv teljesen életszerűtlen, már beüzemelt, használatba vett gép eseten.
senki sem ül arra várva hátha felhívják a megrendelőtől , hogy valami problémájuk van.
24-48-72 órás beavatkozás létezik,akár szerződés szerint, de hajnali kettőkor hívogathat, felesleges.a plc-s tevékenység sokrétű, a perifériák száma rengeteg ( hmi-k, robotok, képalkotók, adatgyűjtők, mérőegységek, stb.) ezek adott esetben nem a meglévő rendszer része hanem hozzá építés, vagy fejlesztés. ezt természetesen más cég is csinálhatja.
itt a megrendelő felelőssége is felvetődik , hogy kivel dolgozik együtt.
van olyan partnerünk aki megválogatja, illetve van beszállítói specifikációja, ami szerint kell eljárni minden partnerének.
ha a partner nem hajlandó a program hozzáférhetőségét biztosítani, akkor azzal nem dolgozik.persze ez csak egy összetevő.más kérdés, hogy kész meglévő teljes rendszert akar-e megvenni egy cég.
ilyenre is volt példa,más cégnél ugyan, de pont egy olasz mosó berendezés esetében, ami egy óriási egység volt, több komponensel. nem volt választás, nem is jártak jól.
én magam jeleztem az olasz kollégáknak,(akik egyébként jó fejek voltak) hogy kell a program amit meg is ígértek.
azt nem értettem miért a központból kell küldeni majd később, és miért nem a laptopjukról, de persze a program soha nem ért oda.a program átadása vagy hozzáférhetővé tevése nem jelenti az arról való lemondást, véleményem szerint.
jogilag megegyezik pl. akár a windows jogállásával. tehát a gépeken licencként működik, de máshová is eladható a fejlesztő belátása szerint mivel az ő tulajdona, illetve saját fejlesztése, amivel szabadon rendelkezhet. -
Szirty
őstag
válasz
Dezsi82
#6493
üzenetére
Helló Dezsi82!
"Szerintem nincs semmi extrém abban amit leírtam"
Természetesen nincs. Nem is azért írtam ezt le, hanem ezért, hogy abba az irányba ne menjünk el a vitával. Vagyis szeretném megelőzni az ilyet, mert tudom hogy az szokott történni.
"Nem érdekel ki mit mond, nekem van igazam"
Alapvetően egyetértünk, nem kell mindent támadásnak venni, Csak "beszélgetünk"...
Sajnálom hogy így értetted.
Arra utaltam hogy tényekkel nem lehet vitatkozni. Attól teljesen függetlenül nem lehet hogy ki említette...""Szerintem hibakeresésre nem a PLC program nézegetése való, erre van a kijelző, stb. Ha hiba van a programban, akkor az garanciaidő alatt kiderül."
Azt nem feszegetném hogy mi mire való.
De teljesen egyértelmű számomra, hogy a PLC program hozzáférhetősége elképesztő mértékben meg tudja könnyíteni a hibakeresést.
Ezt nap mint nap tapasztalom. Egyedül lennék ezzel? Főleg ha távolról kell hibát keresni és a telefonon átadott információ nem elegendő, zavaros vagy nagyon félrevezető (sajnos szinte kivétel nélkül mind ilyen).
Sajnos napi szinten kell hibát keresni itt, és bizony olykor a programban monitorozzuk mi a helyzet. De ez itt viszonylag nagy gyár, nagy programokkal, nem tudom ez számít-e. Kisebb önálló célgépeknél viszonylag ritka valóban hogy a programot kellene nézegetni. Legfeljebb makacsabb hibáknál szükséges."Program nem fog tönkremenni, és van más lehetőség is a hibák megkeresésére."
Mindkettő igaz.
Ám a lehetőségek közül - amennyiben több is van - a jobbat kell választani. Sok esetben ez a program monitorozásával alátámasztott hibakeresés.Valóban nem megy tönkre a program. Vagy legalábbis nem változik meg magától.
De lássuk be: tökéletes program nincs.
Nálunk a mai napig (8 év után, sőt az egyik 12 éves vezérlésben is) futunk bele olyan hibákba ami eddig nem okozott problémát és csak most alakult ki az az együttállás amikor jelentkezik és gondot okoz.
Kijavítjuk és megy tovább az élet. -
Psanyi42
tag
válasz
Dezsi82
#6493
üzenetére
Szerintem hibakeresésre nem a PLC program nézegetése való, erre van a kijelző, stb. Ha hiba van a programban, akkor az garanciaidő alatt kiderül. Program nem fog tönkremenni, és van más lehetőség is a hibák megkeresésére.
Hát most a héten voltam megnézni egy PID-et. Annyi változás történt a rendszerben, hogy nagyobb folyadékáramot használnak, és máris ment a kukába az egész, mert a paraméterekkel nem lehet megoldani, hogy indításkor ne lője túl, akármit is állítok, akármilyen kicsire is veszem a tagokat mindig túllövi, mert kb 5-6 mp-es késés van a rendszerben. Szóval azt kellene csinálni, hogy PID nélkül felfuttatni a rendszert a kívánt érték közelébe, de ez nem lehetséges, mivel le van jelszavazva a program.
(A D tagra mindig 0-t ír, szóval szerintem azt csak dísznek rakták a kijelzőre, mert nem változtat semmin, szóval inkább csak PI) -
Szirty
őstag
válasz
Dezsi82
#6489
üzenetére
Szia!
Nyilván a gyártó meg akarja óvni magát attól, hogy mások által szerencsétlenül végzett beavatkozás miatt saját költségén garanciában javítsa ki a kreálmányát.
De elméleti szinten maradjunk a gyakorlatias ésszerűség és korrektség mezején, ne feszegessük a lehetőségek extremitásait, mert az minden szempontból nagyon távolra vezetne...Ennek jegyében:
- Garanciás gépet nem alakítunk át! Ha baj van vele, akkor a garanciát vállaló cég munkatársai térítésmentesen megoldják a problémát, erről szól a garancia. Ha a gép "mission critical", akkor fel lehet velük venni a kapcsolatot és konzultálni áthidaló megoldást lehet kidolgozni, de ilyen gép esetén szokták biztosítani a gyártó általi online elérést az azonnali problémamegoldás érdekében. Mindkét fél alapvető érdeke, hogy a gép működjön és termeljen!
Szerintem kell azért legalább egy szikrányi bizalom a megrendelő és a teljesítő cég között! Ha ez már kezdetben sincs meg, akkor nagyon rögös út vezethet a kölcsönös megelégedéshez...- Mi van amikor már nem garanciás? Az üzemeltető jobban jár ha megkapja a teljes forrást hogy igénye szerint felhasználja hibakeresésre, módosításra (a szerzői jogok megsértése nélkül természetesen).
Bárki bármit is állítson ez a korrekt megoldás!"Továbbá miért nem hallok senkit panaszkodni, hogy miért nem kapja meg a telefonján futó app, az autója vezérlőjében lévő program, a frekvenciaváltóban lévő program, a CNC gépe vezérlőjében futó program, a TIA portál, CX programmer, stb forráskódját."
Azokat nem akarja a felhasználó módosítani. A szakértelme és eszköze sincs meg hozzá, ahogy említetted.
Ezzel szemben egy gyártósor üzemeltetésében részt vevő szakemberek eszközei és tudása megvan ahhoz hogy a gép vezérlőprogramja segítségével hibát keressenek vagy azt szakszerűen módosítsák.
Az igény is megvan erre az üzemeltető részéről, mert egy gyártósor nem mosógép, nem frekvenciaváltó és és nem TIA portál, lássuk be.
Ha a frekvenciaváltó szoftver hibás kidobjuk a francba, rakunk be másikat ami jól működik, nem kezdünk el azon sírdogálni hogy jajj nincs meg a forrásprogram a FW-hez pedig úgy kijavítanám.Teljesen más szinten van a két dolog!
-
tibi-d
tag
válasz
Dezsi82
#6384
üzenetére
Szerintem az I/O-k állapotából lehet egy bináris számot generálni, és ezt küldeni át a hálózaton. Bármelyik bit megváltozik, a szám értéke is megváltozik. A számot a feldolgozás helyén lehet dekódolni. Ha ez egy PC, az neki gyerekjáték. Így ha két átvitel között megváltozik az átvitt adat, a dekódolás után lehet tudni mi történt.
-
Szirty
őstag
válasz
Dezsi82
#5345
üzenetére
Helló Dezsi82!
Sajnos amit javasoltál szerintem csak windows alapú paneleknél lehetséges, ezek közül egyik sem az.
Itt induláskor bekapcsolás közben nyomva tartott különböző bill. kombinációkkal annyit lehet tenni hogy teljes project törolése után transfer mód, vagy csak transfer mód, vagy DOS prompt.
Szerintem a transfer módból való kilépés pedig azonnal indítja a projectet, vagyis nincs runtime loader. -
-
#5260
norbert100
csendes tag
Dezsi82
#5256
-
Szirty
őstag
válasz
Dezsi82
#5246
üzenetére
Üdv Dezsi82!
Az nem oldható meg, hogy az összes esetben eltérő DP címe legyen minden bekerülhető eszköznek?
Akkor egy buszra a HW configban felpakolhatnád az összes lehetséges eszközt.A CPU megnézné melyik eszköz elérhető és az el nem érhető eszközöket deaktiválná az SFC 12 "D_ACT_DP" funkcióval.
-
Szirty
őstag
válasz
Dezsi82
#5119
üzenetére
Helló Dezsi82!
Most egy kicsit megsértődtél. :-)
Az élet nem könnyű!Van akinek biciklivel egyszerű kenyérért menni, van akinek autóval. Pedig az autóban sokkalta több alkatrész van, meg több mikroprocesszor is. Ez már csak ilyen. Az adott helyzet eldönti.
A jó megoldás általában valahol a végletek között van.Ki tudja melyik a jobb? 64 bitet felhasználni egy boolean változóhoz, vagy 1 bitet?
-
Szirty
őstag
válasz
Dezsi82
#5117
üzenetére
Üdv!
Nem tudom egyszerűbb-e adatküldéssel, hibakezeléssel, összehasonlítással foglalkozni mint egyszerűen figyelni egyetlen bit állapotát.
Én azért aggódnék, hogy mi is történik ha a relé fogja magát és belekapcsol az adás közepébe (mivel teljesen aszinkron módon kapcsolgat, erre elég nagy esély van). Akkor jön a krix-krax. Ami vagy "kisimul" a következő stop bit után (már ha sikerül beállítani egyáltalán hogy legyen stop bit) vagy nem.
Megtelik a vételi puffer, vagy épp nem ürül ki, jönnek a hibák...
Aztán lehet port újraindítgatással vacakolni, meg nagyobb szüneteket hagyni a küldések között, stb.Természetesen működhet így is, szó se róla, majd eldönti hogyan csinálja, nekem mégis olyan mint elefánt a porcelán boltban.
Az a mondás jut eszembe hogy: "Unatkozik? Vásároljon mosómedvét!" -
Szirty
őstag
válasz
Dezsi82
#4965
üzenetére
Helló Dezsi82!
Ez így sajnos nem működhet, mert:
- UDT változó csak DB-ben lehet
- Az address regiszter 4 byte-os, a DB-n belül lehet csak címezni vele, a DB számát a tartalma nem címzi)Tehát ha #Pultadat egy paraméterben átadott UDT változó és pl. a DB1-ben van valahol, majd csinálsz egy ilyet:
L P##Pultadat
LAR1
L 1
T B[AR1,P#0.0]Akkor az 1-et nem a DB1 #Pultadat változód első byte-jába fogja tölteni (hanem a V stack területre).
Az ok az, hogy szerintem az L P##Pultadat eredményeképpen az accu1-ben az a cím lesz, ahol megtalálod a #Pultadat változót. Valahogy így:
Ebből már össze tudsz rakni pár soros programot, ami megnyitja a DB-t és írja olvassa ahol kell.
-
DP_Joci
tag
válasz
Dezsi82
#4942
üzenetére
Valamikor ilyen Delphi-s dolgokkal foglalkoztam a régi szép időkben, talán prodave nevű drivert kellett hozzá használni, hogy profibuszon meg MPI-on kommunikáljon a PC a PLC-vel.
De már nem emlékszem ezekre a dolgokra.
Ha esetleg lenne feleslegben egy ilyen Delphi-s adatgyűjtögetős programocskád, amivel profineten keresztül lehetne naplózgatni, akkor szívesen lecsapnék rá
üdv.
J. -
DP_Joci
tag
válasz
Dezsi82
#4936
üzenetére
Sziasztok,
Ez az adatmentéses téma engem is érdekel(t).
S7-1200-ban gondolkodtam hasonlóban, mégpedig úgy, hogy fájlokat hoztam létre a memória kártyán. Majd aktiváltam a plc web serverét amit ip cím alapján böngészővel el lehet érni. Innen a fájlokat le lehet tölteni, törölni stb.
Tetszőleges webes felületet lehet létrehozni ha valaki nagyon unatkozik.
Ha jól emlékszem beavatkozásra is van lehetőség (mérés indítás stb), ja igen még monitorozni is lehet a változókat.
Már viszonylag régen foglalkoztam a témával azért ilyen homályos.
Dezsi82 az adatok olvasása a te esetedben a fejlesztő szoftveren keresztül történne?üdv.
J -
-
#4848
RochaShade
újonc
Dezsi82
#4847
RochaShade
újonc
válasz
Dezsi82
#4847
üzenetére
szia,
a példaprogram alapján abból amit küldtél (441.old) minden mozgáshoz pozícionálásához hasonló létradiagram lesz?
"beírod a megfelelő területre a célpozíciót" mi takar a megfelelő terület?
beállítottam a unit-ot a main rackban is és a cx motionban is. Jól sejtem hogy a cx motionban csak hozzá rendelek hajtásvezérlőket amiknek ott csak a beállításait tudom el végezni, ami akkor fog lenne kapcsolva a cx programmerhez ha össze is raknám? -
#4846
RochaShade
újonc
Dezsi82
#4831
RochaShade
újonc
válasz
Dezsi82
#4831
üzenetére
Szia,
köszönöm a segítséget először is, bár attól tartok nem nem minden egy értelmű számomra. Addig el jutottam hogy a Cx motion-ben ki választottam a hajtást, meg a PLC-t, valamint a cx programmerben is a unit setupban a main racknél be állítottam az NC271-et. De sajnos nem tudom hogyan lesznek a pontok meg határozva ahová mozgatom, és hogy ez a cx programmerben a plc programban hogyan fog ki nézni. There is no editable parameter defined by CPS. Ezt kapom a cx programmerben. -
byte-by
tag
válasz
Dezsi82
#4830
üzenetére
halo !
nos valóban, a cpi1-hez is hozzáadható a Main Rack mudulsorhoz az NC271.
elindítottam a sx-one-t és hozzáadtam.
de az is igaz, hogy fel kéne paraméterezni , kiosztani az általa használt memória tipusokat és területeket. csak elvi felépítésben egy ilyen konfiguráció ( plc-modul-vezérlő-motor) kissé nehézkes.
kíváncsi vagyok, hogy a hardverek nélkül a paraméterek rögzíthetőek -e , és működhet-e a dolog.
byte -
Dezsi82
tag
válasz
Dezsi82
#4830
üzenetére
Üdv!
Még annyit tennék hozzá, hogy a mozgatás NC271-gyel nagyon egyszerű, mert a megfelelő címekre bemozgatod a
-sebességet
-profilt
-célt
-start parancsot.
Visszajelez, amikor ott van. Nem sokkal nehezebb, mint egy munkahenger mozgatása. Macerásabb a hibakezelés leprogramozása, de azt jól meg szerintem a valós gépnél tudod megcsinálni -
#4826
RochaShade
újonc
Dezsi82
#4825
RochaShade
újonc
-
KB.Pifu
tag
válasz
Dezsi82
#4796
üzenetére
szia!
Ezen túl vagyunk, valóban ez a legfontosabb mégsem mondják el túl gyakran, főiskolán se! Szomorú de igaz,itt kell bepótolni.
De valóban olyan nagy gond az ,hogy szabadidőmben ilyennel is szeretnék foglalkozni? Végzettségem szerint mérnök vagyok (sajnos 0 km-es) egy kisebb cégnél akár elvárás is ez a fajta tudás, magyar cégeket ismerve pedig inkább számítok rá, hogy ezt is tudni kell, ha más nem azért, hogy a helyszíni beüzemeléskor a kedves vevőnek meg lehessen magyarázni miért kell a reset gomb a biztonsági relére. (meg amúgy is, tájékozottabb akarok lenni)
Úgy látom ez a téma nem idevaló, részemről jegelem. a kapott linket meg köszönöm az illetékesnek
-
byte-by
tag
válasz
Dezsi82
#4771
üzenetére
halo
így más a helyzet.
ez biztonsági kérdés amit elvileg és gyakorlatilag biztonsági relének kell lekezelnie nem a plc-nek , ami jelet kaphat a relétől.
ez egyben válasz a fénykapu megsértése utáni történésekre mivel a kétkörös biztonsági relét nyugtázni kell.
elvileg gépészetben 4-es kategóriájú biztonsági eszközöket kellene használni, de ettől sokan eltérnek.biztonsági esemény esetén több dolog történhet, ez függ attól, hogy pl. a kimenetek letíltódna vagy sem.
át kell gondolni.byte
-
#4770
Achilles83
csendes tag
Dezsi82
#4769
Achilles83
csendes tag
válasz
Dezsi82
#4769
üzenetére
Nálunk úgy működik, hogy amikor el kezd csukódni az ajtó és közben belenyúlsz a fénykapuba akkor teljesen visszanyitódik végállásig és úgy is marad ameddig újra nem kezdeményezel zárást.Természetesen ha a fényfüggöny átláthatósága végig meg van szakítva akkor el se indul a csukás.Nemrég volt egy olyan baleset nálunk, hogy az ajtó egyik fele teljesen becsukódott a másik meg megszorult félúton, na most a PLC program úgy volt megírva, hogy akármelyik ajtó fele bezáródik akkor ő úgy látja, hogy mind a két fele be van zárva és a fényfüggöny így már nem is működött, tehát ha az egyik fele bezáródott akkor már hiába nyúlkáltál a fénykapuba már nem nyílt vissza, és természetesen az illető el kezdte feszegetni a másik fél ajtót,(a fénykapuban) amikor egyszer csak megindult és levágta a hüvelykujj felső új percét.Az illetőt kirúgták mert nem zárta le az ajtót, nekünk meg át kellett írni az egész gyárban a PLC-t, hogy akkor is visszanyitódjon ha csak az egyik zár be.Csak azért írtam le, hogy azért vannak ilyen buktatók, erre is érdemes odafigyelni.
Összességében neked van igazad, ha egyszer belenyúltak akkor nyitódjon is vissza teljesen.
-
byte-by
tag
válasz
Dezsi82
#4767
üzenetére
halo!
ha valóban "veszélyes tér ", akkor persze , akárhogy nem lehet elhagyni.
de ha csak egy ajtó akkor nem olyan kritikus.azért kell tudni , hogy ez pl. robot tér, gyártó gép tere, vagy egyéb veszélyes munkaterület.
a 2006 / 42 / EC ( EK -nak is ismerik ) egy irányelv gyűjtemény szabványokhoz. ezen belűl is a B2 típusú szabványok a biztonsági berendezésekre vonatkozó leírások. a B1 típusúak inkább a körülményekre , környezetre koncentrálnak.
ha ez céges buli akkor kell lennie munkavédelmi megbízottnak és neki tudnia kell, de el lehet veszni a szabvány tengerben.Ha , mint írtam valóban veszélyes terület, akkor valóban nyugtázni kell, de méghozzá úgy, hogy belülről ne lehessen.hiszen a fénykaput befelé is átlépheted meg kifelé is.
ezért jók az FSU-k, amik területet fednek le, vagyis folyamatos a benttartozkodás amíg a hatótávjában vagy.de mindenképp a biztonsági berendezés által védett terület veszélyességi szintje határozza meg a teendőket. ha csak tényleg annyi, hogy egy ajtó ami ne csukodjon az illetőre, akkor mindegy , de akkor is az a jó ha az ajtó "visszavonul", majd folytatja. pl. ipari lift ajtó.
byte
-
plutokas
csendes tag
válasz
Dezsi82
#4733
üzenetére
Este próbálkozom még vele, de ha nem megy akkor készitek képeket.
Már csináltam a discrete alarm-ból 16db-ot, hogy bármi változásra megjelenjen egy hiba üzenet.
Egy meglévő ablakra dobtam fel az alarmot.A Step7-ben a DB-ben látni, hogy hiba esetén megjelenik a tartalom a hiba kezelő adatbázisban, tehát a probléma valahol HMI oldalon lehet majd.
-
Szirty
őstag
válasz
Dezsi82
#4731
üzenetére
Üdv!
Elvileg nincs szükség külön állítgatni az alarm trigger bitet tartalmazó word acquistion módját, mert akármire is van beállítva abban a pillanatban ahogy a discrete alarm listába berak belőle egy bitet, átállítja cyclic continuous-ra.
Persze utólag vissza lehet állítani másra, de amikor megint berak egy másik bitet, megint átállítja.
Ha azt is visszaállítja, akkor jön a fordítási Warning, miszerint:"Acquistion mode cyclic continuous requires for trigger tag"
-
KB.Pifu
tag
válasz
Dezsi82
#4722
üzenetére
szia!
örülök, hogy ezekre a különbségekre rávilágítottál, utána kell néznem egyesével mind, én inkább grafikai és logikai hasonlóságokra gondolok, ami egy átlag user-t segít a tájékozódásban, pl mindkettőnél paraméterátadás nagyban hasonlatos, tehát ha nem is tudja akkor sejti hogy hol lehet a válasz, ami pedig a legfontosabb, hogy az F1, itt segíti az embert.
Sokat gondolkodtam, hogy mitsubishi vagy omron legyen a következő, ez akkor eldőlt, amikor élőben kelett monitorozni a mitsubishi PLC-t és semmi súgó vagy hasonló támasz nem volt, lehet verziószám hiba, de akkor sem volt túl megnyerő, pl internet csatlakozás nélkül meg voltam lőve, amikor két merker bitet logikailag összeszorzott és az eredmény az L1018-ba adta meg. Azóta se tudom milyen adat terület ez, de talán most megmondja valaki -
Szirty
őstag
válasz
Dezsi82
#4715
üzenetére
Üdv Dezsi82!
"De találkoztam már jó pár S7-300s CPUval, így úgy gondolom ez nem lehet De találkoztam már jó pár S7-300s CPUval, így úgy gondolom ez nem lehet nagyon gyakori.nagyon gyakori."
Az újabbak ilyenek. A 400-asok közül a régebbiek is.
Nekem a legelső CPU-n nem működött emiatt amin kipróbáltam!
Főleg hogy alacsony című merker címet írtál a példába és a retentív terület beállításánál a kezdőcím rendszerint 0!!
Tehát az alacsony címeknél a legvalószínűbb, hogy nem fog működni ez a módszer.Ez a megoldás ellenjavalt. Senkinek nem ajánlom!
A restart OB-t találták ki arra, hogy indításkor elvégzendő feladatokat az végezze el. -
Szirty
őstag
válasz
Dezsi82
#4711
üzenetére
Helló Dezsi82!
Az rendben van hogy minden feladatra van sok megoldás és ezek között több megfelelően helyes.
Bár kifejezetten a megoldást nem ajánlottad, csak leírtad te hogyan csinálod, de ezt egy olyan kérdésre írtad, amiben azt kérdezik hogyan lehet first cycle impulzust létrehozni.
Ha már akkor is tisztában voltál a módszer komoly hátrányával (amikor az illető bit nem "felejt") akkor ezt nem ártott volna megemlíteni, mert akinek ilyen tipped adsz, azt bevezeted az erdőbe. Ő meg ír egy időzített bombát egy programba.
Nyilván úgy csinálod, ahogy akarod, rendben van. De mint írtam, van CPU, aminél minden retentív (kivéve a process image bitek). Az ilyennél hogy oldod meg ezt? Vagy nem találkoztál még ilyennel? -
Szirty
őstag
válasz
Dezsi82
#4707
üzenetére
Helló Dezsi82!
Azt hiszem az imént túlságosan lehengerlő voltam, elnézést!
Szóval azért nem jó az a always on bittel létrehozott impulzus mint first cycle flag, mert ha a kiszemelt bit értéke 1 marad kikapcsolás után majd újabb bekapcsolás alakalmával, az impulzus nem fog létrejönni, mert nem lesz 0->1 átmenet.
És hát az adatmegtartó terület éppen ilyen tulajdonsággal bír.Próbáltam indokolni, elnézést ha nem fejtettem ki kellő mélységben! Teszteld széleskörűen azt a módszert, látni fogod!
-
Szirty
őstag
válasz
Dezsi82
#4705
üzenetére
Helló Dezsi82!
Óha!
Sajnos nem értek egyet! Ez a megoldás nagyon szívatós!
Senkinek nem ajánlom!!!Ha az M0.0 retentív területen van, akkor nem fog működni. Márpedig van olyan CPU aminél te mondod meg melyik merker terület legyen retentív és melyik ne, és van olyan CPU amelyiknél mindenképpen mind az. Na annál fogják megszívni.
Mindenki használja azt ahol OB100-ban SET bit
OB1 utolsó sorában RESET bit.
Bomba biztos és nem kell külön merker bit sem a -(P)- miatt. -
-
Szirty
őstag
válasz
Dezsi82
#4678
üzenetére
Üdv!
"Ez a módszer engem is érdekelne, mert nekünk is nagy gondot okoznak a nem fizető ügyfelek"
Megfelelően megírt hivatalos szerződés a dolog nyitja.
Ami a szerződésben van azt kell teljesíteni. Ha ez nem történik meg valamelyik fél részéről, akkor lehet pereskedéssel szarakodni.Korrekt üzlet idáig nem kellene hogy eljusson. De ha eleve cigányság van a dolog mögött, akkor rakhattok atombombát is a programjába, kit érdekel?
-
Dezsi82
tag
válasz
Dezsi82
#4679
üzenetére
Üdv
Még annyit hozzáfűznék, hogy mi azért egy hónapot szoktunk ráhagyni, mert két nap elég szoros határidő. Nyilván határidő előtt nem cseszegetjük őket. Aztán ha lejárt egy-két nappal, akkor telefon. Ilyenkor persze ígéret, hogy a hét végéig utalnak. Persze nem így lesz. Írásos figyelmeztetés, és kb egy hónap után aktiválódik a hiba, ami általában megteszi a magáét -
KB.Pifu
tag
válasz
Dezsi82
#4666
üzenetére
üdv!
Nagyrészt egyetértek veled, viszont én akkor csak úgymond a szerencsétlenebb fajta vagyok, valóban nem programoztam még semmit, a "suli" kilökött az ajtón oszt szevasz.
Azért vagyok szerencsétlen, mert hiába teperek, "mérnök" létemre minden nap nyakig olajos vagyok és egész nap benne csücsülök a gépben ha az kell. (emulziós hűtésű cca 10 éves fémmegmunkálók, sorjázók stb, mindenhol vastagon áll az olaj)
Én megelégednék kb 250-300 ezer huf BRUTTÓ kezdő fizetéssel is egy új munkahelyen ahol végre PLC programozással kell foglalkozni, ami azért nem sok (pláne hogy se hülye, se pályakezdő nem vagyok), sőt Pesten még kevés is. (nah jó, ott lehet kicsit többet kérnék)3 éve végeztem és még mindig azzal heccelnek, hát te ilyet még sosem csináltál... persze, mert nem is engedtek oda. Pályakezdő PLC programozó állást meg szerintem nem létezik.
A kedves cégvezető úr elmagyarázta, hogy azért nem vesz fel programozónak, mert elkérem és megkapom a havi br 300-at, neki ez ugye minden jutalékkal együtt 450 k-t (most nem vagyok biztos) jelent havonta, egy évig csak a betanításomra megy az idő aztán meg jól lelépek. Jah megköszöntem az állásinterjút aztán elmentem, sokat alkudozni nem kellett.
Viszont, ami miatt nem érdekel annyira a karbantartás, mert ott olyan sosem lesz, mint amiről itt gyakran szó van, HMI programozás, PLC és HMI közötti kapcsolat figyelése, analóg bemenet skálázása stb, ami miatt a programozó programoz és nem karbantart, amit tényleg a programozó talál ki, valamiért sokan nem értik, hogy a programozó és karbantartó az nem ugyanaz, karbantartótól senki nem várja el, hogy STL-ben olvassa a Siemens programot, de még azt sem, hogy tudja hogy az integer 2 byte-val mekkora értéket lehet megjeleníteni. Neki nem ez a dolga, akkor nekem miért kell egyszerre 2-3 különböző szakmát tudnom?
Ha a gépet helyszínen be kell rúgni, akkor nincs mese javítani kell és bemászni akár egy érzékelőért is a gép alá, én ezt bármikor megteszem (szerintem csak erre kell a karbantartói tapasztalat).
Persze sokat látott ember hamarabb elboldogul, akár a tervezésben is be tud dobni jó ötleteket, de javítsatok ki ha tévedek, ilyen cégeknél csak feljogosított személyek tervezhetik a villamos rendszert, kamarai tagsággal meg ilyenek.
-
#4669
Achilles83
csendes tag
Dezsi82
#4665
Achilles83
csendes tag
válasz
Dezsi82
#4665
üzenetére
Orvosi felhasználásra én sem fogok barkácsolni az biztos
, de az otthoni kazánfűtő rendszer szerintem elbír fél fokos hibát, de még talán többet is.Talán jobb lenne, ha a gyártók kategorizálnák a távadók pontossági tulajdonságuk szerint(a kevésbé pontos az olcsóbb) hogy ne csak a cégeknek érjen már meg egy ilyen érzékelőket venni, hanem aki egy kicsit is modernizálni akarja a házát, azért neki is elérhető áron legyen. -
Szirty
őstag
válasz
Dezsi82
#4666
üzenetére
Helló Dezsi82!
"De ha megnézzük a másik oldalt, akkor iskolából kilépett, nulla tapasztalattal rendelkező "mérnök", aki soha életében nem programozott ipari környezetben (max. rendőrlámpát) elkér annyi fizetést, amennyi egy kisebb cég havi költségvetése."
Abszolút így van.
Attól tartok a dolog valahol ott csúszott el, hogy az azonnali elvárások az egeket ostromolják, mindenki a mának akar élni, az oktatás színvonala meg ugyanilyen meredeken zuhant a béka segge alá.
Emiatt mára kialakult az a helyzet, hogy a munkáltatók és a munkavállalók semmit nem nagyon adnak de mindent akarnak. Az önéletrajzok tele vannak halandzsával és hazugságokkal. Az álláshirdetések meg hangzatos pozíció nevekkel, homályos ígéretekkel ("versenyképes bér", "fiatalos lendület", "rugalmas munkaidő (nekik az, neked meg xopás)), Az ilyenekben szoktak felbukkanni a "specialista", "manager", "asszisztens" szavak.Sajnos egy jó álláshoz ma már a tudáson, tapasztalaton kívül jó sok szerencse is kell.
-
Szirty
őstag
válasz
Dezsi82
#4665
üzenetére
Üdv!
Annyit jegyeznék még meg, hogy ha csak feszültség fogadására képes analóg bemenet van és ahogy már "elhangzott" nem kell nagy pontosság, akkor inkább termisztort érdemes használni hídban vagy egyszerű fesz osztóban stabil tápról (szoftveresen azt is linearizálni kell ha szükséges),
Pt100-al is meg lehet csinálni, de egyrészt a Pt100 az precíziós ipari hőmérséklet mérésre való, másrészt a 100 ohm nem kedvező ilyen osztós megoldáshoz. 1k termisztor jobb.
Másrészt Pt100-al így mérni olyan mint ha valamit mikrométerrel mérne az ember aztán krétával jelölné be a mértet... -
#4650
Achilles83
csendes tag
Dezsi82
#4649
-
Onishi
tag
válasz
Dezsi82
#4622
üzenetére
Igazából azért lenne rá szükségem, mert ez egy családi házban használt plc, és ehhez szeretnék egy megjelenítőt csinálni, amihez egy androidos tabletet használnék. Léteznek mindenféle alkalmazások siemens plc-khez, a kommunikációt meg lehetne oldani, de csak akkor, ha etherneten kommunikálna a plc. Valszeg ehhez a soros-ethernet átalakítóhoz nincs androidos driver, nem hiszem, hogy azzal meg lehetne oldani. Vagy veszek egy windows 7 -es tabletet és azzal. De az drágább, mint egy androidos. Legjobb egy CP kártya lenne plc-hez, de horribilis árai vannak.
Ilyesmiken agyalok mostanság. -
Szirty
őstag
válasz
Dezsi82
#4609
üzenetére
"Lehetséges, hogy az S7-400 ilyen? A netes leírásokból úgy tűnik"
Úgy fest.
Ha ugyanezt az ET200S DP node-ot feldobálod egy S7-300-ra, akkor byte-onként is engedi címezni.Bár a tartalék képzés nem túl erős érv, a 300-ason nem kell tartalék? vagy csak nagyobb az address space ezért bátrabban lehet pocsékolni :-)
Vagy az ok hasonló ahhoz, hogy PC magas szintű nyelvek ma már 64 biten tárolják a boolean adatot. Ez csak hatvannégyszer több a kelleténél, de könnyebb címezni. :-)
(Mottó: A mértéktelen jólét mértéktelen pazarlással jár)
-
Szirty
őstag
válasz
Dezsi82
#4597
üzenetére
Üdv Dezsi82!
"- hova kellene kötni a lámpát? Ha jól sejtem az R2 be nem rajzolt kontaktjára"
Igen, jól sejted. Illetve be lehet kötni az S1 nyomógomb 13-as és R1 relé 11-es pontját összekötő vezetékre is, így hogy a lámpa egyi kivezetése ide, a másik a 0V-ra kapcsolódik.
Így a lámpát az R2 relé 11-12-es kontaktusa fogja kapcsolni."Ha elengedem a gombot, és nem ejt ki az R2 akkor a két relé egymással sorba van kötve. Ilyenkor meg kellene húznia R1-nek, és tartásban maradnia?"
Így van, pontosan ez történik! :-)
"Aztán amikor meghúz R1, akkor az R2 két pontja kerül ugyanarra a potenciálra, és kiesik?"
Igen kiesik, de nem azért mert ugyanarra a potenciálra kerül, hanem mert nem kap feszültséget.
Az egész kapcsolás amiatt a trükk miatt tud ilyen egyszerű lenni, hogy kihasználja azt a tényt, hogy a relék fél feszültséggel is bekapcsolnak, és úgy maradnak.
Ez egyúttal a működés feltétele is, tehát olyan relé kell aminek a behúzó feszültsége alacsonyabb a névleges fesz. felénél és a két relének egyformának kell lennie.A kapcsolásnak négy állopota van:
-
joci9
tag
válasz
Dezsi82
#4582
üzenetére
Szia!
Igen, köszönöm.
A csv fájl írással is így van, ma kipróbáltam panelon (IT112, amin valami zárt CE fut, lehet kérni excellel is), ott nem működ, PC-n meg igen.
Mostani projektjeimben elég a szöveges fájl kezelés, az meg string kezeléssel tök jól megoldható. Csak rá kellett jönni.ü
-
dave0825
őstag
válasz
Dezsi82
#4579
üzenetére
Tegnap este olvastam el a válaszokat, de nem sokkal, miután kiírtam ide, megtaláltam a megoldást
Azért köszönöm a segítséget Neked is, és Szirty-nek is (még ha nem is tűntem pontosnak, és egyértelműnek )
Ez lett a megoldás, és működik, úgy, ahogy szerettem volna.
Egyébként egyetemről vagyok szakmai gyakorlaton egy cégnél, és ott kérdezték, hogy tudom-e, hogy hogy kell ezt megcsinálni, és majd valamikor jöjjek rá a megoldásra, míg ott vagyok (6 hétig)
-
Kopri 62
újonc
válasz
Dezsi82
#4564
üzenetére
Sziasztok, valóban a naplózásra gondoltam, ami a SCADA szoftvert illeti pontosan az ára az ami egy kicsit kiábrándító. Gondoltam más gyártónak is létezik valami kompatibilis változat.Egyébként ha valaki ellátna egy ilyen szoftverrel megfizethető áron arra is vevő lennék függetlenül attól, hogy gyári vagy esetleg saját készítésű.
-
Szirty
őstag
válasz
Dezsi82
#4559
üzenetére
Üdv Dezsi82!
Nem árultál el eleget a pontos körülményekről.
Csak annyit tudunk, hogy 3 CPU van egy profibus DP hálózaton, amelyek közül kettő kvázi véletlenszerűen cserélődik. A "vándorokba" nem kell feltétlen slave DP modul ha a saját hálózatán nincsenek DP slave-ek, mivel a DP-s CPU beállítható slave-ként is a beépített DP interfészén.Persze ha vannak saját DP-s I/O-k rajta akkor master kell hogy legyen.
Viszont egy profibusz hálózatban lehet több master is. Ám azt nem tudom hogy egy hálózatban lévő két master hogyan tud egymással kommunikálni, ilyesmit még nem kellett csinálni.Mindezt csak megjegyeztem mert eszembe jutott a témával kapcsolatban. Ha a DP-DP coupleres megoldás megfelelő, akkor ezzel a problémával már nem kell foglalkozni.
-
Szirty
őstag
válasz
Dezsi82
#4557
üzenetére
Hali!
DP-DP coupler is van a világon :-)
Beraksz egyet-egyet a két "vándor" CPU elé meghatározott fix DP címmel, és a vándor CPU-k címe mind lehet teljesen azonos.
Az azonosítás meg egyszerű, mert az adott "vándor" majd megmondja magáról ki ő. Nem lesz profibusz hiba, nem kell aktiválni, lekérdezgetni vagy címekkel sakkozni. -
Szirty
őstag
válasz
Dezsi82
#4538
üzenetére
Üdv Dezsi82!
"Ezzel az a gondom, hogy nem tudom, mivel lehetne lekérdezni, hogy egy, a configban szereplő, de deaktivált eszköz állapota mivel kérhető le."
Mit értesz pontosan configban szereplő deaktivált eszközön?
Ha azt, hogy benne van a konfigban de nincs jelen a buszon, illetve ha jelen van a buszon van-e busz hibája lekérdezhető az SFC51-el.DP station állapotának lekérdezése S7 PLC-ben
Az a megoldás hogy minden szerszámnak egyedi címe van azzal jár, hogy mindig lesz busz hiba a PLC-n, mivel egyszerre az összes előre konfigurált szerszám nem lesz jelen a buszon (mindig csak max 2).
Lehet minden szerszámnak ugyanaz a címe is, ha a PLC-n két DP busz van...
-
DP_Joci
tag
válasz
Dezsi82
#4538
üzenetére
Hello,
Ez érdekes feladat
Ha 2 DP címet osztasz szét a szerszámok között, akkor minden cpu-ba ugyanarra a címre (word) berakhatod a szerszám azonosítót, így lehetne azonosítani a szerszámot. De itt szerintem ez csak akkor működhetne, ha a cpu-k azonosak, vagy nem.
Ha viszont minden DP címet felveszel a hardver konfigba, akkor nyilván folyamatos busz hiba lesz, de egy Profibusz diagnosztikával ellenőrizheted, hogy melyik címek vannak a buszon és azoknak egy bizonyos wordjében tárolt azonosító megmondaná neked melyik az a szerszám. (ha már maga a cím nem tudná ezt meghatározni)
-
byte-by
tag
válasz
Dezsi82
#3915
üzenetére
halo!
a kezdetekkor én nyitó és záró impulzusokra gondoltam.
az SP-hez képest alacsony PV esetén a nyitó impulzus többször jelentkezik , közelítve lassul.
elérve , vagy túllépve az SP-t a záróimpulzusok szintén hasonló módon mozgatnák a szelepet.persze azért több paramétert is figyelembe kellene venni.
-
Szirty
őstag
válasz
Dezsi82
#3354
üzenetére
Helló!
Szerintem az inkrementális jeladók felbontását impulzus/fordulat (pulse/revolution) értékben adják meg attól teljesen függetlenül, hogy egy fázisú, vagy két fázisú (A és B) jelet ad.
Így ha a gyári adatban szerepel mondjuk 200 p/r és a jeladó két fázisú jelet ad, akkor mindkét fázison egy teljes fordulat alatt 200 teljes periódust lehet megszámolni. Az A és a B jelek fordulatonkénti periódusainak számát nem adják össze sose.No de van (amit Dezsi82 is említett) amikor a két fázisú jelnél nem a periódusokat számolják, hanem a jelváltásokat (éleket). A két fázisú jelben egy fordulat alatt négyszer annyi jelváltás van, mint amennyi a jeladó felbontása. Így a felbontás megnégyszerezhető (quadratic count).
A sebesség mérése nem hiszem hogy gond lenne, egyszerűen meg kell számolni adott idő alatt mennyi impulzus jön. Abból kiszámolható.
-
Szirty
őstag
válasz
Dezsi82
#3244
üzenetére
Helló Dezsi82!
Amit írtam azt a fórumon, mail-ben, skype-on kérdezőkre értettem, nem a munkát megrendelőre.
Az előbbiek írásban jönnek, az utóbbiak meg személyesen, szóban (a végső egyeztetés legalább).Az ok is megvan amiért így viselkedek: A fórumozók (természetesen tisztelet a kivételnek) szeretnek semmit adni és mindent akarni. Ezt főleg az információra értem. Nem azt mondom van az az eset, amikor tényleg lehet tudni mit akar, még ha nem is írja le, de nagyon sokszor lehet bemenni az erdőbe egy feltételezés alapján és sokat fölöslegesen dolgozni a válaszon. Én azt gondolom, hogy a kérdező is küzdjön csak meg legalább egy kicsit a válaszért.
A hagyományos nyomásszabályzó egyébként azért jutott eszembe, mert ahol egy műszaki megoldásra szabad kezet kapnak, ott Ockham nem mindig borotválkozik :-)
Ilyenkor hajlamosak vagyunk egy frappánsan összetett, szakmai kihívást jelentő megoldással előállni és elvetni a sokkal megfelelőbb egyszerű standard megoldásokat.
Azt persze (épp a kevés infó miatt) nem tudhatom, hogy tényleg megfelelne-e oda amire gondoltam, de ha több megoldás is megfelel, akkor mindig válasszuk az egyszerűbbet. Hosszú távon ez megtérül. -
Szirty
őstag
válasz
Dezsi82
#3242
üzenetére
Helló Dezsi82!
Ha kell állítani... Nem tudjuk. Nem esett szó arról, hogy állítgatni kell, és amíg ezt nem írja én nem is feltételezem. Az esetek többségében célszerűbb a kérdésre és nem a kérdés mögött feltételezett kérdésre válaszolni. Legalábbis én így gondolom (sokan nem, főleg a kérdezők, de én igen. Ez van). Aki rossz kérdést tesz fel, az kapjon rossz választ. :-)
Az ilyen messzire vezethet, mert mi van HA nem tetszik neki a kék szín, az meg pont kék? Stb, stb, stb...Ha kell állítani, akkor odamegy és állítja. Ha nagyon gyakran és automatikusan vagy távolról kell állítani az más kérdés, de eddig ilyen igény nem került szóba.
-
Szirty
őstag
válasz
Dezsi82
#3221
üzenetére
Hali!
Még annyi jutott eszembe a dologgal kapcsolatban, hogy ez idő átállítgatás olykor egy csomó problémát okoz. Emiatt nem ritkán érzem úgy, hogy sokkal több problémát okoz, mint amennyit megold....
Pl. ha van időhöz (időponthoz) kötött funkció és az időállítással átlépi vagy éppenséggel visszalép az időpont elé. Vagy amikor pontos 24 órás mérést vagy regisztrálást kell megvalósítani.
Vagy S7-300/400-nál ha Time of Day interruptotot használunk és az annak beállított időpontot lépi át az átállás keletkezik egy time error, amiről ha nem gondoskodunk, jön a CPU stop stb, stb, stb :-) -
isvarga
csendes tag
válasz
Dezsi82
#3228
üzenetére
Szia!
Sajnálom ,hogy nem tudtam neked kielégítő információt adni.
Én úgy csinálnám meg ,hogy naponta egy bitet törölnék (de lehet set-telni is) ami a téli-nyári átállást mutatja.
Egy nap csak egyszer lehetne ilyen műveletet elvégezni , másnap meg már nem próbálná ,mert már nem aktuális.
Egyébként az óra ic-knél milyen megoldást használtok , a pontos idő vizsgálatára? (telep-kondi kimerülésre gondolok)Varga István
-
isvarga
csendes tag
válasz
Dezsi82
#3221
üzenetére
Szia!
Nagyon egyszerű a dolog:
Az alaplapra van integrálva egy óra ic ,ezt egy gombelem látja el táppal . (meg a biost is)
A beállításokat az internetről szedi le , amelyik gép nincs interneten soha ,az 2-3 percet késik-siet évente.(az alkatrészek pontossága ,a környezeti hatások figyelembe vételével)
A téli-nyári átállás szoftveresen megy.(op rendszerből)
A legtöbb kontrollerbe ma már beintegrálják az óra ic-t is,de lehet külön is kapni.( naptár is van benne)
A többi már csak kiépítés kérdése.(1 db 32.768 kHz kvarc kell hozzá)Varga István
-
Szirty
őstag
válasz
Dezsi82
#3215
üzenetére
Helló Dezsi82!
"Omronnál nincs PWM funkcióblokk, egyszerűen csak a megfelelő CIO címre kell a szükséges értékeket beírni, és a megfelelő biteket beállítani
Ilyen funkcióblokkot nem fogsz tudni leprogramozni, mert a PWM kimenet olyan gyors kell legyen, amit a felhasználói program ciklusidejének ingadozása és mértéke nem teszi ezt lehetővé."A dologgal kapcsolatban annak teljessége érdekében meg kell jegyeznem, hogy:
Vannak szoftveres és hardveres PWM generátorok. Mindegyiknek megvan a maga előnye és felhasználási helye.Igen valóban van PULSEGEN funkcióblokk, S7-nél, ami szoftveres PWM generátor. Ez természetesen lassú, nagy időállandójú PWM előállítására használható, ami bőségesem meg szokott felellni PID controllerek teljesítmény szabályzó kimenetéhez.
Egy fűtésre használt gáz égőt amúgy sem lehetne másodpercenként több százszor ki/be kapcsolni, oda perces sebességű PWM kell. De egy PLC kimenet által vezérel SSR-es fűtés kapcsolgatására is meg szokott felelni az 1-2 másodperces ciklus idő, amihez megfelel a szoftveres (és lassú) PWM.
A felhasználói program ciklusidejének ingadozásának "pontatlanító" hatását ennél azzal küszöbölik ki, hogy timer interrupt OB-ból futtatják, ami pontos.A másik, hogy S7-nél is van hardveres PWM lehetőség. Persze CPU függő. Nem mindegyiken van.
Ahogy szerintem omronnál meg van szoftveres PWM lehetőség és akkor körbe is értünk.
-
Szirty
őstag
válasz
Dezsi82
#2982
üzenetére
Helló Dezsi82!
A diagnosztikai bufferből mindig kiderül melyik hibakezelő OB hiánya miatt áll meg.
Így csak blöffölni tudok.Szerintem OB122 (I/O Access Error Organization Block)
Gondolom nem csinálták meg rendesen a buszos eszköz hibakezelését és akkor is írni és/vagy olvasni akarja amikor még nincs jelen a buszon.
Nézd meg a diag buffert.Ha ez a probléma, akkor úgy lehet kezelni, hogy OB1-ben meghívod SFC 51 "RDSYSST"-t amivel megállapítod melyik konfigurált eszközök vannak jelen a buszon és a PIW/PQW írását csak akkor engeded ha jelen van.
-
Szirty
őstag
válasz
Dezsi82
#2869
üzenetére
Helló Dezsi82!
Természetesen az összes ellenszenvem a virtuális géppel kapcsolatban a mindennapi "éles" használatra vonatkozik.
Kétségtelenül előny, hogy lehet gyentelni egy VM-et ritkán használt, más szoftverekkel együtt nem működő programokat havonta/évente egyszer-egyszer használni, vagy szoftvert kipróbálni. Arra tökéletes."- Több fejlesztő környezetet használsz és nem akarod hogy az összes környezet összes kis kommunikációs, sql, meg minden egyéb kis kütyüje fusson olyankor is, amikor nem is használod."
Ne viccelj ez meg milyen érv? Azt akarod,hogy a virtualizálás állandó jelleggel két pofára GByte számra zabálja a RAM, ot és felezze a a CPU teljesítményt, mert nem akarod, hogy néhány service elhasználjon 10% CPU időt meg pár-tíz MB memóriát?
Milliókat költünk pár forint megspórolására...
Persze akarhatod, magánügy, nem akarlak meggyőzni semmiről én csak azért írom le miét nem akarom. (Az ellentétek ütköztetése segíthet másoknak eldönteni ők mit vagy mit ne akarjanak)Nyilván megvan az előnye és emiatt a létjogosultsága a VM-nek is. De azért azt merész lenne kijelenteni hogy ezzel együtt nincs hátránya és hogy mindig probléma mentes.
Számomra két alapvető hátránya teszi problémássá a a mindennapi használatát.
Az egyik a mértéktelen erőforrás igénye, és teljesen mindegy hány csillió teraHertzes a CPU (és ezen az erőforrás zabáló VM-en futtatunk erőforrás zabáló szoftvert (.NET-es alkalmazás rulez)). Persze a sebesség még ha mérhető is, van annyira szubjektív, hogy talán ami neked "nem lassú" azt én állni látom, benne van ez is.Mindenesetre szarul nézett ki, amikor baj volt egy géppel és terepen bekapcsoltuk a gépet, a BIOS szokásos fél perces parádéja után feltápászkodott a Win 1-2 perc alatt, aztán az egész boot műveletet megismételtük további 2-3 perc alatt a virtuális gépen, majd további fél perc mire betöltődik a fejlesztői környzet, aztán egy 20-30 másodperc "kiböngészni" a projectet és annak betöltődésekor nézni a homok órát, miközben a fél műszak, a művezető, az üzemvezető meg a karbantartók kérdezgetik hogy na mi a baj, mit csinálsz...
Persze tudom jöhetnek az ellen érvek: Pl. hogy vegyünk gyorsabb gépet. Vagy a notebookban van akku, nem kell leállítani amikor kivisszük (akku van, csak épp egy percet sem bír már szegény).
Vagy hiberbnáljuk, ne bootoljunk, akkor gyorsabban lesz üzemkész. Sajnos van hogy a "sztázisból" bal lábbal ébred a windows és nem jut eszébe hogy hálózat is volt még mielőtt elaludt. Így lehet újra bootolni, ami a leállással együtt, meg a hibernációból való ébredéssel együtt a fenti folyamatra rádob még pár percet. Ezt persze nem mindig csinálja, de ilyenkor (amikor sietni kellene) valószínű :-/Mivel a sok kicsi sokra megy a végén mit látnak? Azt, hogy áll a gépsor, én meg negyed óráig állok tétlenül a gép előtt...
Mióta natív XP megy és nincs VM a gyakran használt fejlesztői rendszer alatt, azóta sokkal hatékonyabb a munka. Ezért javaslom mindenkinek hogy ha teheti kerülje a VM használatát."...és nem szeretnéd, hogy elrontsa a korábbi szoftvert és újra kelljen telepíteni, akkor csak csinálsz egy snapshotot, és bármikor vissza tudsz állni."
A host gépen végrehajtott image mentéssel megoldható.
-
sörösló
aktív tag
válasz
Dezsi82
#2857
üzenetére
A nálunk működő rakatolóautomaták szervói resolveres jeladókkal működnek. Elmennek egy induktív érzékelőig, aztán tovább a resolver következő nullaátmenetéig. Ez a referenciapont. Ezt a módszert a német szerelő magyarázta el, de konkrét eljárást nem ismertetett. Az egyik gép lelke a jó öreg S5 hihetetlenül bonyolult szervovezérlője, amihez a csak a kizárólagosan használható programozókészülék töbszázezer, a használatához szükséges tanfolyam szintén. A másik egy S7 300 családba tartozó CPU, ami egyedi, technológiai CPU, felvértezve a háromtengelyes szevo vezérléséhez szükséges dolgokkal. A szoftveres hozzáféréshez a fullra töltött SIEMENS FiELD PG mellett még egy + párszázezres kiegészítő program kellene. de valszeg azzal sem mennénk semmire probléma esetén. Néhány kolléga szerint CNC gépeknél az abszolút útadó az egyetlen járható megoldás. Ez sem az ócsó kategória, úgyhogy az élet nem egyszerű
-
Szirty
őstag
válasz
Dezsi82
#2851
üzenetére
Helló Dezsi82!
A szervó hajtásokra jellemző (már amiket ismerek) hogy a refpoontnak nem kell a nulla pontnak is lennie egyben (sőt a legtöbbször nem az).
Durván fogalmazva úgy fest, hogy elballag a refpont érzékelőhöz, ott valamilyen módszerrel (pl. a "hiszterézis kereséssel") felveszi a referencia pontot és a koordináta rendszer nulla pontját ehhez viszonyítva állítja be (többnyire egy előre megadott paraméter alapján.
Több egyforma gépen ennek a paraméternek a beállításával (ha volna ilyen) elvileg teljesen azonos helyre lehetne hozni a hajtás nulla pontja.Sajnos igen a paraméter meghatározásához mérni kell. Mégpedig legalább olyan pontosan, amilyen pontosan be kell állítani egyformára.
A mérésről semmi elképzelésem nincs, nyilván kell egy bázis amihez képest mérünk. De hogy milyen mérési módszer adna ilyen pontosságot nem tudom, nem vagyok gépész.
De abból, hogy a szervó képes mérni a saját mozgását ekkora pontossággal, azt feltételezem, hogy ilyen pontos mérés lehetséges és kivitelezhető.
(Vannak pl. 1um pontosságú optikai távolságmérők) -
Szirty
őstag
válasz
Dezsi82
#2848
üzenetére
Hali Dezsi82!
Én sajnos csak elméleti fejtegetésbe tudok menni, ezért valószínűleg nem szolgálok válasszal a kérdésedre, de érdekes probléma.
Ha a szervó inkrementális encoderrel dolgozik, és az encodernek az "A" és "B" jelén kívül van "Z" is (ami körülfordulásonként egy impulzus) akkor a pontos refpontot ad az, ha a refpont ind. érzékelő valahol két "Z" között van. és a refpont az adja, hogy elérte ind. érzékelőt és onnantól első "Z".
Sajnos mivel a refpont felvétel ált. a drive magánügye, ha ilyen lehetőséggel nem vértezték fel, akkor ez máris füstbe ment.
Szokott lenni sok (de legalábbis több) reftravel mode. Akkor ahogy mondtad az lehet a legjobb ha elmegy ind. érzékelőig, megjegyzi hol érte el, túlmegy, megjegyzi hol hagyta el és a kettő különbségének a fele lesz a refpont.Amúgy fogalmam sincs, ilyen pontosság még nem kellett nekünk (igaz ált. a szervó utak nálunk 10 méterekben mérhető).
A CNC-k hogy/mivel csinálják ezt?
-
-
Dezsi82
tag
válasz
Dezsi82
#2830
üzenetére
Szia!
Közben rájöttem, h a FIFO kiolvassa a tárolóból, az ATT meg beleteszi.
De mivel nemsokára nekünk is kell egy ilyen alkalmazás, meg is írtam a függvényt.
Az FC1 függvény csinálj a lényeget. Kell neki egy DB szám. Ez itt most a DB1. Ebbe kell hogy legyen egy integer, utána meg egy real tömb. A tömb méretét ha átállítod, akkor az adatok is tovább mennek bele.Más nem lehet a DBben!!
Vár még agy real adatot, egy bemenetet a naplózásra, és egy segédmerker kell még neki. A kimeneten jön az átlag, a min és a max.
Ha nem felfutóra szeretnéd, hanem minden ciklusban, akkor ki kell szedni az FC1 ben azt a a sort, hogy AN felfutó_seged
Itt a projekt -
Dezsi82
tag
válasz
Dezsi82
#2769
üzenetére
Szia!
Csináltam egy kis szimulációt. Ebben kiderült annyi, hogy a master kimenetéhez, jobb ha hozzáadod a beállított tartályhőmérsékletet (mivel hogy a PID alapvetően különbségképző) és ez lesz a slaved alapjele.
Ha esetleg érdekel a szimuláció
Új hozzászólás Aktív témák
Hirdetés
- AKCIÓ! GAMER PC: Új RYZEN 5 4500-5600X +RTX 3060/3070/3080 +Új 16-64GB DDR4! GAR/SZÁMLA! 50 FÉLE HÁZ
- UHH! HP EliteBook 840 G8 Fémházas Laptop 14" -45% i5-1145G7 4Mag 32/512 FHD IPS Intel Iris Xe Magyar
- Xiaomi Redmi Note 13 Pro 5G - 8/256 - Media Markt garancia
- Xiaomi Redmi 9at - 2/32 - szürke
- Xiaomi Mi8 - 6/128 - fekete
- ÁRGARANCIA! Épített KomPhone Ryzen 7 9800X3D 64GB RAM RTX 5090 32GB GAMER PC termékbeszámítással
- MacBook felváráslás!! MacBook, MacBook Air, MacBook Pro
- LG 42C3 - 42" OLED EVO - 4K 120Hz 0.1ms - NVIDIA G-Sync - FreeSync Premium - HDMI 2.1 - A9 Gen6 CPU
- Realme C30 32GB, Kártyafüggetlen 1Év Garanciával
- AKCIÓ! nVidia Quadro P4000 8GB GDDR5 videokártya garanciával hibátlan működéssel
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: Promenade Publishing House Kft.
Város: Budapest