Hirdetés
- sziku69: Szólánc.
- Luck Dragon: Asszociációs játék. :)
- sziku69: Fűzzük össze a szavakat :)
- ubyegon2: Airfryer XL XXL forrólevegős sütő gyakorlati tanácsok, ötletek, receptek
- Brogyi: CTEK akkumulátor töltő és másolatai
- Krumple: [Xpenology] DSM 7.3 telepítése proxmox 9 alatt - GUIval
- eBay-es kütyük kis pénzért
- Kalandor: „Ha engedtem volna a lelkiismeretemnek, az üzlet kevésbé lett volna jövedelmező”
- 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
-
Dezsi82
tag
válasz
crucified
#6491
üzenetére
És ugye a comparálással tudod bizonyítani a felhasználó számára, hogy az eredeti programmal működik miután visszaállítottad, ergo valaki ott helyben babrálta
Ez így van, a legtöbb esetben (ahogy írtam, ez azért nem mindig ilyen egyszerű). De ehhez is el kell menni, összehasonlítani, feltölteni, tesztelni. Épp elég baja van egy fejlesztőnek alapból, nem kell még neki ráadásul a teljesen felesleges utazás, és nyűg a nyakába.De ez csak az éb szubjektív véleményem, tiszteletben tartom az ettől merőben eltérőt is. Nálam az én verzióm működik.
Én is így gondolom. Nekem is sokkal jobb ha megvan a forrásprogram, könnyebben hibát keresek, módosítok. És én is mindig átadom, és olyan kódokat készítek ami megkönnyíti a hibakereső, módosító munkáját, nekem is kevesebb a nyűg. De teljesen megértem azokat a cégeket, akik levédik a kódjaikat. -
Dezsi82
tag
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...
Szerintem nincs semmi extrém abban amit leírtam- 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
Az elvvel egyet értek, de többször előfordult, hogy módosított garanciás gépünkhöz kellett kimenni, vagy garanciás gép módosítására kértek minket(olyannál aminél nem mi voltunk az eredeti gyártók). Van olyan berendezés, ahol ez azért nem fekete-fehér. Például egy robotnál van aki azt mondja, hogy egy pozíció elállítása módosítás, van aki azt mondja, hogy az még csak paraméterezés.Bárki bármit is állítson ez a korrekt megoldás!
"Nem érdekel ki mit mond, nekem van igazam"
Azokat nem akarja a felhasználó módosítani. A szakértelme és eszköze sincs meg hozzá, ahogy említetted.
Nem értek egyet.
Egyrészt nekem megvan hozzá a tudásom/eszközöm/igényem, hogy kicsit módosítsak a mosógépünkön, és a TIA portálon is (kivéve ha valami nagyon elvadult fejlesztő környezetben készítették). De sajnos nem tehetem meg, mert nincs meg a forráskód.
Másrészt ha nézek egy berendezést, ahol mondjuk van PC program, robot, PLC, és egy kis céleszköz chip-pel, akkor attól függően korrekt átadni a programot, hogy a megrendelőnél rendelkezésre áll-e a megfelelő szakember?
Szerintem ez ettől független kell legyen.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.
És ha csak egy célgépről beszélünk, nem egy gyártósorról, ott már rendben van, ha nem adja át fejlesztő a forráskódot? Hol húzod meg a határt? IO szám, vagy a programsorok száma?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).
Persze, hogy jobban jár. A fejlesztő meg akkor jár jobban, ha mindent levéd.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. Persze, ez a legkényelmesebb megoldás, de a kényelemnek sok fokozata van.
Én nem hibáztatok egyetlen fejlesztőt sem aki levédi, nem adja át a programot. Szíve joga. Ha a kijelző megadja a szükséges információt egy hiba javításához, nem kell a forráskód.
-
Dezsi82
tag
válasz
crucified
#6485
üzenetére
A fejlesztő cégnek - hangsúlyozom, csak szerintem - nincs igaza, Akkor sérti valaki a szerzői jogot, ha azt a szellemi terméket máshol is felhasználja a szerző engedélye nélkül. Addig én bármit csinálhatok a szoftverrel, ha akarom módosítom, letörlöm, stb., persze onnantól nem él a garancia, de ez már az én felelősségem.
Ez elvben jól hangzik, de a gyakorlatban ez úgy szokott zajlani, hogy nem megy a gép, mert hozzáértő kolléga mókolt valamit, nem igazán sikerült, valamennyire összekaparja a gépet, hazamegy. Este megy a gyártástól a karbantartáshoz a telefon, hogy nem megy a gép, ők meg mivel garis a gép nem nyúlnak hozzá, érkezik az értesítés a fejlesztő céghez.
Ott értetlenül állnak a helyzet előtt, hiszen ezerszer le volt tesztelve, de hát mindenki hibázhat. Azért rákérdeznek, nem nyúltak-e hozzá, ők meg "Á, dehogy, a közelébe se mentünk". Leállítják az éppen másik projekten dolgozó fejlesztőt, elküldik a pár száz kilométerre lévő géphez, javítsa ki a hibáját. Ő meg szépen odaér pár óra alatt, lehet éppen hajnalban, csinál egy összehasonlítást (a legtöbb PLCnél ez viszonylag egyszerű, robotoknál már nehézkesebb) látja hogy nem egyezik, visszacsinálja a módosítást, és megy a gép. (Legalábbis nekem ez a tapasztalatom). Így aztán az "én felelősségem" nem teljesen állja meg a helyét, mert ezt mindig bizonyítani kell.
Jómagam sosem védem le jelszóval a programot, mert több problémát megelőz mint létrehoz, de meg tudom érteni azokat a cégeket, akik megteszik.
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.
Valószínűleg azért nem, mert az illetőnek nincs meg hozzá a tudása, szoftvere, eszköze, stb. De mivel a PLChez, robothoz megvan a tudás, az eszköz ezért azt muszáj módosítani.
Szerintem alapvetően egy berendezést használatért vesz meg egy cég. Az, hogy a használó úgy dönt, hogy ő más célra akarja használni, vagy ugyanarra a célra más módon, ahhoz joga van. Ha a fejlesztő cég úgy dönt, hogy módosítás ellen védi a programot, ahhoz is joga van. Ezért ha a felhasználó úgy dönt hogy módosítja a programot, de a fejlesztő ágál ez ellen, akkor csak annyi a teendő, hogy nem az eredeti programot módosítja a felhasználó, hanem egy teljesen újat készít, ugyanazokkal a funkciókkal. Nem lehetetlen, csak idő, mint ahogy a fejlesztő cégnek is idő volt annak idején.
-
Dezsi82
tag
Üdv
kommunikációs vonalon jobb folyamatosan küldeni valamilyen jelet, és az értékét változtatni ha esemény van, mint addig nem küldeni semmit, míg nincs esemény, mert, azt nem tudom detektálniEz az alapelv meg is állja magát. Annyira hogy nem csak kommunikációs vonalon, de a digitális bemeneteknél is. Pl egy tartály minimum szintkapcsolója akkor ad jelet, amikor érzékel folyadékot, a maximum pedig akkor ha nem érzékel folyadékot. Így ha elszakad a vezeték akkor biztos nem fut a szivattyúd szárazon, és nem semmikép sem töltöd túl a tartályt (kivéve persze zárlat esetén, de mindenre szinte lehetetlen felkészülni). De a 4-20mA jeleknél is azért jó hogy 4mA a minimum, mert egyből detektálható a szakadás.
Kommunikációs vonalon külön szokás a kommunikáció épségét ellenőrizni, amire rengeteg módszer van, többnyire a protokollba beépítve.
Ha egy nagyon egyszerű kommunikációt nézek, mondjuk egy mezei RS232-t, ami mondjuk csak akkor küld adatot, amikor a bemenet igaz, ott előfordulhat az az eset, amit felvetettél. Mert ebben az esetben a küldő megnyitja a portot, és elküldi az adatot, és nem is tudja hogy a fogadó megkapta-e. Ilyen esetben is a kommunikációt kell kicsit módosítani. Vagy úgy, hogy a küldő kap visszajelzést, hogy a vevő megkapta az adatot, de ettől még csak a küldő fogja tudni a hibát. Vagy a küldő fix időközönként elküldi a bemenet állapotát, annak állapotától függetlenül. Esetleg a vevő szólítja meg először a küldőt. Ezekben az esetekben ha nincs válasz, vagy nem jött adat x időn belül, akkor gond van.
Mindenesetre ezek mind kommunikációs finomságok, nem az értékes adatot érintik.
De természetesen folyamatos kommunikáció szükséges, hogy meg tudd állapítani, hogy a kommunikációs csatornád működik-e. -
Dezsi82
tag
Természetesen képezhetsz számot az IOkból, és meg ezen kívül sok egyéb módon is ábrázolhatod, de az hogy bitekből áll, nem változik, így ugyanannyira érzékeny mintha csak egy bitet küldenél
Ugyanakkor képezhetsz egy ellenörző összeget a kapott számra (vagy akármire) és így már üzembiztosabb az adatátvitel.
De pont erre valók a kommunikációs protokollok, ezekkel neked már nem kell bajlódni. Teljesen mindegy hogy egy darab, vagy egy rakat bitet küldesz.
Ráadásul egy "darab kész" jel miatt ellőni egy CNC gép összes lehetséges kimenetét elég "drága" mulatság -
Dezsi82
tag
Üdv.
Nem vagyok benne biztos, hogy értem mire gondolsz.Az elv az, hogy a vezérlő küld egy utasítást az IOnak, hogy küldje el az IO állapotokat. Az elküldi, a vezérlés megnézi, hogy a korábban kapott állapothoz képest van-e eltérés. Ha van, és az új állapot igaz, akkor növeljük a számláló értékét.
Persze ha a munkadarabok gyártásának sebessége összemérhető a hálózati kommunikáció sebességével, akkor más megoldást kell találni és/vagy trükközni kell. (Pl a legtöbb általam ismert adatgyűjtő modulnak van beépített számlálója)
Úgy gondolod, hibás gyakorlat lenne terepi IOkról le/felfutó éleket figyelni?
-
#6380
Dezsi82
tag
gera082116
#6378
Dezsi82
tag
válasz
gera082116
#6378
üzenetére
Üdv!
Ha csak a darabszámokra van szükség, én a helyedben fognék valamilyen ethernetes IO modult (ICP DAS,Moxa,Advantech, stb), és kiraknék ezekből párat a gépekhez. Módosítani kell minden gép programját, hogy adjon egy jelet, amikor végez. Ha nagyon üzembiztosra akarsz menni, akkor handshake is lehet, vagyis kaphat visszajelzést a gép, hogy meddig tartsa kint a jelet.
Az, hogy maga az adatgyűjtés milyen rendszerben történik a rendelkezésre álló programozói képességtől függ.
De én egy nagyon egyszerű TCP/IP alapon kommunikáló programot írnék egy PCre, ami számolja a felfutó éleket. Így ez egyben lehet a megjelenítő és az adatgyűjtő is.
Az adatgyűjtő persze lehet egy egyszerű PLC is, bár ebben az esetben akkor jobb a PLC gyártójától venni az IO modult is, meg persze megjelenítő programot is kell készíteni. -
#5283
Dezsi82
tag
norbert100
#5281
Dezsi82
tag
válasz
norbert100
#5281
üzenetére
Üdv!
Különben szándékosan lépteted a címregisztered plc ciklusonként egyet?
Mert ha ciklusba szervezed, akkor nem kell elmenteni, mert egy PLC ciklus alatt megcsinálja, csak a kezd label-t tedd egy sorral lejjebb.
Persze ha kivitlezhető -
Dezsi82
tag
válasz
mcwizard
#5273
üzenetére
Üdv
Az, hogy PLC újraindítás után megmaradt a hiba, egész természetes, hiszen a Graph függvénye DBben dolgozik, így aztán az újraindítás elvileg sokat nem használ neki.
Elvileg az Init minden DB állapotot visszaállít, tehát ha minden igaz, olyan mintha újratöltenéd a DBt. -
#5263
Dezsi82
tag
norbert100
#5260
Dezsi82
tag
válasz
norbert100
#5260
üzenetére
Üdv
Még bele is írtad a kommentbe (vagy valaki): L W#16#102 //ir (01) 2 Byte
Tehát ha jelen esetben 4 byte-ot akarsz, akkor: L W#16#104 //ir (01) 4 Byte
Olvasásnál hasonlóan.
Bár nem olvastam a manualt, csak a kommentedből indulok ki -
#5256
Dezsi82
tag
norbert100
#5249
Dezsi82
tag
válasz
norbert100
#5249
üzenetére
Üdv
Valószínű azért látod csak a második adatot, mert az első írási parancsot lényegében ki sem adod. Attól, hogy beállítod a DB adott bitjét, attól még nem fog történni semmi.
Nem tudom az okát, miért két körben akarod írni, de próbáld ki, hogy minden írás/olvasás parancsod után meghívod az FC44-t
A programod így most az első parancsnál beírja az adatokat, utána rögtön felülírja a másodiknak gondolt írási parancsoddal, és a következő PLC ciklusban végrehajtja az írást/olvasást -
Dezsi82
tag
Üdv!
A következőben kérnék segítséget, ötleteket: Egy olyan érdekes feladatot kaptam, hogy van egy S7-300-as Cpu. Ehhez kapcsolódna nagyon változatos módon többféle ET200 sorozatú profibuszos io. Még az is előfordulhat, hogy ugyanazon a profibus címen egyszer egy et200 eco, aztán meg egy et200s szerepel, akár eltérő io pontszámmal. Két megoldàs jutott eszembe:
- minden lehetséges konfigurációnak létrehozok egy profibus hálózatot a hardver konfigba(kb 40-50 a lehetőségek száma), és a felhasználói programban váltogatom, hogy a cpu melyik hálózathoz csatlakozik(kérdés, hogy megoldható-e, és ha igen hogyan)
-a hardver konfigban csak a cpu lenne, és beolvasnám az elérhető profibus címeket(eddig megy is a dolog), aztán kiolvasnám hogy mennyi ki, és bemenete van a modulnak, és ennek megfelelően olvasnék, küldenék adatokat sfc14, sfc15tel. A kérdés itt is az, hogyan tudom beolvasni, hogy mennyi ki-bemenete van a modulnak/slavenek.
Ha valakinek bármi tapasztalata, ötlete van hasonló témában, szívesen várom -
Dezsi82
tag
válasz
dokikaaa
#5178
üzenetére
Üdv!
A modbus TCP elég egyszerű szerkezetű, könnyen megírható a keret. Én innen vettem az infókat:http://www.simplymodbus.ca/TCP.htm
TCPn ismét nem nagyon bonyolult a kommunikáció:
-wizardban beállítod a paramétereket
-FB65 (TCON)-nal portot nyitsz
-FB63(TSEND)-del küldesz.
-FB64(TRCV)-vel fogadsz adatot
-FB66(TDISCON)-nal bontod a kapcsolatot, ha szükségesA TCP kommunikációt a kommunikációs processzor teljesen lerendezi, nem sokkal bonyolultabb egy ilyen alkalmazás, mintha soros portot kezelnél
-
Dezsi82
tag
válasz
soldi3r
#5132
üzenetére
Üdv
Az mennyire art a frekivaltonak?
Általában nem árt neki, de valószínű, hogy ha az ember elkezdi másodpercenként 10-szer ki, bekapcsolgatni, az nem tesz jót az élettartamának. De ettől eltekintve nem szabad, hogy baja legyen tőle, hiszen kikapcsolni sem, tudod máshogy, csak ha elveszed a tápot.
Annyi gond lehet esetleg ennél a kivitelnél, hogy ilyenkor a frekiváltó nem biztos, hogy tud fékezni, lehet hogy egyszerűen csak szabad kifutással áll meg a motorod. De nyilván a lágyindító sem tett ennél többet, így elvileg nem lehet belőle gond. -
Dezsi82
tag
Nem tudom egyszerűbb-e adatküldéssel, hibakezeléssel, összehasonlítással foglalkozni mint egyszerűen figyelni egyetlen bit állapotát.
Nos, én viszont tudom. A soros port alapvetően kommunikációra lett kitalálva, nem arra, hogy egy, egy tüskéjén megállapítsuk, van-e feszültség. Tehát mivel a fejlesztő környezetek többsége felkészült ilyenre, így mondjuk egy "bonyolult" kommunikációs megoldás így néz ki:
var
Receivebuffer:array of char;
begin
Comport1.Open;
SetLength(ReceiveBuffer,1);
while True do
begin
ReceiveBuffer[0]:=' ';
Comport1.WriteStr('X');
Comport1.Read(ReceiveBuffer,Length(ReceiveBuffer));
if ReceiveBuffer[0]<>' '
Then 'Relé Zárva'
Else 'Relé nyitva';
end;
end;
ugyanakkor az "egyszerű" bit lekérdezés során olyan windows apikba kell belemenni, ami egy kezdő számára egyáltalán nem egyszerű. (És ezzel nem a kérdező programozási tapasztalatát saccolgatom, csak általánosságban összehasonlítok)
Akkor jön a krix-krax
Nem baj, ha az, tudjuk, hogy a relé zárt. Bár én már sajnos többször kellett ezt alkalmazzam, de még nem tapasztaltam
Megtelik a vételi puffer, vagy épp nem ürül ki, jönnek a hibák...
Nincs mitől megtelnie, hiszen beolvassuk. A küldési meg ismét nem tud megtelni, hiszen a programsor akkor fut tovább, amikor már az adat elment.
Természetesen működhet így is
Nem működhet, működik
nekem mégis olyan mint elefánt a porcelán boltban.
A hardveres konverter, WinAPI-val számomra meg ágyúval verébre esete, de ízlések és pofonok különbözőek -
#5092
Dezsi82
tag
Achilles83
#5090
Dezsi82
tag
válasz
Achilles83
#5090
üzenetére
Szia!
Ennel a kártyánál a full scale 4000, vagyis 0-nál a konverziós érték alsó értéke, 4000-nél a felső érték lesz. 4096 túl magas érték, ettől függetlenül lehet működik. Tehát ha a kártyád 0-10V-ra van beállítva (lehetne 1-5V,4-20 mA, 0-5 V, vagy +-10V is), akkor 4000-nél 10V, 2000-nél 5 V. Ezt különben az adatlapja adja meg. -
Dezsi82
tag
válasz
csomorbalazs
#5016
üzenetére
Üdv!
Létezhet több megoldás is, a "favágóstól" a profiig. Én PCs alkalmazásban gondolkodnék, könnyen megoldható, hogy akár képet is készítünk a kameráról, amikor kinyitják a fiókot. Miben kellene segítség? Mindenben, vagy csak egy részében? -
Dezsi82
tag
Üdv!
Az Audinál a régi csarnokban Siemensek vannak, ha jól emlékszem ez alól nincsen kivétel. Az új meg kizárólag Phoenix Contact.Az én tapasztalatom szerint a német, osztrák érdekeltségű cégek leginkább Siemens-t használnak. Az ázsiaiak meg Omron-t, Mitshubishi-t vegyesen. Az amerikaiak, északi-európaiak Allen-Bradleyt. Aztán a kis cégeknél meg minden van. Ha nem írják elő mit kell használni, akkor a rendszerintegrátor azt használja, ami a legolcsóbb, hogy megnyerje a projektet.
De én nem hiszem, hogy ezt figyelembe kellene venned tanulás közben. Ismerd meg elég mélyen a Siemenst, Omront, esetleg még valami pc közeli nyelvet használót (pl. TwinCAT, Bosch). Ha ezekben elég sok ismeretet szerzel, akkor úgy gondolom nem lesz gond akkor sem, ha egy kicsit ismeretlen PLCvel kell szembenézned.
-
Dezsi82
tag
Üdv!
A következőkben kérnék segítséget:
Létrehoztam egy UDT-t, aminek egyik eleme DATE_AND_TIME. Van egy FC-m, aminek az egyik IN_OUT-ja ez az UDT. Szeretnék ebbe a változóba indirekt címzéssel egy temp változót beleírni ami szintén DATE_AND_TIME, de valamiért nem csinálja azt, amit szeretnék, és a keresés nem hozott számomra eredményt. Jelenleg a következőképp csinálom, ami nem működik:
L P##Pultadat
L P#10.0
+D
LAR2LAR1 AR2
L LD 14
T D [AR1,P#0.0]
LAR1 AR2
L LD 18
T D [AR1,P#4.0]
A Pultadat lenne az UDT, a DATE_AND_TIME az UDT-ben 10. bájtnál kezdődik. A DATE_AND_TIME az L14-től 8 bájt.
Ha valakinek van ötlete, hogy miért nem működik, vagy hogy esetleg hogyan lehet más címzéssel megoldani, szívesen venném. Előre is köszönöm -
Dezsi82
tag
-
Dezsi82
tag
válasz
DP_Joci
#4943
üzenetére
Az a helyzet, hogy univerzális programot még nem készítettem, mindegyik alkalmazásspecifikus. Van olyan, ami SQL szervernek küldi az adatot, illetve olyan, ami rögzített adatokat fogad, és azokat tárolja le. Így sok hasznát ezeknek nem vennéd.
Ugyanakkor valamelyik projektünket egy kicsit ráérősebb időmben átalakíthatom, és mint TCP szerver, vagy kliens el tudja végezni ezt a naplózást. Ez azonban nem Profinetes naplózó, hanem TCP socket alapú. És a PLCben is meg kell csinálni a programozás részét. Ami nem sok, csak annyi, hogy adott időközönként, vagy trigger jelre elküldje az adatcsomagot a megfelelő formában, aztán az alkalmazás elmenti csv formában.
Ha gondolod, ezt szívesen megoldom, valószínű a jövő héten jutna rá időm -
Dezsi82
tag
válasz
DP_Joci
#4939
üzenetére
Üdv!
Az RSlinx legtöbb verziójával elérhető, amit írtál, amit különben DDE-nek hívnak.
Ezt gyári szoftverrel ethernetes PLCnél szerintem OPC szerverrel a legegyszerűbb elérni. De kinek mi az olcsó. Nekem a legolcsóbb, hogy írok egy alkalmazást Delphiben, illetve egy egyszerű programrészt a PLCben, aztán mehet is a naplózás -
Dezsi82
tag
válasz
DP_Joci
#4938
üzenetére
Üdv
Az én esetemben vagy WinCC Flexible vagy Zenon lesz használva.
Elég nagy az esélye a wincc flexible-nek. Azt még ki kell próbálnom, hogy vajon tudok-e olvasni unlinked db-t, vagy sem WinCC Flexible-lel. Ha nem, akkor a PLCbe kell tennem egy függvényt, ami kiolvas egy sort egy elérhető db-be. -
Dezsi82
tag
Üdv Szirty!
Örülök, hogy hasznos infóval szolgáltam. Ha esetleg valaki hasonló megoldásban gondolkodik, akkor a következőket kellet nekem figyelembe venni:
- az MMC élettartama 100 000 törlés és írás ciklus. Vagyis csak akkor írjuk, ha muszáj. Elvileg az MMC kezelő gondoskodik arról, hogy az írás ne ugyanarra a területre essen, így maximalizálva az élettartamot. De nem tudom, hogy vajon ez DBnél is megvalósul-e. Nyílván egy minden ciklusban írás, hamar kinyírja a kártyát. Jómagam úgy csinálom, hogy inkább csak írom, aztán ha 200 év múlva megtelik az MMC, akkor törli a DB tartalmát
- A DB mérete maximum 64 kB lehet, így sok adat tárolásakor lépegetni kell a DBket, esetleg automatikus létrehozásról (SFC85) gondoskodniEttől függetlenül jómagam jobban szeretem, ha a tárolást egy PC végzi, de jelen esetben a felhasználó nem kíván folyamatosan üzembe tartani egy PCt, hanem amikor szükségük van az adatra, kiolvassák, és statisztikákat végeznek.
Ráadásul egy napig keresgettem a netet megoldás után, erre a kérdés feltétele után 5 perccel megtaláltam
-
Dezsi82
tag
Sziasztok!
Lenne egy alkalmazásunk, ami során egy 315 2PN/DP CPU-t használunk. A PLCnek feladata lenne, hogy naplózzon adatot, és nem keveset.
Egy naplóbejegyzés nem lenne sok, max 10 bájt. Viszont jó lenne egy 10 000 rekordot tárolni. Mivel viszont már jó pár adat van a work memory-ben, az már nem fér bele. Lenne azonban egy 8 MB-os MMC. Tudtok valami módszert, hogy adatot tároljak ezen a majdnem üres MMCn, úgy hogy ha kell, olvasni is tudjak belőle?
A segítséget, ötleteket előre is köszönöm -
Dezsi82
tag
Üdv!
Gondolom a PLC programot szeretnéd letölteni (bár általában ezt feltöltésnek hívják) és monitorozni.
Step7-tel biztosan tudod, de talán TIA Portállal is (sokat nem használtam TIA portált)
De túl sokra nem mész ezzel a feltöltött programmal, mert nem lesznek benne szimbólumok. De monitorozni tudod.
Biztonsági mentésként a képernyő részére gondoltál? Ha igen, azt a Simatic ProSave-vel lehet megoldani. -
#4858
Dezsi82
tag
Achilles83
#4857
Dezsi82
tag
válasz
Achilles83
#4857
üzenetére
Üdv
Nem teljesen világos mit szeretnél. Hogy megjelenítsd a maradékot, ami 5? Ha igen, akkor a D2001-t alakítsd át lebegőpontosra. Ugyanis a maradék az R+1 területre kerül ennél az utasításnál. De igazából át se kell alakítani lebegőpontosra, mert a maradék mindig egész szám
Ha 18,5-t szeretnél a kijelzőn látni, akkor pedig a második blokkot felejtsd el, az első blokkba pedig /F legyen az utasítás -
#4850
Dezsi82
tag
RochaShade
#4848
Dezsi82
tag
válasz
RochaShade
#4848
üzenetére
Üdv!
"beírod a megfelelő területre a célpozíciót" mi takar a megfelelő terület?
A lényeget Szirty elmondta, én most kiegészítem néhány számmal.
Ha például a CX Motionben beállítod a W0-t, mint output area kezdő cím, akkor a doksi 187. oldala alapján a célpozíció az a+2, vagyis W2 lesz (32 bit). Azt hogy, ezt hogyan értelmezi a rendszer (impulzus, kontrol impulzus, vagy mm) azt a beállítás alapján dönti el. Itt a kérdés az, hogy mennyire szeretnél számolni a PLC programban, vagy mennyire inkább a szervó paraméterben állítgatsz. Tehát te számolod ki, hogy egy mm hány impulzus, vagy rábízod a szervóra Én inkább saját magam kiszámoltam egy egyszerű szorzással, neked is ezt javaslom. Ez a mm-re állás, úgy gondolom inkább komolyabb gépeknél lehet érdekes, ahol még lineáris interpolációra van szükség.
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?
A szervó nem kapcsolódik a CX-programmerhez. Egyrészt beállítod a mozgásvezérlőt, hogy milyen szervókkal kommunikáljon, másrészt a PLC felé milyen belső címeken kommunikál. Azt, hogy hol van ez a terület, te döntöd el, de az adatok tartalmát, sorrendjét már nem. Annyi a feladatod a CX programmerben, hogy leprogramozod, hogy melyik memóriaterületre mikor mi kerüljön. A szervó paramétereket a CX-Motionnel tudod feltölteni, és nem a PLCre, nem a szervóra, hanem a hajtásvezérlőre(NCF271). Csak annyit jelznék még, hogy én CX Motion NCF-et használtam. Nem tudom mi a különbség, de CX Motionből van egy pár.
a példaprogram alapján abból amit küldtél (441.old) minden mozgáshoz pozicionálásához hasonló létradiagram lesz?
A 441. oldalon egy mozgási utasítás kiadás látható. Az, hogy hova mozogjon, itt nincs leprogramozva. És az sincs, hogy mi a mozgás feltétele, ezt egy "Positioning execution condition" NO kontakttal jelölik. Hogy minden mozgáshoz megcsinálod-e ugyanezt a létrát, az már a te döntésed, mint programozónak, attól függően, hogy milyen vezérlési struktúrát használsz. Bemásolhatod többször ugyanezt a létradiagrammot, de akkor STEP vagy Interlock utasításokkal kell operálnod, vagy esetleg külön taszkokkal.
Én nem így csinálnám, hanem csinálnék egy lépésvezérlést, mondjuk
az első lépésben elindítanék egy abszolút mozgást:
- CIO 2-be beírnám a címet (állítható 0-5 mm-nek megfelelő impulzus)
- H1.0-t igazba állítom
- W0.0-t igazba állítom (a "Positioning execution condition"-t elneveztem W0.0-nak)
Akkor lépek a következőbe, ha 1000.5 igaz
Aztán a következő lépésekben történik, ami kell, munkahengerek, stb
Amikor megint mozogni kell, akkor
- CIO 2-be beírnám a címet (-5 mm-nek megfelelő impulzus)
- H1.0-t hamisba állítom
- W0.0-t igazba állítom
Akkor lépek a következőbe, ha 1000.5 igazMég egy gondolat, ami most jutott eszembe: Abszolút mozgáshoz kell egy nulla pont is, tehát referenciára is kell járatni a szervódat, csak így fogja elfogadni a mozgás parancsot.
-
#4847
Dezsi82
tag
RochaShade
#4846
Dezsi82
tag
válasz
RochaShade
#4846
üzenetére
Üdv
Pontok úgy lesznek (remélem egy tengelyről beszélünk, és nem szeretnél lineáris interpolációt), hogy kiválasztod milyen mozgást szeretnél, beírod a megfelelő területre a célpozíciót. Neked először abszolút mozgást javaslok, majd visszafelé relatívot.
Aztán parancsot adsz a mozgásra. De nézd meg a Section11-et vannak példaprogramok.
A CX-Programmer-ben semmit nem kell beállítanod, csak berakni a konfigba, és beállítani a unit number-t. -
Dezsi82
tag
válasz
13128814
#4841
üzenetére
Üdv!
Azt hittem, hogy egységes dolog ez. Pl. ha én létrában programozok, akkor az minden PLC-n ugyanaz
Csak amolyan kiegészítésként azokhoz, amit Szirty leírt.
Elvileg IEC61131 meghatároz bizonyos dolgokat, amik a PLC-k programozására vonatkoznak. Ennek megfogalmazásában a gyártók is részt vehettek, és az IEC61499 még szigorúbban veszi ezeket, például blokk meghívásokat is.
Ezért aztán van egy utópisztikus gondolat, ami azt mondja, hogy gyártófüggetlenül lehet majd PLC-t programozni. Talán majd egyszer. Addig áll, amit korábban Szirty írt.
Ki is jött már néhány gyártó a saját IEC developer-ével. Amiről tudok és használtam az a Mitshubishi és Phoenix Contact. Ezek éppenséggel talán csak a szoftver kezelésében hasonlítanak (ugyanolyan körülményes), de másban nem igazán. Állítólag ugyanaz a cég fejlesztette nekik az alapot, és a végét csinálták maguk. -
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 -
#4830
Dezsi82
tag
RochaShade
#4829
Dezsi82
tag
válasz
RochaShade
#4829
üzenetére
Szia!
Az alkatrészek nélkül nagyon nehézkes lesz a programozás.
Szerintem az alapvető elképzelés nem rossz, sőt még CP1H CPU is stimmel (rosszzul néztem, mert ő maga nem képes mechatrolinkre, de a pozíciószabályzó modulja igen). Mi is pont így csináltunk egy egyszerű gépet. Használj NC271-et.
CX- Motion NCF programmal tudod beállítani a kommunikációs paramétereket. Itt állíthatod be, hogy milyen címtől kezdve legyenek a tengely parancs, és visszajelző bitjei. Ha a beállítással kapcsolatban konkrét kérdés van válaszolok, de nem szeretnék egy lépésről lépésre leírást készíteni, mert nagyon egyszerű a program kezelése. USB-n fel tudod tölteni a projektet a szervó vezérlőre, de csak a valósra
A Mechatrolinkes modulnak vannak saját bitjei, ezeket ebben a doksiban találod:
http://downloads.industrial.omron.hu/IAB/Products/Automation%20Systems/PLCs/Compact%20PLC%20Series/CP1H/CJ1%20Position%20Control%20Units/W426/W426-E1-10%2BC_1W-NC%2BOperManual.pdf
A section2 és section 4 lesz a legérdekesebb rész számodra.
De a PLC és PCU nélkül sok képzelőerő kell a boldoguláshoz. Bízom benne, hogy elég infót kaptál a kezdéshez, ha elakadnál szívesen segítünk -
#4825
Dezsi82
tag
RochaShade
#4823
Dezsi82
tag
válasz
RochaShade
#4823
üzenetére
Üdv!
Ránéztem a PLCre. Mi kommunikál mechatrolinken? Mert a PLC nem képes rá. Vagy rosszul látom? -
#4824
Dezsi82
tag
RochaShade
#4823
Dezsi82
tag
válasz
RochaShade
#4823
üzenetére
Üdv
Mechatrolinken le tudod kérdezni a szervó helyzetét, és parancsokat is tudsz adni neki a megfelelő címeken.
A következők lennének a feladatok:
- beállítod a szervó vezérlőt
- bemozgatod a megfelelő értékeket
- kiadod a megfelelő parancsokat.Mindegyikben tudod segíteni, a kérdés, hogy mindegyikben kell, vagy csak valamelyik része?
-
#4811
Dezsi82
tag
Bakareszia
#4810
Dezsi82
tag
válasz
Bakareszia
#4810
üzenetére
Üdv!
Ha jól sejtem, Siemens S7-300-ról beszélünk. Én ezeknél egy ciklust csinálok indirekt címzéssel. Átmásolom az egyik címet a másikba, és addig folytatom, amíg az elejére érek.
Másrészt mi lenne a konkrét feladat? Mert szerintem nem olyan gyakran szükséges ez. Lehet van egyszerűbb megoldás is, mint a léptetgetés -
Dezsi82
tag
válasz
KB.Pifu
#4797
üzenetére
Üdv!
De valóban olyan nagy gond az ,hogy szabadidőmben ilyennel is szeretnék foglalkozni?
Egyáltalán nem gond, sőt. És nem is azért írtam, hogy ezt éreztessem, elnézést hogy félreérthető voltam. Inkább egy tapasztalatomat akartam megosztani. Jómagam viszonylag sokszor találkozom olyannal, hogy ciklusidő csökkentés miatt olyan dolgokat kérnek, ami nem szabályos. Lásd ez utóbbi eset, ahol a feladat kiírója saját cégének munkabiztonsági utasításának ellentétmondó kiírást adott.
És igazad van, a legjobb, ha az ember odatolja az előírást, hogy ezt nem lehet. Én sajnos nem tudok ilyen szabálygyűjteményt, ezért írtam ezt a szerintem egyik legfontosabb szabályt.
Ugyanakkor szerintem ez a téma nem teljesen off-topic, mert a gépek biztonsága beletartozik a programozás körébe, még ha érintőlegesen is. -
Dezsi82
tag
válasz
KB.Pifu
#4795
üzenetére
Üdv!
Szerintem az egyik legfontosabb szabály, amit PLC programozóként tudni kell, az az, hogy egy jól megtervezett rendszerben a PLCnek szinte semmi köze sincs a munkavédelemhez. Persze kiír hibaüzenetet, meg bele lehet rakni még plusz biztonságként figyeléseket. De a munkavédelmi körben biztonsági eszközök kell, hogy szerepeljenek (léteznek persze biztonsági PLCk is).
Ha idővel a biztonsági kört is te tervezed, akkor már azt is ismerni kell (milyen kategória, stb) , de amíg kezded a programozást, addig elég ha ezt tudod. -
Dezsi82
tag
válasz
byte-by
#4772
üzenetére
Üdv
Közben sikerült átnyálaznom a cég belső munkabiztonsági szabályzatát, ami egyértelműsítette a helyzetet. Mégpedig nyugtázni kell.
Persze a fényfüggöny mindenképp biztonsági relére megy, ami nyugtázva lesz, de a nyugtázást éppenséggel csinálhatná PLC, vagy láttam már olyan bekötést, ami automata nyugtázást tesz lehetővé.
Jelenlegi terv szerint a fényfüggöny jele megy egy biztonsági relére, egy vészstop gombbal együtt, ha nem ad jelet a relé, akkor a fékes munkahengerről elvesszük a vezérlést, és fékkel rögzítjük. Nyugta után meg megy minden tovább.
Köszönöm a segítséget. -
#4771
Dezsi82
tag
Achilles83
#4770
Dezsi82
tag
válasz
Achilles83
#4770
üzenetére
Üdv
Köszi a plussz infót.
Valójában a kérdésem nem a fénykapu megsértésekor történő reakcióra vonatkozik, hanem arra, amikor kilép az emberke a fényfüggönyből, történhet-e a fényfüggöny terében mozgás nyugtázás nélkül, ha a fényfüggöny folyamatosan látja a veszélyes teret. Mivel nálunk az ajtó nyitása is veszélyes (ív mentén felfele nyílik, és állcsúcson verés könnyen előfordulhat), így a terület megsértésekor az a helyes, ha sehova sem megy.
A történtekre válaszolva, amennyire tudom, közönséges CPU, közönséges bemenetein nem lehet olyan szerepben, hogy munkabiztonságért felelős legyen. Tehát nálatok az lenne a helyes, ha a szelep lenne olyan, ami vezérlés hiányában kinyitja az ajtókat, illetve a munkahenger véghelyzeteiben reteszelt, hogy ne nyíljon ki, ha zárt helyzetben bemennek a függönybe, vagy esetleg némítani a fényfüggönyt, ha zárva az ajtó.
Persze ha a CPU biztonsági CPU, biztonsági bemenettel, akkor más a helyzet -
Dezsi82
tag
Sziasztok!
A következőben kérném segítségeteket:
Nem teljesen programozás, de érinti. Egy olyan feladatkiírást kaptam, aminél az lenne a feladat, hogy egy pneumatikus működtetésű ajtó nyitása, zárása álljon meg, ha belépnek a fényfüggönybe, és amikor kilépnek, automatikusan induljon újra a mozgás. Jelenlegi tudásom szerint ez nem szabályos, hiszen a veszélyes tér elhagyását nyomógombbal (vagy valamilyen más, direkt módon) szükséges nyugtázni.
Próbáltam rákeresni, hogy melyik szabály, szabvány írja ezt elő (ha egyáltalán így van még), de nem jártam sikerrel. Ha valaki tudna linket, idézetet adni, szívesen venném
Köszönöm. -
Dezsi82
tag
Benne van a System Software for S7-300/400 System and Standard Functions Volume 1/2-ben is:
You use SFC 20 "BLKMOV" (block move) to
copy the contents of a memory area
(= source area) to another memory area (= destination area).
Permissible source areas are the following:
•Parts of data blocks
•Memory bits
•Process-image partition (part process image) for inputs
•Process-image partition (part process image) for outputs -
Dezsi82
tag
válasz
KB.Pifu
#4723
üzenetére
Üdv
Valóban nincs a Mitsubishinek intelligens súgója (legalábbis a GX Developernek, amit én használok), de azért vannak súgófájlok (legalábbis egy jogtisztának, egész biztos) ami a súgó menüből elérhető. De én is jobban kedvelem az Omron súgóját, Viszont tapasztalataim szerint a Mitsubishi és az Omron nagyon sokban hasonlítanak (mindkettő japán, hasonló a gondolkodás), sokkal jobban,mint Siemens és Omron.
A példa amit írtál, érdekes. Az L terület a Latch terület, vagyis megőrzi a tartalmát, kikapcsolás után is.
A szorzás már érdekes dolog, én két esetre tudok gondolni:
- az M területet is lehet kezelni számként, ilyenkor mögé kell írni hány digitet akarsz címezni (ha jól emlékszem). pl M10K2, ami egy 8 bites integer. Tehát lehet, hogy összeszoroz két ilyen számot, és kiírja retentív területre
- a másik, hogy a két bittel XOR műveletet hajt végre, és ezt menti retentív területre. Bár nem találtam meg a XOR műveletet Mitshibishire, de lehet könnyen be lehet nézni szorzásnak -
Dezsi82
tag
válasz
KB.Pifu
#4720
üzenetére
Üdv!
Nem, Omronnál azért egy kicsit másként működik. Alapvetően Omronnál nem beállítható, hanem a H terület szolgál adatmegőrző területként, illetve a D terület, ami megőrzi a tartalmát, de az mindig.Én úgy gondolom, hogy az Omron és a Siemens PLC nagyban eltér egymástól. Minimum a memóriacímzésben, hiszen míg az omronnak Wordos a memóriaszerkezete, addig a Siemensnek bájtos. A legértékesebb címben is eltérnek. Míg az Omronnál a felső bájt az értékesebb, addig Siemensnél az alsó. Amíg siemensnél az egyes funkcióknak, mint kommunikáció, stb függvények vannak, addig Omronnál a megfelelő címekre kell a megfelelő értékeket beírnod.
Nyilván, mivel mindkettő PLC, ezért vonatkoznak rájuk bizonyos szabványok, amelyeket a gyártóknak be kell tartani, ezért nagyban egyeznek, de azért sok az egyedi vonás. Ha valaki tud PLCt programozni, akkor tudja mindegyik PLCt programozni. Kérdés, hogy mennyi idejébe telik, mire az adott gyártó saját tulajdonságait megszokja.
-
Dezsi82
tag
Üdv!
Részemről az, hogy "csak" nem retentív területen működik egyáltalán nem komoly hátrány. Tény, hogy nem találkoztam még olyan S7-300s CPUval, ahol mindegyik terület retentív, és ebben esetleg hibáztam. De találkoztam már jó pár S7-300s CPUval, így úgy gondolom ez nem lehet nagyon gyakori. De nyilván tévedhetek.Még szép, hogy ajánlom a megoldásom, hiszen az elmúlt 14 évben még egyszer sem okozott gondot.
-
Dezsi82
tag
Üdv!
Részemről nem volt semmi probléma a gondolatmeneteddel, teljesen igazad van, ha retentív területet választ az ember nem fog működni. Teljesen felesleges tesztelnem, tisztában vagyok vele, hogy így fog működni, ahogy azzal is hogy teljesen hibátlanul működik, ha nem retentív területen használja az ember.Én úgy gondolom, hogy nincs abszolút jó megoldás egy feladat leprogramozásánál. Nyilván rosszak vannak, de a programozás épp egy olyan feladat, ahol a programozó döntésére van bízva, hogy mit, hogyan programoz le. Láthatjuk másként a dolgokat, megvitathatjuk az ezek egymással szemközti előnyeit, hátrányait, de alapvetően mindenki maga dönti el, hogy melyik megoldást használja a saját programjában. Én sosem fogom használni az OB-s megoldást, de sosem a felejtő memóriaterületet. És nincs ezzel semmi baj.
-
Dezsi82
tag
Üdv.
Hát ennyi erővel az sem megfelelő, ha OB100-ban van, mert ha valaki írja azt a bitet (amit Te is írtál), akkor ugyanúgy megszívja.
Vagy ha mondjuk az ember a clock byte-ot állítja be úgy, hogy átfedésben legyen ezekkel a bitekkel. Vagy MPI Global Datának, de szerintem lehetne még sorolni.
és nem kell külön merker bit sem a -(P)- miatt.
Külön bit ugyan nem kell, csak külön OB.
Persze, hogy nem lehet ész nélkül programozni, de ez nem csak erre a feladatra igaz. -
Dezsi82
tag
válasz
plutokas
#4702
üzenetére
Üdv!
A korábban vázolt megoldások is tökéletesek, de én máshogy szoktam.
Két megoldást alkalmazok:
- Általában szoktam használni egy mindig1 és egy mindig0 bitet is. M0.0 a mindig hamis, M0.1 a mindig igaz, és M0.2 az első scan
Az OB1 első sorai:
- Vagy ha nem akarom cifrázni, akkor az ob1 utolsó sorában setelek egy bitet, ha ezt negáltan lekérdezem a programban, akkor ez egy első ciklus bit -
#4693
Dezsi82
tag
Achilles83
#4691
Dezsi82
tag
válasz
Achilles83
#4691
üzenetére
Üdv!
Nem lehet, hogy az a gond, hogy a kommunikációs egység csak soros kommunikációt tud, a CPUn lévő DSUB9 meg hétfélét, a Peripherial meg 4 félét, és nem sorosra van állítva az a port ahova dugod? -
Dezsi82
tag
válasz
soldi3r
#4686
üzenetére
Én is úgy gondolom, hogy nem teljesen korrekt eljárás, de szerintem se várjon el korrektséget, az, aki inkorrekt a beszámítóval szemben.
byte-by:
Hidd el, csak pszichológiai értéke van egy ilyen szerződésnek, nálunk is így vannak megírva a papírok. Ha nem fizet, futhatsz a pénz után. Egy nagy cég nyilván nem fog eltűnni a föld színéről egy ki nem egyenlített számla miatt. Így aztán 2-3 év után valószínű kiegyenlítik. Ha van az adott cégnek annyi tartaléka, hogy ez a kiesett bevétel nem terheli meg, akkor ok. Az én előző munkahelyem azért szűnt meg, mert negyed éves munkát nem fizetett ki egy amerikai multi cég. Persze utána már egyenlített volna, de akkor már nem volt kinek.
Olyan ez mint az elsőbbség adás. Ha valakinek nem adják meg, mindenki neki ad majd igazat a temetésén -
Dezsi82
tag
Üdv
Ez egy nagyon szép elképzelés, de nem működőképes.
Pereskedés előtt azért vannak más lehetőségek.
Ilyen a fizetési meghagyás, ezért persze először ki kell fizetned a közjegyzőt. Az illető 4 válasszal élhet:
- nem ismerem el a tartozást -> irány a bíróság
- elismerem a tartozást-> inkasszó a számlára, ha van ott annyi (ált nincs)
- elismerem a tartozást, de nem fizetem ki -> irány a bíróság
- nem válaszol-> inkasszó, lsd feljebbSzóval bíróság, előre fizeted az eljárást. Megítélik. Onnantól kezdve előre fizeted a behajtókat, a bíróságot. Megduplázod a költségedet, és mid van? Egy papír, hogy jogosan nem vagy a pénzednél. Sajnos saját tapasztalat, két éve nem tudunk behajtani egy tartozást. És az van, amit írsz, szarakodás. Eredmény nélkül. Közben a dolgozóknak fizetést kell adni, egyéb költségeket kiegyenlíteni. Ebbe simán tönkre mehet egy cég.
Én úgy gondolom, hogy teljesen jogos egy ilyen fellépés. Amúgy is halasztott fizetés van, egy ilyen gép akár ki is termelheti az árát a határidőig.
Bonyolítja a helyzetet, hogy nyilván, ha a gép áll, akkor talán a megrendelőnek sincs lehetősége kiegyenlíteni a számlát.
-
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 -
Dezsi82
tag
-
Dezsi82
tag
Üdv
Ez valóban így van.
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. Mivel a cég, ahol gyakorlatot tudna szerezni, nem tudja alkalmazni, elmegy egy multihoz, ahol a termelés a fő tevékenység. Ott persze hibakeresés a feladat, de azt azonnal. Egész nap gyakorlatilag nem csinál semmi érdemit, ha hiba van, akkor meg nem fűlik hozzá a foga. Aztán ha be kell nyúlni az olajos gépbe, hogy beállítson egy pozíciószenzort, akkor meg azt mondja, hogy ő nem villanyszerelő.
És úgy gondolom, ezért is gyakori a karbantartói tapasztalat, hiszen az ilyen helyeken lényegében a programozási feladat hibakereséssé zsugorodik, és azt azért viszonylag hamar el lehet sajátítani. Legalábbis amíg egy elállítódott szenzort kell megtalálni. -
#4665
Dezsi82
tag
Achilles83
#4660
Dezsi82
tag
válasz
Achilles83
#4660
üzenetére
Üdv
De a mérőhidas megoldás is jó.Igazából nem értem miért csinálnak méregdrágán távadó átalakítókat.
Úgy van, ahogy Szirty mondja. Ha otthonra kell, és van időd, kedved, hozzáértésed kicsit barkácsolni, és elfogadod, hogy a pontosságod csak mondjuk 0.5 °C (ami egy otthoni alkalmazásnál simán jó), és te illeszted villamosan a rendszeredbe és finomhangolod, akkor nem kell használni átalakítót, .
Ha mondjuk egy gyógyszergyárba mész, ahol jóval fontosabb a pontosság, nincs idő arra, hogy az ember kikísérletezzen egy ilyen eszközt , mert 200 db használsz belőle, és fontosabb az, hogy bedugod, és megy, akkor meg kell venni a távadót.
Annak meg megkérik az árát, mert felelősséget vállalnak érte, időt szánnak a tökéletesítésre, és beleépítik tapasztalataikat. -
#4659
Dezsi82
tag
Achilles83
#4654
Dezsi82
tag
válasz
Achilles83
#4654
üzenetére
Üdv
Ha csinálsz belőle egy mérőhidat, akkor megoldható -
#4649
Dezsi82
tag
Achilles83
#4648
Dezsi82
tag
válasz
Achilles83
#4648
üzenetére
A kérdésem az lenne, hogy az analóg jelek azok milyen címzésen fognak megjelenni?
Az attól függ, hova rakod. A PLC IO tableban tudod konfigolni a hardvered. Ott kiírja a címet is.
ha hőmérsékletet akarok szabályozni akkor az hogy tudom átskálázni ha fokban akarom látni az értékeket
Ez sok mindentől függ. Milyen az analóg bemeneted, milyen tartományú a hőmérséklet távadód. De pl a kártya maga is tud skálázni, szintén a PLC IO-ban konfigolható -
Dezsi82
tag
Üdv!
Szerintem ezt úgy tudod megvalósítani a lehető legkevesebb hardver befektetéssel (feltételezve hogy a tablet, és a PLC már adott), hogy úgy nevezett soros-ethernet szervert teszel a kettő közé. Ez hasonló a konverterhez, csak annyiban tér el, hogy szöveget küld a PC/tablet a szervernek, az átalakítja sorosra, de még mindig szövegként és elküldi. Majd ugyanez visszafelé. Így aztán ha beállítod a szervert a 80-s portra, és a PLCben leprogramozol egy webszervert, akkor böngészőn keresztül máris tudod vezérelni tabletről a PLC-t.
Elég melós megoldás, mert hát nem kis meló bepötyögni a webszerver részét a PLC-be (nem nehéz, csak időigényes). A legjobb és legprofibb megoldás a Szirty által javasolt épület automatizálási vezérlő lenne. Nem tudom ezek mennyibe kerülnek,de egy ilyen soros ethernet szerver kb 30ezer körül mozog. -
Dezsi82
tag
Szia!
Ezek az eszközök általában úgy működnek, hogy feltelepül a soros driver, amit ugyebár tud értelmezni az általad használni kívánt program. A driver megkapja az elküldendő adatot, átalakítja TCP streamre, majd az átalakítód vissza alakítja soros jelekre.
Amit te szeretnél, ha jól értem az, hogy, az első lépést kihagyva, a géped már egyből átalakított adatcsomagokat küldjön ki az ethernet porton. Ez teljesen esélytelen, egész biztos hogy a két kommunikáció paraméterei, protokollja, mindene megegyezzen.
Az általam használt Helmholz átalakító is drivert használ, ami beépül a Set PG/PC inteface-be, és így lehet használni.
Más különben nem is látom semmi hasznát annak, hogy a driver kihagyása nélkül tudj kommunikálni. Mi lenne ennek értelme, miért szeretnéd kihagyni ezt a lépést? -
-
Dezsi82
tag
Üdv!
Nekem lenne pár kérdésem a rajzhoz.
- hova kellene kötni a lámpát? Ha jól sejtem az R2 be nem rajzolt kontaktjára
- ez hogyan működik pontosan? Számomra úgy tűnik, hogy amikor megnyomom a gombot, akkor R2 meghúz, ilyenkor R1 mindkét pontja 24Vra kerül. 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? Aztán amikor meghúz R1, akkor az R2 két pontja kerül ugyanarra a potenciálra, és kiesik? Szóval nekem nem világos, hogy hogyan kellene működnie, szívesen vennék egy kis leírást
Köszi -
Dezsi82
tag
Üdv
Érdekes, hogy ha ESA runtime-t használok egy olyan PC-n ahol van excel, akkor xls-t is tudtam írni, de a panelon nem.
Ennek az az oka, hogy a VB Script az office telepített objektumait használja (talán OLE). Ez az offica-szal települ fel. Nincs office, nincsen OLE. Ha jól emlékszem, akkor talán megoldható, hogy ha az adott op rendszerbe bemásolod a megfelelő DLL-eket, akkor is tud menni az Excel-be írás. De hogy miket kell másolni, arról fogalmam sincs. -
Dezsi82
tag
válasz
dave0825
#4577
üzenetére
Üdv!
Utoljára fősuliban csináltam ilyesmit, de sikerült összehoznom egy kapcsolást. Azt nem tudom rendelkezésre állnak-e a megfelelő számmal kontaktusaid, de ha más nem plussz relékkel meg tudod oldani. Lehet van egyszerűbb megoldás is. Ez egy lépésvezérelt megoldás, ami elvileg működik.
Való életben én egy SR tárolóval oldanám meg, vagy esetleg ezzel
Kis leírás:
Amikor feszültséget kap a rendszer K4 meghúz. Amikor megnyomod a gombot, akkor LED bekapcsol, és K1 öntartásba megy. Amikor elengeded, K2 meghúz,és öntartásba megy. LED világít, mert K1 tart. Amikor újra megnyomod, K3 kapcsol, és öntart, K1,K2 kiesik, lámpa kialszik. Amikor elengeded, K4 meghúz. És elvileg indul elölről a folyamat -
Dezsi82
tag
válasz
Kopri 62
#4565
üzenetére
Szia!
Beírtam a google keresőbe, hogy modbus tcp logger, és ezt adta ki:
http://sourceforge.net/projects/plclogger/
Elvileg tudja, amire Neked kell (bár azt nem tudom pontosan mire van szükséged). Nem próbáltam ki, csak a leírását olvasgattam.
Ha nem tudja, akkor privát üzenetben meg tudjuk beszélni, hogy mire lenne szükséges, és mik a lehetőségek, mert mi tudunk ilyen alkalmazást készíteni -
Dezsi82
tag
válasz
Kopri 62
#4562
üzenetére
Szia!
Anélkül, hogy részletesebben ismerném a Schneider szoftvereket (eddig egyszer programoztam), én a következőket mondanám:
-nyilván van a Schneidernek SCADA szoftvere, azzal biztos megoldható. Ajánlottak is annak idején nekünk ilyen szoftvert, tud SQLt is, de amennyire emlékszem, jó ára van. Persze ha ez rendelkezésre áll, akkor nem kérdés
-léteznek kimondottan naplózó szoftverek (én a PLC analyzer Pro-t ismerem), ezzel csak beállítod a paramétereket és megy is. De ez is fizetős. És csak fájlba tud menteni, és megjeleníteni
-írsz saját magad egy naplózó szoftvert, persze ehhez kell ismeret, meg szoftver. De gondolom ez a CPU is ismeri a Modbus TCP-t, és egy egyszerű socket kommunikációval lekérhetőek az adatok, majd fájlba írhatók, SQLbe küldhetők, megjeleníthetők.
Ezek akkor működnek, ha nem kell túl gyorsan naplózni. Kommunikációs processzortól függően max kb. tízszer lehet másodpercenként így adatot menteni. Ha ennél gyorsabb kell, akkor a PLCnek kell pufferelni, majd a PCnek küldeni. Vagy olyan ipari kommunikációt kell használni, amire mind a PC, mind a PLC képes. -
Dezsi82
tag
Üdv
A helyzet a következő:
Ennél a cégénél Siemens PLCk vezérelnek robotos hegesztőcellákat. A cég autóipari beszállító, több autógyárnak is szállítanak. Többféle terméket gyártanak, mint amennyi ilyen robotos cellájuk van. Ezt úgy oldják meg, hogy az asztalok, amin a robotok hegesztenek, cserélhetőek. A szerszámokon érzékelők, munkahengerek vannak. Ezek ET200-ba, SMC szelepszigetekbe, stb vannak bekötve. De a szerszámok különbözőek, ezért más-más a hardver konfig, ezért van az, hogy SFC12-vel deaktiválnak, aktiválnak, slaveket. Minden szerszámhoz tartozik egy-egy FC, ami a lefutást végzi. Becsukási sorrend, darabérzékelés, stb. Amikor jön egy új szerszám, egy új termékhez, hívnak minket, leprogramozzuk.
Viszont a robotok, és a hegesztőszerszámok sem egyformák, ezért gyakran előfordul, hogy csak átrakásról szól a feladat, attól függően hogy a termeléstervezés, hogyan igényli. De gyakran beleütközünk abba a problémába, hogy a cellákban a hardver konfigban az adott szerszámon lévő slave címe már használt, ezért át kell állítgatni annak a címét. És kezd a helyzet kaotikus lenni. Nem beszélve arról, hogy ugyanaz a szerszám egy másik cellán más néven szerepel, vagy egy szerszám több "programban" is benne van. A kiválasztott program adja meg, hogy milyen hardver konfig töltődjön be. Igen ám, de ezek van, hogy beraknak egyik oldalra Suzukit, másik oldalra Audit, aztán másnap Suzuki Mercedes-szel, harmadnap megint más. Emiatt aztán sokféle program van, ami a különböző konfigokat párosítja össze, és már senki sem tudja, hogy melyik kombináció mit takar pontosan.
Ezért arra gondoltunk, hogy beillesztünk a cella CPU-ja, és a változó hardver konfig közé egy CPU-t, amiben van DP master és DP slave interfész is. A master kezeli a szerszámon lévő slaveket, tartalmazza a szerszám programját a slave pedig kommunikál a vezérlő CPUval. Így ha csinálunk egy univerzális programot az összes cella vezérlő PLC-jébe, ami azokat a memóriaállapotokat kérdezi le a szerszámban elhelyezett CPUtól, és a szerszám FC-je a szerszámon lévő CPUn futna, akkor elég lenne egyszer megírni a szerszám programját.
A lényeg tehát az, hogy két hálózat van, és ezek közti átjárás kell megoldani. A multimasteres rendszer is működhetne, de itt a címekkel lenne megint probléma. Az általad javasolt DP-DP coupler megoldás teljesen tökéletes. Azt még nem tudom, hogy viseli a coupler, hogy az egyik oldalán hardveresen megszakad a vezeték, és nem látja a masterét, de ha jól gondolom, akkor, amint felcsatlakoztatják a mastert, akkor helyreáll a kommunikáció, és minden működik. De ahogy írtad, nem kell vacakolni címekkel, aktiválással, lekérdezésekkel. -
Dezsi82
tag
Üdv
Átnéztem az SFC51-t, és egy paramétert találtam, ami esetleg szóba jöhet, de sajnos ez sem tesz különbséget
0291 Module status information of all faulty and non-deactivated modules IrrelevantViszont keresés közben megtaláltam az SFC13 paramétereit:
Byte 1: Status 1
Bit DIAGNOSTIC
0 Diag.Station_Non_Existent: Set to 1 by the master if slave cannot be reached over the line. Slave sets this bit to 0.
1 Diag.Station_Not_Ready: Set by slave if slave is not ready for data transfer.
2 Diag.Cfg_Fault: Set by slave if it detects a mismatch in config data.
3 Diag.Ext_Diag: Set by slave to indicate a diagnostic entry is in the slave-specific diagnostic area (see below).
4 Diag.Not_Supported: Set by slave if requested function/service is not supported.
5 Diag.Invalid_Slave_Response: Slave sets this bit to 0. Set to 1 by the master if it receives an implausible response from the slave.
6 Diag.Prm_Fault: Set by slave if last parameter frame was faulty (wrong parameterization, bad length, bad ident_number, etc.).
7 Diag.Master_Lock: Set by a class 1 master to indicate slave has been parameterized by another master (if address in DU byte 4 is not 255 and differs from its own address). Set to 0 by slave.Byte 2: Status 2
Bit DIAGNOSTIC
0 Diag.Prm_Req: Set by a slave if it needs to be parameterized and cleared once parameterization is complete.
1 Diag.Stat_Diag: Static diagnostics. Slave sets this bit to cause the master to retrieve diagnostic information until this bit is cleared (the slave sets it if it’s not able to provide user data).
2 Slave sets this bit to 1.
3 Diag.WD_ON: Set by slave to indicate Watchdog is active.
4 Diag.Freeze_Mode: Set by slave after it has received the Freeze control command.
5 Diag.Sync_Mode: Set by slave after it has received a Sync command.
6 Reserved.
7 Diag.Deactivated: Set by the master if slave has been marked inactive within the slave parameter set and is removed from cyclic processing. Slave sets this bit to 0.Elvileg az elérhetőséget mutatja az első bájt nulladik bitje, a deaktiváltságot a második bájt hetedik bitje. Azt tudom, hogy az SFC12 időigényes függvény, van hogy akár több tíz másodpercig fut. Arról nem találtam infót, hogy az SFC13 milyen gyorsan fut le, és sajnos tesztelni nem fogom tudni, így majd élesben kell megoldani.
Ha esetleg Te tudsz olyan SFC51 paraméterezést, ami kiadná a deaktivált, és a hiányzó slaveket, külön-külön, akkor az hasznos lenne, mert nyilván gyorsabb lenne, mint pollozni a 30 slavet.
Köszönöm az ötleteket -
Dezsi82
tag
Sziasztok!
Joci: Azért nem oszthatok szét 2 db címet a 30, amúgy egyforma CPUk között, mert akkor két egyforma című szerszámot nem tudnának egyszerre felrakni, és ez biztos elő fog fordulni. Jó lenne tudni, milyen profibus diagnosztikára gondoltál, mert ha FB125, akkor leírás alapján nem tesz különbséget a deaktivált, és a hiányzó slavek között.Szirty:
Mit értesz pontosan configban szereplő deaktivált eszközön?
Azt értem, hogy benne van a konfigban, de SFC12-vel deaktiválva van. Ez pontosan arra szolgál, hogy más-más programszámhoz más-más profibus hardver konfig tudjon tartozni. Így nem fogja hiányolni a bekonfigolt, de nem csatlakoztatott slaveket, és profibus hiba sem lesz. Az SFC51-et átnézem, van-e olyan paraméter, ami alapján el tudom dönteni, hogy egy eszköz ott van, de deaktivált, vagy tényleg nincs ott.
Új hozzászólás Aktív témák
- Milyen TV-t vegyek?
- Kodi és kiegészítői magyar nyelvű online tartalmakhoz (Linux, Windows)
- Tőzsde és gazdaság
- Debrecen és környéke adok-veszek-beszélgetek
- Képregény topik
- PlayStation 5
- Projektor topic
- Tiltott témává tenné Kína az öngyilkosságot az AI számára
- 3D nyomtatás
- Facebook és Messenger
- További aktív témák...
- Olcsón! LG 34WR55QC-B 100Hz 21:9 UltraWide USB-C PD Machez is! Gari: 2027.áprilisig.
- Liquid Freezer III 360 - használt, garancia: Alza 2031.02.16-ig - ALKUKÉPES.
- Asus Rog Strix G513 144hz Laptop Eladó!
- Mobil LTE hotspot router TP-Link M7200 V4 4G/LTE 150Mb/s,WiFi 2,4GHz 300M
- Four Connect Stage2 2x10mm2 prémium hangfalkábel Nakamichi banándugókkal
- Dell Latitude 5530 i7-1255U 16GB 512GB 15.6" FHD TouchScreen Nagyakksis! 1 év teljeskörű garancia!
- Keresek Xbox Series S / Series X / Playstation 5 konzolokat
- BESZÁMÍTÁS! ASUS H510M i5 11500 16GB DDR4 512GB SSD RX 6600XT 8GB Zalman T4 Plus Cooler Master 700W
- HIBÁTLAN iPhone 13 mini 128GB Blue -1 ÉV GARANCIA - Kártyafüggetlen, MS3139
- BESZÁMÍTÁS! SAPPHIRE B650M R7 8700F 32GB DDR5 512GB SSD RX 6800 16GB Zalman S2 TG GIGABYTE 750W
Állásajánlatok
Cég: Laptopszaki Kft.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest