Keresés

Új hozzászólás Aktív témák

  • #95092224

    törölt tag

    Szijasztok,

    Akaratom ellenére csöppentem bele PLC programozási kérdésekbe, amikhez annyit se értek, mint tyúk az ABChez. Számítógépes vagyok. A segítségeteket szeretném kérni elvi dolgok megítélésében. Annyi a feladat, hogy ugassatok le, ha butaságokat írkálok.

    A feladat (újabb típusú) PLC vezérlő összekötése számítógéppel adatok átküldése végett. PLC oldalon - amennyire tájékozódni tudtam - a digitális i/o modul az, ami legáltalánosabban mindenütt rendelkezésre áll, vagy olcsón beszerezhető még több. Erre tippeltem HW alapnak (jó? / rossz?). Fizikailag erről kellene kiküldeni elektromos jelet.

    Az egyik tippem, hogy a kimeneti jeleket párhuzamos üzemben be lehet állítani 0/1 szintekre, és kvázi több bitet egymás mellé szervezve párhuzamosan el lehet küldeni egy bináris számot. Mondjuk ebből az egyik bit lenne a szinkron. A többit időben előbb beállítani, és ha azok stabilak, bebillenteni a szinkron bitet is, és úgy hagyni a biteket mondjuk 8-10 mS időre. A PC ebből tudná, hogy az adat most érvényes, aztán a szinkron bitet törölni, mielőtt a többi bit bármit is változna. Az eljuttatása PC-hez most nem fontos, csak a PLC oldali szoftvertechnika a kérdés.

    Második tippem fogni egy ilyen i/o jelet, ami mondjuk 0.5 másodpercig nyugiban van, azután kb 3-400Hz-es frekivel (max ennyi használható) kapcsolgatva 0/1 állapotok között kiküldeni rá valahány impulzust, mondjuk max 100-at, és a másodperc másik 75%-ban már csöndben maradni. Az a szám 0-100 között a küldött adat valamilyen kódolásban.

    Harmadik tippem, ugyanúgy egy jelvezetékes. Valamennyi ideig "csönd": 0 értéken a jelvezeték, azután pld 10mS időosztásokban számolva kiküldeni egy valamilyen hosszú impulzust a kimenetre: 1-be kapcsolni valamennyi időre, azután persze vissza 0-ba. Egy max tized másodperces impulzussal (100mS) át is lehet küldeni egy számot 1-10 értékkel.

    Megvalósíthatóak ezek? Ha igen, sorrendbe kellene őket tenni, hogy kizárólag a PLC oldali egyszerű és hatékony programozás szempontjából, melyik mennyire egyszerű / bonyolult.

    Köszi.

  • #95092224

    törölt tag

    Vegyünk alapul egy siemens s7-est, amibe semmi ilyen nincs beépítve. Ami modbus/profibus van is benne, az más célra már használatban van.

    Azok a konverter modulok mibe kerülnek? Egy digit i/o mibe kerül? Árlistából egy darabot se láttam sehol.

    Edit: modulokból din sínre szerelhetőt találtam 33k hufért rs232/485 over tcp-t, de az a legszutyokabb fajta. A normális 80 rugóba kerül, de emellé még kell a szekrénybe a soros port is. Modbus/tcp-t meg egyáltalán nem találtam még névlegesen sem létezni.

    [ Szerkesztve ]

  • #95092224

    törölt tag

    Általánosságban érdekelne tapasztalat PLC részegységeket illetően, hogy mennyire általános, illetve ritka dolog egy részegységnél, hogy az egyébként egyenáramú tápkábelt nem megadott polaritással, hanem akár fordított polaritással is be lehet kötni. Pld 24V DC a betáp, és tök8, hogy a 2 luk közül melyikbe megy a plussz, és melyikbe a mínusz.

    A kérdés nem korlátozódik sem vezérlő típusra, sem részegység típusra. Általánosságban.

  • #95092224

    törölt tag

    válasz Szirty #875 üzenetére

    Eszköz tervezési elgondolás ihlette. Ha a betápot tetszőleges polaritással lehet bekötni, az egy kényelmi szempont. Éshát lehet ilyet csinálni, bizonyos problémák által. Annyi a gond, hogy a bemenetre kell egy diódahíd. Ha az egész dobozolás alapvetően műanyag, vagy legalábbis kettős szigetelésű, és nincs galván kapcsolat a házzal még akkor se, ha fém, akkor a betáp GND-nek nem muszáj feltétlenül 0 volt potenciálnak lennie. Elfogadható, hogy egy dióda nyitófesz megemelje a készüléken belüli GND potenciált.

    Egy nagy baj van vele. Ha nem minden kimenete galvanikusan elválasztott, és kap egy földhurkot. Akkor bizony a bemeneti GND oldali dióda turbo sebességgel elhasználódik / elég a fenébe.

    Szóval megkérdeztem, átlag csinálnak-e ilyet periféria jellegű eszközöknél, mert ha igen, én is olyanra tervezek. De ezek szerint nem általános dolog, és én is inkább hagyom a fenébe.

    Semmi ördöngösség :N

  • #95092224

    törölt tag

    Szirty:

    #796-ban Macys szembetalálkozott egy problémával. Nem két napja volt már, de nem is kimondottan az ő problémájáról van szó, hanem hogy az a probléma mennyire általános?

    Az általánosat úgy értem, hogy magyarországi gyakorlatban (úgy egészében statisztikai átlag szintjén) mennyire komoly probléma, hogy valamilyen régi / olcsó / mit-tudom-én-miért-nem-jó típusú plc-t akarnak összekötni számítógéppel, és nem csak nincsen rá kiépített lehetőség, hanem szakember se tud rá javaslatot tenni.

    A komolyat pedig részemről úgy definiálnám, hogy nem csak az agyonhajszolt technikus zsörtölődik (tuti, hogy mindig agyonhajszolják, és mindig mindenen zsörtölődni fog, de az még az üzemszerű eset), hanem már a főnökének is elkezdi csípni a szemét az, ami miatt zsörtölődik. Sőt, talán management szintjén is felvetődhet a probléma, hogy elmaradott a termelési logisztika. Az a probléma pld hamarabb kezdi majd el csípni a főnök szemét. Tudom, nem ez a világ legprecízebb definíciója a komoly problémát illetően, de perpillanat ez a leggyakorlatiasabb, amit ismerek.

    Ez az egész jellegében olyasmi, amit egyszerűen csak érezni tud valaki, ha eltöltött pár évet a terepen. A legelső dolgot írd le nekem plz, ami most hirtelen az eszedbe jutott a kérdésem egészéről.

    Köszönöm.

    [ Szerkesztve ]

  • #95092224

    törölt tag

    válasz kazmer71 #902 üzenetére

    Licitálni??? Munkalehetőségre? Bakker ez a legjobb HR-es vicc, amit az elmúlt hónapban találtam :))

  • #95092224

    törölt tag

    válasz Szirty #901 üzenetére

    Szirty:

    Elárulom, miért kérdeztem. Van egy project, ami tervezet szintjén elkészült (kész kapcsrajz, kész firmware folyamatábra, de még nincs sorozatgyártásban). Kicsit csücsül, ahogy az lenni szokott ("elküldtük a központba...", bla-bla-bla). Annyi a móka, hogy amíg csücsül, addig még faraghatok rajta elektronikai oldalon.

    Összefoglalva egy ethernetes jelvezeték konverter lesz. Fő szempont az volt, hogy olcsó legyen (áfás áron 20 rugó alatt marad). Második szempont az volt, hogy semmiféle kevert ismeretet ne követeljen meg a felhasználása. Szét kellett választani, hogy a PLC-t is, és a számítógépet is csak a saját szakija programozza, és egymás munkájához ne kelljen érteniük.

    Szóval amin jár az agyam, hogy kifelejtettem-e valamit a listáról, amire még gondolhatnék, és ami sokat segítene majd a jövőben, hogy könnyebb legyen egy elkészített eszköznek piacot bővíteni.

    Régi PLC-knél azt alapértelmezettnek vettem, hogy ha "ködösítetten" van csak ledokumentálva valami (vagy egyáltalán nincs), akkor kell a saját szakija a PLC-nek, aki elektronikailag ismeri. Ha az az ember is elveszett már, akkor az egész munkagép egyébként is kuka, mert épp csak egyszer meghibásodik, és úgysem fogja megjavítani senki.

    Amikre eddig gondoltam:

    -Érzékelni tud feszültség impulzust 5V..30V tartományban alacsony áram terheléssel (ebben a tartományban van meg a worst case méretezés).
    -Vannak fogyasztás mérő órák, azoknál tipikusan opencollector impulzusok vannak, azokat tudni fogom megszámlálni.
    -Felhasználható lesz akár épületgépészetben 24V-os mágneskapcsolók behúzására is, ha valakinek arra fog kelleni.

    Ha akad valami tipped, mire lenne még jó gondolni, hálás köszönetem minden tapasztalt tanácsodért.

    Ja igen, a célpiacok sorában nyilván nem szerepel majd az a cég, ahol egyben kipengetnek 100milcsit, és a legújabb PLC-ket fogják kompletten teleszórni modbus/ethernet konverterekkel, plussz a kész szoftver rendszert is egészben megveszik hozzá. Az a cég nem tud célpont lenni. De ugye nem csak ilyen cég van Magyarországon.

  • #95092224

    törölt tag

    válasz Szirty #905 üzenetére

    Hali Szirty,

    Mostanra már a prototípus építés kérdéseivel bajlódom.

    Egy ethernetes "megdrótozó" lesz. Ennél szemléletesebben nem tudom leírni. RJ-45 az egyik oldalon, sorkapcsok a másikon. Olyasmi, mint az ADAM modulok.

  • #95092224

    törölt tag

    válasz Szirty #907 üzenetére

    Igen.

    Az egyik legkézenfekvőbb lehetőség egy adat gyűjtő szerver. PC, MAC, VAX / VMS, bármi, ami intelligens ethernetes kommunikációra programozható.

    [ Szerkesztve ]

  • #95092224

    törölt tag

    válasz Szirty #909 üzenetére

    Valószínűbb, hogy a fogalmazó készségemmel van a baj. Ezen a terepen kezdő vagyok, nem ismerem a szakszlenget, pedig most jól jönne. Szóval nem tudtam elmagyarázni. Sebaj. Már amúgy is eldöntöttem, megkockáztatom, hogy megyek a magam feje után. A kockázati idő és pénz nem jelentős.

    Egy szereléstechnikai tippet viszont had kérjek. Sorkapcsok. Mint kiderült, ez sem olyan egyszerű, mint hittem. Fotó:

    Sorkapocsba a vezetéket úgy rögzítik, hogy belecsavarozzák. Különbség viszont, hogy az a sorkapocs már eleve rögzítetten része egy eszköznek (pld a jobboldali apróságok fixen be vannak forrasztva), vagy az eszköznek csak egy aljzat a része (középen a csapsorléc, ami be van forrasztva), és abba dugaszolható sorkapcsokat csatlakoztatnak (bal oldali részlet). A dugaszolós kivitel is létezik nem csak ilyen szélesben, hanem 2 vezetékesben is, de a nagyobb példányokról mellékeltem fotót, mert a jelleg így jobban felismerhető.

    Nosza, filozom. Pár fotót felleltem neten szerelési szekrény belsőkről. Dugaszolósra éppen nem sikerült példát találnom, de ez csak eseti véletlen is lehet. Egy átlag szaki kényelmesebbnek tartja a fix modellt? Vagy a dugaszolóst tarthatják igazából kényelmesebbnek? Esetleg a dugaszolós szerelést felesleges körülményeskedésnek tartják?

    Mi a szitu ez ügyben?

    Köszönöm.

    [ Szerkesztve ]

  • #95092224

    törölt tag

    válasz Dezsi82 #960 üzenetére

    Bocsi, hogy így belekotyogok a dolgokba, de miért is kell mindenre PLC-t használni? Ipari termelésre, az okés, de egyéb civil célokra mi baj van az ipari miniPC-kkel? Laptopot én se raknék ki termelési területre, de egy miniPC-t be lehet szerelni a szekrénybe, és elvan, mint a befőtt. Van rajta azonnal ethernet, meg ami SW támogatást csak akarsz. És egyáltalán Windows.

  • #95092224

    törölt tag

    A kérdés ipari PLC-k Digit Output moduljaira vonatkozik. Az adatlapokban nem találtam arra vonatkozó infót, hogy mi várható, ha a szaki bután kötöget drótokat, és kimeneti meghajtást beköt fogyasztó nélkül (rövidre zárja a kimeneti meghajtást a 24V-os külső tápegységgel).

    Konkrét példának mondjuk a "Siemens SM 322; DO 8 x 24 VDC/0.5 A with diagnostics interrupt" - ezt írta róla egy adatlap. Ezen a diagnostic interrupton akadt meg a szemem. Mit jelent ez a gyakorlatban? Ha zárlatban rákötöttem a tápfeszt (nem hogy 0.5A-t, de 100x annyit is lazán be tudna az tolni), képes felismerni, automatán lekapcsolni, és mindezt még üzemszerű körülményként állandó ismétléssel is túlélni?

    Vannak más Digit Output modulok is, ahol nem olvastam ilyen apróbetűs jegyzetet. Azokkal általánosságban mi a szitu? Túlélhetnek egy félrekötést, vagy tönkremennek tőle?

  • #95092224

    törölt tag

    válasz Szirty #992 üzenetére

    Ugye tudod hogy a PLC is számítógép!?

    Ugye tudtad, hogy a Zlotyi is pénz? :)

    A pic is szemantikailag egy teljes értékű számítógép, noha csak egyetlen áramköri tok az egész, mégsem gondolok rá számítógépként. Te hogy vagy vele?

    [ Szerkesztve ]

  • #95092224

    törölt tag

    Szerintem a fa helyett lássátok inkább az erdőt. A számítógép definíciójába inkább én se mennék bele, de van egy sokkal egyszerűbben megfogható különbség a számítógép, és a periféria eszköz között: maga az alkalmazás.

    Egy számítógép tipikusan absztrakt felületen dolgozik. Afféle ideális körülmények között. Nincsen rajta idő-kritikus nyomás. Egy periféria vezérlő pedig idő-kritikus alkalmazásokra van optimalizálva.

    Írok egy példát. Pld adva van egy információ stream, másodpercenként csak 1 millió bittel. Nem egy nagy sebesség. Ennek a többszörösét is fel lehet dolgozni számítógéppel. Viszont ha azt vesszük, hogy minden információ elem éppen csak abban az egy uSec időablakban áll rendelkezésre, máris problémái lesznek a számítógépnek (pld a PC-nek). Ugyanis egy mai oprendszerrel (pld WinXPsp3) nem lehet 16 mSec időablakon belülre pozicionálni. Ha ki kell nyisszantani fixen egy bitet a streamből, akkor kell egy perifériát kötni a számítógéphez, ami ugyan sokkal gyengébb teljesítményű, viszont azt a csekélyke teljesítményt koncentráltan a feladatra tudja fordítani. Pld kinyisszantani egy bitet az adott uSec időablakból, amivel egy PC felsülne, arra még egy aprócska pic10-es is képes. Azután valamilyen információ bufferbe rakni a dolgokat, ahonnét kötegelve lehet továbbítani a számítógép felé, amikor majd a számítógép éppen kegyeskedik odafigyelni, és kötegelve átvenni egyszerre mindent, ami időközben felgyülemlett.

    Bármilyen számítógép perifériát is veszünk alapul, azok mindegyikének önmagának is van egy processzora, és kvázi perifériái (sima TTL / CMOS jelvezetékei, ha más nem). Ergo azok önmaguk is számítógépek. De az alkalmazás típusa miatt mégis perifériáknak hívjuk őket.

    Egy PLC-vel is ez a helyzet. Időkritikus alkalmazásra termett, nem absztrakt munkavégzésre. Egy PC-hez képest a PLC csupán periféria.

    Amúgy a miniPC-ket "ipari" célokra én úgy értettem, hogy pld egy nagyobb kivetítő monitort nem feltétlenül kell időkritikus üzemben működtetni. Tök8, hogy egy kép az adott uSec időablakban jelenik-e meg, vagy akár több mSec idővel később. Egy absztrakt eszköznek maximum az emberi reflexek sebességéhez kell alkalmazkodnia, de arra meg bármelyik képes. Időkritikusabb alkalmazásokra én sem használnék miniPC-t, ugyanis alkalmatlan rá. Oda vagy PLC vagy pic.

    Némelyik PLC-nek PIC12C magja van, mint időközben megtudtam: összteljesítményét tekintve iszonyúan gyengusz egy típus.

  • #95092224

    törölt tag

    válasz Szirty #1002 üzenetére

    Mutatós a fotó, thx.

    Én úgy gondolom, hogy a periféria fogalma alárendeltségi viszonyt is jelent.

    Abszolút igaz. Mindössze megjegyezném, hogy körültekintőbben kellene eldönteni, mit is nevezünk "fölérendelt" státusznak?

    A szemantika "elsődleges adathordozónak" azt nevezi, ami emberi értelemmel is feldolgozható formájú. Elsődleges adathordozó a papírra írt szöveg, a monitoron megjelenített ábrák, de már csak másodlagos pld a hálózati adatforgalom, a winchesterek és egyéb memóriák tartalma, stb. Maga a teljes számítógép az emberi értelem tartozéka, és nem fordítva. Az a felsőbbik szint, ami a közvetlenebb emberi kommunikációt teszi lehetővé. Az időkritikus folyamat végrehajtás az absztraktabb szint alatt van, és a képernyőre kiírt adat is felsőbbrendűbb információ, mint a PLC memóriája.

    Mielőtt páran jót kuncognának rajta, hogy "Akkor a számítógép a perifériája a monitornak és a billentyűzetnek?", üzenem nekik, el se kezdjenek vihogni, mert igen. Bármit is sugall a műszaki világ logikája, a logikát eszköznek szokás használni, és nem áldozatul esni neki. Aki nem tudja felmérni, hol a határ, az simán csak alkalmatlan a szellemi terheléssel járó munkakörökre. Ergo a véleménye sem szakember véleménye. Fejlettebb társadalmakban már a humán erőforrásnál külön személyiség teszteket használnak a szellemi balesetek megelőzésére, és nem is kerülhet az adott munkakörbe az az ember, aki nem bírja a terhelést. Mindössze a magyar trehányság következménye, hogy nálunk ilyesmik nincsenek.

    Azért remélem, ettől most senki sem fog rosszakat álmodni :)

  • #95092224

    törölt tag

    válasz Dezsi82 #1015 üzenetére

    Elvileg a saját programozójával vissza tudod olvasni.

    PC-re újabban már .NET technológiával készülnek a programok, azok pedig visszafejthetők.

  • #95092224

    törölt tag

    válasz Dezsi82 #1017 üzenetére

    Gyors és egyszerű kategorizálás alapján: "Microsoft .NET" == "Sun Java". A háttérben az zajlik, hogy Microsofték le akarják kaszálni a Sun piacot, és bizony szégyentelenek lesznek. Ennyi a lényeg.

    Modbus:
    Kotorászok a modbus doksik között, de valahogy nem sikerül választ találnom egy tök alapvető kérdésre: a modbus multi-master alkalmazás?

  • #95092224

    törölt tag

    válasz #95904256 #1193 üzenetére

    akosf:

    Éppen most nézem, hogy az elmúlt napokban PLC adatgyűjtéssel szenvedtél. Pár tapasztalat, aminek szerintem hasznát fogod venni.

    Van 4 gyártó (Lantronix, Digi, Moxxa, Systembase), a cuccaik HW-re normálisak, de SW-re gyerek cipőben jár mindegyik. A saját driverük / firmwarejük nem stabil. Egyiknek sem. Ahány helyen csak próbálták, még normális switchek mellett is max pár óra, és lefagyott. Teljesen érthetetlen szituk tucatja, amiket eddig láttam. Néhol működik, néhol nem. Ha olyan kedve van, lefagy, és csak a tápkábel kihúz / bedug segít.

    Van Wiznet-es cumó is (google meg fogja találni), azzal még HW baj is van (megsütötte a pénztárgépet, ahol kipróbálták, ennyit tudok az esetről).

    Részemről azt csináltam, amikor nekem kellett ilyet megoldanom, hogy fogtam a HW cumót, írtam rá saját firmware-t, és PC oldalra is egy SQL szerveres illesztőt írtam, az furcsa mód első pöccentésre működött, és azóta is. Lévén azzal semmi baj nincs, én levontam a következtetést: vagy a firmware, vagy a driver, vagy mindkettő, de valami nem tiszta. Stabil megoldást csak arra az esetre ismerek azóta is, ahol elég sok cumót kell kitelepíteni, hogy az SQL szerver is gazdaságos legyen, mint központi adat gyűjtő. Ez az eset easy rider plug & play, a többi meg felejtős. De legalábbis a firmware drivert le kell cserélni, és a PC oldali driver helyett is saját programot használni.

    Ha nem feltétlenül kell a soros port, mert igazából külön elektromos jelvezetékek vannak, és kell a cuccból vagy ~150, akkor pedig megszokhatóbb lesz egy célirányos elektronika, mert azt lehet közvetlen ethernetre beállítani, és nem kell vele külön firmware-ezni.

    Kézzel fogható segítséget a témában meg valószínűleg azért nem kaptál, mert a fentebbi pár problémán elég sokan "elkenődhettek". Sajna a cumókat mindenki csak "gyorsan megveszem, és gyorsan tovább adom" alapon kezeli, de a portszerverek még nincsenek annyira kiforrottak, hogy ilyen módon kezelni lehetne őket.

    Én magam veszekedtem már eleget a gyártó cégekkel levelezésben, hogy ugyan figyelnének már oda egy kicsit, de belefáradtam. Értetlenkedő keményfejű banda mind. Nem venném biztosra, hogy a fenti problémák rövid időn belül fognak megoldódni általánosság jelleggel. Nem is érdemes vele vessződni. Ha tutira kell a cucc, az a biztos, amit te tudsz karban tartani.

    Általánosság jelleggel annyit tudok mondani, ha van saját programozó a cumó mellé PC oldalra, akkor egyáltalán működhet. Ha nincs, akkor felejtsd el a portszervereket. Ha pedig a PC szerverre telepíteni semmit nem engednek, még a "megbízható" informatikusnak sem, az egy olyan szitu lehet, hogy szerintem ők igazából nem akarják, hogy te ilyen problémát valóban megoldj.

    Ha segítség kell a témában, most pár napig kicsit jobban idefigyelek.

  • #95092224

    törölt tag

    válasz #95904256 #1195 üzenetére

    Amit kiszámoltál, mennyibe tud kijönni PLC-nként? Épp csak érdekel. Az én tippem olyan 30-35-be volt.

  • #95092224

    törölt tag

    válasz #95904256 #1197 üzenetére

    Úgy hirtelen nem tudom mennyi most az euro, de helyből lehet vagy 70 rugó, amire tippeltél. És ha jól sejtem a bedobozolásnak, tápegységnek, mechanikai felrögzítésnek még csak ezután nézel utána. Egy portszerver simán csak fele annyi célirányos firmware-el is. Biztos azt a pc kártyát akarod?

  • #95092224

    törölt tag

    válasz #95904256 #1199 üzenetére

    Ha mégis portszerverek után néznél majd valamikor, átprogramozva tudok neked adni cégként számlára.

  • #95092224

    törölt tag

    válasz Marty76 #1202 üzenetére

    Szió Marty76.

    Amit barkács dolgokról tippet adnék neked, hogy a gépeken mindenütt vannak vagy digit i/o modulok (akár sima jelvezetékek nagyon régi gépeknél), vagy pld egy printer port, amire folyamatosan nyomtatja a gép a munkaadatokat. Szóval valami, amit fel lehet fogni, el lehet vezetni. Ha mást nem, akkor úgy kell programozni a PLC-t, hogy célirányosan küldjön jelzéseket eseményekről. Azután megírni a saját programot a központi szerverre az adatok fogadására, feldolgozására (a főnök gondolom grafikonokat akar látni, nem számhalmazt).

    Elektronikai park átlag RS-232 / D I/O <-> Ethernet konverter (bruttó 20 khuf-tól 40-ig darabja), switchek (ipari tárolósak is vannak bruttó 30..50 között, kommerszek 4-5 / db), ethernet kábelezés (métere 150 huf? valami ilyesmi), egy átlagos teljesítményű Tesco-s szerver gép (kb 200 khuf egészben tokkal vonóval). Szoftver park célszerűen talán Visual Stidio (valamelyik programnyelve, lehet választani), MSSQL. Ha elég a kis teljesítményű SW cucc, az van még freeware is. Ha a jogtiszta eszköz kell, teljes park MicroSoftéktól most valami 140 khuf (van speckó fejlesztői licence). Ezek mind olyan dolgok, hogy doksi róluk bármelyik sarkon akad, de amúgy is bárki elboldogul vele, mert simán csak "legózni" kell.

    Amit jó lesz észben tartani. Aki barkács rendszert épít, annak kell majd helyben egy barkács szaki. Kellene oda a céghez egy józan életű technikus, meg programozó. Nem kell különösebb képzettség. Az kell, hogy legyen helyben stabil ember, akit a napi csip-csup dolgokkal meg lehet találni. Nélküle barkács rendszernek nekikezdeni felejtős.

    Ha tanács kell bármelyik pontjához a rendszer építésnek, kérdezz konkrétan.

    Ami a gyári "szabványos" dolgokat illeti, azokkal akosf éppen jelenleg futja a kört, tőle kérdezd, hogyan megy. Nekem csak nagyon rossz tapasztalataim vannak azokkal.

    [ Szerkesztve ]

  • #95092224

    törölt tag

    válasz Marty76 #1219 üzenetére

    Szerintem itt alapvető félrefogalmazások lesznek azt illetően, hogy mit is szeretnél.

    Amikor adatgyűjtésről beszélünk, akkor az a cél termelési magas szinten, hogy a gépek által már elvégzett munkát - mint statisztikai adatot - real-time eljuttassuk egy központi szerverbe.

    Az egyedi konstrukciód úgy néz ki, hogy a taiwani pajtás fogott egy mini pc-t, gyártott egy külön kis mikrokontrolleres áramkört, a kettőt soros porton összekapcsolta, és ezt az egységet egyetlen dobozba pakolva elnevezte a végeredményt valami akármi PLC-nek. Szólj rám ha ezt rosszul vettem ki soraidból.

    Te szétbontanád a dobozt, és lecserélnéd a beépített mini pc saját vezérlését egy saját magad által készített központi vezérléssel.

    Természetesen meg lehet ezt csinálni, nem probléma, de mielőtt belefutnék egy félreértés sűrűjébe, megkérdezem, sacc/kb jól foglaltam össze a lényeget ?

  • #95092224

    törölt tag

    válasz Marty76 #1223 üzenetére

    Jól fogtál neki, csak így tovább. Amúgy amibe a fejszédet belevágtad, az egyáltalán nem kispályás dolog még akkor sem, ha elég egyszerű és sablonos a mikrokontroller / mini pc kommunikációja. A jelen esetben az a fő különbség, hogy te nem adatgyűjtést csinálnál, hanem a teljes vezérléstechnikát írnád újra. Nem nehéz, csak szöszölni kell vele. És igen, nagyon sokat. Elakadni nem akadtál el, ahogy elnézem.

    Persze tedd fel a kérdést újra, ha valamit rosszul értettem. Ami kérdést a legelején feltettél, azt igazából megoldottad magad is, ahogy elnézem.

  • #95092224

    törölt tag

    Itt magyarban barkács célra azok a cuccok nagyon drágák. Barkács célra barkács cumó kell, és az nem az Omron lesz.

  • #95092224

    törölt tag

    Tudni kéne hogyan állíthatod a taiwani cuccos kimeneti vonalait a belső mini pc programjából. Ennek ugye már nekiugrottál. Ha még nem térképezted fel, hát igyekezz :) Utána már elvileg nem lehetne problémád a vonalak állítgatásával. A többi a túloldali plc programjától függ (amit gondolom szintén te írsz meg).

    És most egy kérdés, ha mégis elakadtál volna a felprogramozással, miért nem használsz valami kommersz embedded cuccot? Még mindig sokkal olcsóbb lenne, mint az Omron termékek.

  • #95092224

    törölt tag

    válasz Petya 888 #1245 üzenetére

    Ha csak annyi van ráírva "FANUC", akkor az egy FANUC-0 típus. Nagyon régi darab. A supportjuk is már több mint 10 éve végleg megszűnt. Van, ahol még működnek, de ott megvan hozzájuk a saját környezetük, ami ha egyszer tönkremegy, már csak kidobni lehet ezeket a kivénhedt darabokat.

  • #95092224

    törölt tag

    válasz izriot #1514 üzenetére

    Egész biztos, hogy modbus-ra kell felcsatolni azokat a cuccokat ? Jellegében miféle eszközök ? Mert ha csak sima TTL vonalas vmik, egy vonali meghajtóval digit io-ra simán rákötheted őket. Alacsony intelligenciás kapcsolathoz pedig már ezernyi a távközlési lehetőség. Kezdve a legkülönfélébb wifi cumókkal (pld zigbee).

  • #95092224

    törölt tag

    válasz izriot #1519 üzenetére

    Fene tudja, részemről a liberális elvek híve vagyok.

    Az "azonnal tudja azt patentra, amit kell", valószínűleg az lesz a csillió forintos tétel. De cca 300 darab alatt igazából nincs más esélyetek.

    Ha már mennyiség kell belőle, utána kerül csak láthatárra, hogy ugyanúgy, mint a "dicső nagyok", ki lehet fejleszteni egy X+n -edik kommunikációs szabványt is (a sajátotokat). Az sem lesz ugyan ingyen, de nem lesztek kiszolgáltatva a "nagyok" hegemóniájának. Hidd el nekem, az is valami, hogy nem lesz minden évben még eggyel több ránc a szemetek alatt :)

  • #95092224

    törölt tag

    válasz Krisz737 #1593 üzenetére

    Ha főleg PC oldalra kell a segítség, oda a legegyszerűbb egy .NET-ben megírt NT Service, ami egyrész kommunikál a HW oldallal (pollozza az adatokat a PLC felől), másrészt kommunikál az SQL szerverrel (felírogat dolgokat, illetve onnét is pollozza a kimenő adathalmazt). A pollozás reakció idő veszteséggel jár, de nagyon kényelmes funkcionalitás valósítható meg vele, és ami a legfontosabb: sohasem dö*lik meg. Adat vezérelt automata funkciók, kétirányú kapcsolat, amit akarsz.

    Ilyen text file-os közbülső dolgok - na ezeket nagyon nem javaslom. Állandó baj van az adatok archiválhatóságával. Közvetlen SQL kapcsolat kell.

    Ami a PLC kapcsolatát illeti a szerver gép felé, oda már gondolom találtál cuccost. Lehet kész terméket venni ami kezelhetőbb+drágább, vagy ha elvárás, hogy saját cucc kell, írni egy módbusos processzort sem a világ vége, ami ethernet kontrollert is kap maga mellé, bár a cucc normális dobozolása sem éppen olcsó.

    Hát, remélem segítettem valamicskét.

  • #95092224

    törölt tag

    válasz gyurissg #1729 üzenetére

    Laptopok és egyéb usb-s rs232 eszközökön optikai illesztéssel szoktak dolgozni. Ez annyit tesz, hogy a cél eszköz handshake vezérlőjeleit megterhelve azokat vezetik vissza. Ha a cél eszköz minden tekintetben szabványos lenne, ez egy rövidebb kábellel (max 3m) még működne is. Csak hát már mindkét oldal linkelget, és egyik se akarja bevállalni a filléres max232-t sem, így pedig elég ciki :C

  • #95092224

    törölt tag

    Kicsit más téma.

    Fényképen látok narancs-fekete olajos-zsíros-mocskos dobozt, rajta billentyűzet panel, kijelző, meg egy felirat, hogy "Fanuc 16", "Fanuc 32". Kellene nekem valami egyszerűsített rendszertan arról, fejlettségi szinten hol is tarthat az, ami a burkolaton belül van. Egyáltalán már digitális CPU-ja és rendszer sínje van, vagy még külön egységekből van összekábelkorbácsolva az egész mákostészta módjára?

    Kotorásztam neten, de a jelek szerint ez már nem mai technológia. Vagy ha az, engem biza elárasztott a bőség zavara (meg a sok tonnás mellébeszélés). Bízom benne, itteni szakik még emlékeznek ilyesmire, és rövid úton be tudnak tájolni.

    Köszönöm.

  • #95092224

    törölt tag

    Jelenkori PLC vezérlők magyarországi gyakorlatban milyen ModBus sebességet támogatnak? Az a legnagyobb sebesség érdekelne, amit még tényleg használnak is, és nem csak papíron tudja 50 eszközből maximum 1. Köszönöm.

    [ Szerkesztve ]

  • #95092224

    törölt tag

    Kezdő kérdés PLC nyelvekről. Milyen szélességű adatokat kezelnek? 16 vagy 64 biteseket?

    Eddig csak a modbusba ástam bele magam, az a világ full 16 bites a legújabb doksik szerint. A PLC elektronikák viszont 64 / 128 bitesek. Szóval kicsit értetlenkedem.

  • #95092224

    törölt tag

    válasz Szirty #1846 üzenetére

    Modbusos elektronikát kellene gyártanom, és ásom belefele magamat a szoftver / elektronika kapcsolat lehetséges problémáiba.

    Azt a bizonyos DWord, DInt, REAL (32 bit) típust képes úgy kezelni, hogy modbusra kapcsolt elektronika állapot regisztereibe simán csak beleírni egy lépésben? Arra gondolok, megcsinál-e olyat automatikusan, hogy lebontja a 32 bites adatot kettő 16 bitesre, és azokat kiírja a (regiszter cím) címre (alsó 16 bit), és a (regiszter cím+1) címre (felső 16 bit)? Létezik ilyen nyelvi tulajdonság?

  • #95092224

    törölt tag

    válasz Szirty #1850 üzenetére

    Szerintem (a válaszodból ítélve) félreértetted a lényeget
    Hát tényleg nem értem. Pedig én már sok dolgot nem értettem.

    Más. Még egy ModBus kérdésem lenne. Az Application Protocol nem köti le szabványban, hogy egy CPU üzenetre mennyi időn belül kell kötelezően nyugta üzenetet küldenie a megcímzett perifériának, csak az van kikötve, hogy kell rá küldeni nyugta üzenetet. Figyelmeztetésként is csak annyi van, hogy:

    Note: It is desirable to manage a time out in order not to indefinitely wait for an answer which will perhaps never arrive.

    A jelek szerint ezt a késleltetési idő dolgot program szintről szokás lekezelni. Olyan doksikba még nem ástam bele magamat, szóval nem vagyok képben, mennyire kényelmes / kényelmetlen dolog egy elhúzódó nyugta üzenetre várni? Gondolok itt arra, hogy a független folyamatoknak zavartalanul mennie kell tovább, csak azt az egy folyamat ágat le kell stoppolni. Meg lehet tenni ezt különösebb megizzadás nélkül akár az idők végtelenségéig?

  • #95092224

    törölt tag

    Amennyire elnézem én ezt a modbus témát, tényleg nagyon rosszul álltam hozzá. Akkor megközelítem másik oldalról. Egyenlőre csak tegyük fel eset.

    Tegyük fel vásárolnék egy PLC CPU-t egy kifejlesztendő elektronika tesztelésére. Kicsit bele kellene rázódnom a programnyelvekbe is (részemről az utasítás listás feküdne jobban, asm / c-s vagyok). A CPU-ra csak egy olyan egyszerű programot kellene megírnom, ami egy hozzá kötött modbus-os elektronika egyik állapot regiszteréből adatot olvas, és ír oda vissza. Igazából semmi mást nem is kell tudnia, csak ezt ciklusban. Van hozzá laptop, winXP, a többiről gőzöm sincs. Azt vennem kell. Utolsó tápegység és csatlakozó kábelig mindent a nulláról. Ami példát láttam utasítás listás garázsajtó vezérlésre pld, annak a szerkezete nem hasonlít sem egy C programra, de még egy VHDL kódra sem. Szóval az elején kellene kezdenem, mert valami nagyon zöld ebben az egészben.

    Ha mindezen tényleg keresztül akarom rágni magam, cirka mennyi pénzembe fog kerülni, és durván hány oldalnyi doksit kellene megemésztenem?

    [ Szerkesztve ]

  • #95092224

    törölt tag

    válasz Szirty #1856 üzenetére

    Konkrétan ilyen feladatom még nincs, de perpillanat a küszöbön van, és elképzelhető, hogy rámkopog.

    Kezdésnek az elsődleges cél az lenne, hogy lássam a saját szememmel, ahogy egy elképzelésből program lesz, és az a program valami úton módon a cpu-ba kerül, elindul, és működik. Amúgy igazából nem pont a PLC vezérlés a szakterületem, és nem is számítok semmiféle komoly megmérettetésre ezen a téren, de olyan helyzet állt elő, hogy nem lesz elválasztható az egyik a másiktól, és legalább alapokkal képben kell legyek.

    Ejnye lássunk már valami kézzelfoghatóbbat. Mondjuk egy fejlesztői környezet összepakolást. Ez most csak egy példa lesz. Schneider árlista. Itt pld: [link] az BMXP341000 L1-es processzor 92khuf+áfa. Az adatlapja szerint 24V-ról megy, kell hozzá egy tápegység. Találtam itt [link] BMXCPS2010 46+áfa. Aztán ezt a valamit programozni kell. Találtam olyat, hogy programozó kábel [link] BMXXCAUSBH018. Mondjuk azt nem vágom, hogy egy 1.8m usb-s kábelben mi kerül 21 ezerbe, de nyilván van valami oka, hogy nem használhatok pld egy sima PC-s usb kábelt. Ahogy a cpu-t elnéztem, a modbus kimenete rj45-ös. Ha több elektronikát kell rákötni, kellene hozzá valami elosztóféle is. Ilyet egyáltalán nem találtam. Másik problémám, hogy nekem db9-es csatlakozóra kellene a modbus rtu, nem rj45-re. A felkötendő elektronikának db9-es csatlakozója lesz. A kábelek között találtam egy TCSMCN3M4M3S2 -t, de ez is kicsit gyanús, hogy egy sima kábel 15 rugóba kerül - és persze nem vagyok biztos benne, hogy ezt kell használni egy külső elektronika cpu-ra felkötéséhez. Ennek az egész hóbelebancnak a szoftveres hátteréről egy deka szót sem találtam. A fejlesztői környezetet a csomagban adják a cpu-hoz dvd mellékleten? Kimaradt még valami fontos, amire nem is gondoltam?

    Az STL nyelvnek most kezdek utánaolvasni. Köszönöm a tippet.

    [ Szerkesztve ]

  • #95092224

    törölt tag

    A "PLC STL"-ről nem találtam kb semmit. Max félig névben stimmel brossúrákat. Bármiféle szabványosított scriptes vagy akármilyen előredefiniált utasítás készlete is van a PLC-knek, az a jelek szerint egy kicsit sem publikus.

    Akkor most lenne egy kérdésem, amit máshogyan vetek fel.

    Nem tudom, lehet-e ilyet csinálni, de ha lehet, árajánlatot kérnék rá (egyszeri alkalmi munka / tanácsadás). Adva vannak Ge Fanuc 16i / 32i vezérlők. A gépen futó termelési program időnként leáll. Pld elfogy a bemeneti nyersanyag, vagy elkopott a kés és cserélni kell, vagy csak a gép kezelője állítja meg a mittudomén miért. Kellene egy olyat programozni, hogy ha megállt a termelési folyamat bármiért is, akkor ne lehessen simán csak folytatni, hanem kapjon a gép kezelője egy 5-6 soros listát kiírva (leállás lehetséges okai), és muszáj legyen megnyomnia legalább az egyik gombot pld F1..F6 (visszajelzés, hogy melyik eset is történt), mielőtt a programot tovább léptethetné / újraindíthatná a termelést. A Fanuc-ok mindegyikén ott egy soros port, arra rákötve egy karakteres printer (és amúgy tuti biztos működni fog). Arra kellene gombnyomás után kiküldeni egy nyomtatási sort, hogy gépidő / kiválasztott lista elem, esetleg még egykét PLC regiszter értéke, és sordobás. Ennyi. Szóval mint írtam, nem tudom, egyáltalán lehetséges-e ilyet csinálni. Ha igen, és valaki meg is tudja csinálni, várom a jelentkezését. Köszönöm.

    (Kérdés, jelentkezés csak priviben)

    [ Szerkesztve ]

  • #95092224

    törölt tag

    Köszönöm a vásárlási tippeket. Amikor legközelebb lesz egy nyugodt időszakom, akkor belefogok. Addig a mostani problémával már csak kerülőúton tudok megbirkózni, vagy segítséggel (éppen azért is írkálok ide).

    Szirty:

    "ne lehessen simán csak folytatni"
    Oké, az én hibám. Marhaságot írtam. Bocsánat. Nem kell kényszer legyen. Megengedő jelleggel kell egy ilyen funkció. Szinkronizálni sem kell semmivel. Pld gombnyomásra az illető átvált egy másik képernyőre, és ott ha bök valamire, akkor a printer nyomtasson egy sort összetartozó adatokkal. Így is tökéletes.

    "adjon a gép kezelője egy 5-6 soros listát kiírva"
    Feltettem ezt a kérdést magam is. Mint kiderült, félreértettem a szándékot. Vannak bizonyos problémák, amikről tudnak, és már ellenintézkedések is vannak. Az igazi kérdés csak az ellenintézkedések hatékonysága, amiről kell a visszajelzés.

    A harmadik probléma, hogy ezzel a megoldással emberi tényezőt
    Hát ezzel bizony úgy vagyok, hogy nem szívesen vetek fel olyan problémát, amivel nem tudok mit kezdeni ;] Szóval van egy megbízás X gépre első körben, és ha nagyon nem jön be, akkor a második ütemet törölni fogják. Ez előfordulhat. De az elsőt akkor is kifizetik. Azért az is csak pénz.

    Sörösló:

    Köszönöm a tippet. A vonalkódolvasó nekem eszembe sem jutott. Én "hangpostán" filoztam, csak sajna túl nagy sávszélesség és túl sok tárolókapacitás kell hozzá, ha valaki esetleg unalmában elkezdene karaokizni. Saját human interface-t gyártani is sorozatgyártásban jó 40k huf, mire mindent összeszámolok. Tablet PC is van már ilyen áron, vagy legalábbis a kicsike fajta, csak azt meg széteszi az olaj ipari környezetben.

    Részemről még mindig filozok rajta, hogy ha a PLC-t fel is lehet programozni erre, akkor egyáltalán semmiféle külön HW nem kellene, és hosszú távon tuti az a legüzembiztosabb. Még egy vonalkódolvasó is taccsra megy időnként, és akkor dobni kell, másikat venni helyette, amit majd vagy megtesznek, vagy nem. A PLC program nem amortizálódik.

    Szóval a fanuc 16i-ben is már 64 bites proci van, és az alaprendszerében is van egy rakásnyi menü. Az nem valami buborékmemóriás kábelkorbács kukás szutyok, hanem kvázi egy számítógép. Tényleg a PLC gyártók lennének annyira szemetek, hogy a testreszabás legkisebb kezdeményét sem engedik? Vagy a PLC programozók lettek mind Stockholm-szindrómások és eltanulták tőlük a pénzéhséget? Csak lesek, mi a fenébe csöppentem már megint bele :(

  • #95092224

    törölt tag

    válasz sörösló #1865 üzenetére

    A pic-es áramkör fejlesztéssel nem lesz gond, abban a világban otthon vagyok. A külön interface-t akartam lespórólni. Ezért nyafogtam. Simán csak mert plussz költség, amit rá kell áldozni. De ha muszáj beletörődni, akkor beletörődöm.

    A DOS-ról meg csak annyit, hogy szerintem az egyik legjobb találmány volt. Amíg a gépeken DOS futott, addig időkritikus alkalmazásokat is futtatni lehetett rajta, és pld a printer porton keresztül vezérelni HW-ket. Anno még én is csináltam. Win alól minderre már külön HW kell, mert anélkül ilyet már nem lehet megcsinálni. Nem meglepő, ha ipari elektronikában még visszaköszön a puszta valóság.

    [ Szerkesztve ]

  • #95092224

    törölt tag

    válasz Szirty #1871 üzenetére

    Éppen csak hitetlenkedtem, hogy miért is nem lehet user custom menu-t gyártani a termelési programba. De mint felvilágosítottak, márpedig nem lehet.

  • #95092224

    törölt tag

    Egy link: http://www.ge-ip.com/products/family/90-30-cpus

    Van ott egy olyan, hogy "Built-in Communication Ports" -> "One RS-485 port on power supply.Supports SNP ". Ezt az "on power supply" dolgot elektronikailag hogyan kell érteni?

  • #95092224

    törölt tag

    zsolo_d, Szirty:

    Elméleti kérdésem lenne az iménti leírtakkal kapcsolatban. Nem pont a HMI-kről, hanem alapvetőbb dolgokról.

    Ha olyat kellene megcsinálnom, mint fentebb említett példa, nevezetesen egy plc regisztereit kell olvasnom és írnom is annak működése közben, és mindezt a plc programjába való beavatkozás nélkül, általános jelleggel elmondható, hogy bármilyen profibuszra felcsatlakozott szabványos eszköz meg tud ilyet csinálni? Annyi az egész, hogy station number, és tudni melyik regisztereket kérjem le / írjam át, és simán fog működni?

    Mindehez persze feltételeztem, hogy az adott plc-nek egyáltalán profibuszos felülete van, amire felcsatlakoztathatom azt az eszközt, amit előzőleg megfelelően konfiguráltam. Viszont a plc vezérlő szoftverébe semmi módon nem avatkozhatok bele, és ez lényeges peremfeltétel lenne.

    Azon filozom, hogy a profibusz hálózaton belül nincsen valamiféle előre beállított védelem, hogy bizonyos eszközök bizonyos eszközökhöz nem férhetnek hozzá, mert a busz master a kezükre csap érte? Alapértelmezetten minden eszköz "megbízható"-nak van nyilvánítva, és bármelyik megtehet akármit?

    Ha túl nagy marhaságot írtam, szóljatok rám. Én ugyanis nagyon nem vagyok képben ezekről a dolgokról.

  • #95092224

    törölt tag

    válasz Szirty #2480 üzenetére

    Köszönöm a választ Szirty. A jelek szerint pár dolgot elnéztem. Esetleg kérném további tanácsaidat a dolgok pontosításában.

    A terepi buszok elleni hekker támadás threadet szerintem zárjuk le. Ha bármilyen utalásom ilyesminek tűnt volna, ezúton jelezném, pusztán tévedés volt részemről. Bármilyen ipari termelési rendszert természetesen zártra terveznek, és biztonsági szolgálattal védenek, ergo hekkerek álmodozzanak csak nyugodtan, úgysem fognak labdába rúgni sohasem. Maximum géppuskával, de az nem a mi asztalunk.

    Megfordult viszont a fejemben, hogy mi történik akkor, amikor valaki olyan program vezérlést ad az eszközöknek, hogy valamit összekutyul? A nap bizonyos szakaszában mindenki csak ember, és tévedhet. Influenza, stressz, akármi. Az informatikában számos ilyen "gyerekzár"-at iktattak már be fejlesztői környezetekbe azzal a célzattal, hogy a fejlesztők a saját figyelmetlenségük és ostobaságuk ellen tudjanak védekezni. Ipari környezetben annyira jól kiképezett szimulátor alkalmazások lennének, hogy ha hibásan van egy alkalmazás elkészítve, garantáltan észreveszik még a logikai butaságokat is?

    A busz protokollokkal a jelek szerint valamit félre értettem. Részemről a "profibusz" alatt egy layer 1 felületet értettem, nevezetesen halom kábelezés, és csatlakozók, rajtuk előreszámítható 0 és 1 bitekkel, amik azonos típusú adat keretekbe szerveződnek, amire magasabb layeren protocolok illeszkednek. Olyasmik, mint a PB-DP, PB-DP-V1, PB-DP-V2/ISOM, PB-DP-V2/DXB, PB-DP-V2/CLKS, MPI. Ezekkel találkoztam össze doksikban. Ezek közül igazából mindegyiket csak slave funkciók kapcsán láttam említeni, most pedig fentebb olvasható dolgokból arra következtettem, MPI protocol master funkciókra is alkalmas lehet. Ellenőrzésként megkérdezném, az MPI protocol elektronikailag ugyan arra a buszra csatlakozik, mint a DP slave-ek, vagy fizikailag is külön busz, külön csatlakozók, és teljesen szét vannak választva?

    A "HMI"-ről kb annyit találtam, ami a wiki-ben le van írva (human machine interface, ami kb mindenre igaz, monitorra, egérre, billentyűzetre, stb), meg persze google pajtás előadásában szimpatikusan vigyorgó öltönyös bácsik-nénik brossúra fotóit - de semmi releváns dolgot. Van egyáltalán szabványban leírt neve a kommunikációs protokoljának az S7 rendszerekben, vagy definíció szerint ez valami olyasmi, amit a Siemens olyanra tervezett, amilyenre, és senki másnak nincsen hozzá nyúlka-piszka?

    Például találtam pár layer 2-es eszközt itt:

    http://www.profichip.com/products/overviewasics/

    Ezek közül pedig ennek a neve ugrott be a fentebb olvasottak alapján:

    http://www.profichip.com/products/overviewasics/mpi12x/

    Ez az eszköz alkalmas lehet bus masterként viselkedni, és a CPU regisztereihez hozzáférni? (Feltételezzük, hogy az ehhez szükséges konfigurációs beállítások a rendszerben megtörténnek. De csak konfigurálás. Semmi extra program support, nevezetesen hogy a CPU direkt kiírogatja a regisztereit erre az eszközre, mint slave-re, mert az már csalás :) )

    Ha ez az eszköz nem az, amire én gondoltam, részemről akkor is érdekelne, van-e lehetőségem ilyen eszközt megépíteni. És természetesen nem a szép színes érintőképernyőre, és a java fejlesztői környezetre értettem mindezt, hanem arra, hogy valahogyan csatlakozni kell a CPU felé a buszra, és teljesíteni a protokol elvárásokat. Mindezek IEC doksiban olyan 8..10 ezer oldalon keresztül természetesen remekül le vannak írva (és nem csak 10 ezer oldalnyi, de olyan summa 15 millió forint is az a full doksi webstore-ból), de azt mind átolvasni, az azért sok lenne nekem. Valami rövidebb célirányos dokumentáció (max 4-500 oldal), esetleg kész layer2-es IC evaluation kit / stack support, ilyesmik. Létezhet ilyen kereskedelmi forgalomban?

    [ Szerkesztve ]

  • #95092224

    törölt tag

    Hmm, még egy kiegészítő kérdés. Lassan esik le a tantusz.. Jellemző, hogy milyen CPU-k mellett van lehetőség egyáltalán ilyen protokolt használni? Pld ez valami új keletű dolog, ami S7-est igényel?

  • #95092224

    törölt tag

    válasz Szirty #2485 üzenetére

    Hi Szirty!

    Köszönöm a kimerítő választ, de (mindig ez a fránya "de" :) ) még valami konkrét dolognak is örülnék.

    Ez a kérés nem feltétlen csak neked szól.

    A fentebbiekből annyit szűrtem le, hogy léteznek olyan eszközök, amiket akár profibuszra (az RS485-ösre) is fel lehet csatolni, és azon keresztül is képesek a plc cpu-ból diagnosztikai adatokat kinyerni, illetve real time a regisztereit felül írkálni - ha éppen ez lenne szükséges.

    Ezek az eszközök (nevezzük őket ezúttal tök8 minek) mégiscsak léteznek, kézzel fogható valamik, vagyis van egy elektronikájuk a profibuszos csatlakozóhoz közel, és ott kell lennie egy layer 2-es elektronikának is. Egy fekete áramköri tok sok lábbal és a tokon egy típus jelzéssel.

    Ha valakinek véletlenül akad egy ilyen a keze ügyében, ami esetleg már elromlott (vagyis túl sok kárt már biztosan nem tud tenni benne), és nem sajnálja rá az időt széttekerni, igazán megtehetné azt az aprócska szívességet, hogy feljegyzi annak az áramköri toknak a típus jelzését. Esetleg ráfotózni egyet a panelra, ha több áramköri tok is ott van, amik nehezen azonosíthatóak. Elég hamar ki tudna derülni, hogy egy ilyen eszközt miből is gyúrnak igazából.

    Előre is köszönöm.

  • #95092224

    törölt tag

    válasz Szirty #2487 üzenetére

    Hali Szirty!

    Sajnos ez tényleg nem valami bíztató :( Egy fpga-ba azt raknak bele, amit csak akarnak. Egy típusjelnek azért örültem volna, mert az utal arra, amit a magba belegyömöszöltek.

    Hanem a történet ennyitől még nem állt meg. Ha mást nem, esetleg írhatok a Profibus Organizationnak, vagy akár a Siemens-nek, de ha ezt teszem, akkor legalább abban biztosnak kellene lennem, hogy nem valami nagyon nevetni való csacsiságot kérek tőlük. Náluk ugyanis elég kemény pénzekre tud menni egyetlen tévedés is.

    Találtam egy kicsi leírást a BME honlapján. Nem tudom, mikor készült, és hogy azóta hányszor fogalmazták újra bizonyos dolgok nevét, ezt megítélni kérném a segítségedet. (Abban a világban, amit az IT-ból én látok, olyan 3-4 évente már "nem teljesen igaz" az, ami annak előtte szentírás volt.)

    Itt egy link, ami profibusz ismereteket taglal:
    http://www.fsz.bme.hu/traficc/profibus/profibus_index.html

    Ebben a fejezetben:
    http://www.fsz.bme.hu/traficc/profibus/312sysco.html
    1. osztályú dp masternek ("DPM1"-nek) nevezi a gyakorlatilag cpu-t, ami a dp slaveket kezeli, irányítja a tényleges munkafolyamatot, és 2. osztályú dp masternek ("DPM2"-nek) nevezi az ezeket felügyelő eszközöket. Funkcionalitást tekintve ez kb ráillik arra az eszközre, mint ami működés közben monitorozni tudja a rendszert, és akár a cpu regisztereibe is beleírhat (természetesen mindezt a felügyelet személyes felelősségére).

    Ebben a fejezetben:
    http://www.fsz.bme.hu/traficc/profibus/32exdp.html
    Az oldal legeslegalján az utolsó fejezetben azt taglalja, hogy "MSAC_C2" nevű kapcsolattal (ez gondolom valami firmware-ben rögzített, és layer 2-es szintű elnevezés) a DPM2-esek is képesek kommunikálni a slave-ekkel a DPM1 szinkron adatátvitelétől függetlenül. Sajnos éppen a legutolsó mondat jelentésében nem vagyok biztos, pedig abban egy lényeges dolog van. Az a bizonyos 50-es szolgálati pont, az a DPM2-höz képest slave módban dolgozó DPM1 oldalán elérhető szolgáltatási pont?

    Az 5-ös fejezetben kerül elő a "Profibus-FMS", ami cella szintű kommunikációt valósít meg, és reményeim szerint ez master-master kommunikációt jelent. Szólj rám, ha tévedek. Itt ír róla:
    http://www.fsz.bme.hu/traficc/profibus/51fmsapp.html

    Itt is van egy lista szerű felsorolás:
    http://www.fsz.bme.hu/traficc/profibus/57fmsmix.html

    Ha eddig nem tévedtem el nagyon durván, akkor a 6. fejezetben itt:
    http://www.fsz.bme.hu/traficc/profibus/60implem.html
    A listában az "ASPC2"-es eszköz képes lehet master-master kommunikációval diagnosztikai funkciókat ellátni cella szinten. Az aspc2-t megtaláltam itt is:
    http://www.sea.siemens.com/us/PIC/Development/PROFIBUS/PROFIBUSASICs/Pages/ASPC2.aspx

    Sajnos az ASPC2 oldalán fellelhető dokumentációk fogalom rendszere teljesen más, mint amit a BME oldalain találtam a fentebbi linkeket is tartalmazó dokumentáció teljes elolvasása során, így a kettő kapcsolata igazából kimerül abban a névben, hogy ASPC2. Azért is írtam le az egészet, mert a fentebbi gondolatmenet önmagában zárt, egyébhez hozzákötni nem tudtam, ergo csak önmagában állhatja meg a helyét, vagy sehogyan.

    Az ASPC2-höz találtam doksikat a Siemens oldalán, de aki azokat írta, sajnos ahhoz is elég profi volt, hogy külön működő példa szemlélése nélkül azzal a dokumentációval a világon semmire sem mehessek. Ha ez az eszköz tényleg tudhat olyat, mint amit gyanítok, és sikerül erre valami üzleti alapot is teremtenem (ez legyen egy teljesen külön lap), akkor igazából nem olyan borsos az ára az ehhez tartozó evaluation kiteknek sem, de legalább azt tudnám biztosan, hogy nem fogok nagyon pofára esni egy csúnya elvi tévedés miatt.

    Mindezt azért írtam le, hogy megkérdezzem tőled, akad-e bármi olyan a fentebbi gondolatmenetben, ami lehetségesen elvi tévedés?

    És köszönöm mindazt a temérdek időt, amit kilométer hosszú leveleimnek pusztán az elolvasásával már eddig is rám áldoztál.

Új hozzászólás Aktív témák