Ezt a rendszert már régóta használják,
TokenBusznak híjják (pl:GM) robotok vezérlésére. Etherneten is megvalósítható (nem hallottam konkrét megvalósításról) ccsak egy baja van, 1 kiemelt MASTER vezérli az egészet, kell tehát egy tarcsi is :) + a SLAVE-k, ez két tipus + a több leveles HUB-ok jobb esetben, öröm szervizelni;)
(Valószínű, hogy a jogdíjak miatt nem terjedtek el a TBus és a hasonló rendszerek)
Előbbi példámhoz visszatérve a TR-nél mindegyik kártya rendelkezik ehhez hasonló inteligenciával mint a master, ezért is drágább...
MAkos ne keverd, kijavítalak, a HUB-nak nincs köze az UTP- STP-séghez!
A nem megfelelő eszköz csak több hibalahetőséget visz a rendszerbe, de a jobb félék segítenek, még a hibakeresésnél is.
A tartalék utakról még nem is beszéltünk!
A program fejlesztést ha értelmesen csinálják átlátszó lehet az applikáció számára. ettől kezdve Internetezhetünk is rajta:) ahogy mondod ehhez pénz + szakember + idő kell.
Az első három mondatod -szereti nem szereti- szóról szóra bejön.
Az Ethernet győzhet, simán, ha olcsóbb, akkor tutira.
A megbizhatóságot és valódi teljjesítményt igen-igen ritkán részesítik előnyben az óccsóósággal szemben! Idővel ezt a szót -megbizható- el is feledhetjük.
példa:
Van egy másik rendszer a TokenRing (IBM).Inkább csak volt, mert mára kihalt.
Pedig egy 16MB-s hagyományos TR egy 100MB-s Switched EThernet hálózatot (Eth két géppel!) simán leköröz. (Persze ehhez megfelelő minőségű gyártó is kell Trnél pl: Madge, Eth-nél Lannet, ma asszem a Lucent Technologies vette meg néhány éve).A megbízhatóságról nem beszélve.
Csak azok tartották meg akik tudják, hogy mi az, és mire képes. Sajna nem tudok arról, hogy fejlesztenék a TR-t, tutira kukában lesz 10 év múlva. De a TR is -elviekben-megmarad, mert ahogy sejtem az IBM SAN-ja (storage area network) Tokenring technológiára alapoz, 8 gigabitet tud.
Szóval tudnék mesélni, mennyivel és miért jobb a TR, de felesleges ma már.
Szerintem is az Etherneté a jövő. A szükséges áramkörök filléresek. Szerintem egy az Ethernethez képest kis szériás csatoló, amelynek bonyolult protokoll vezérlő áramköre van, nem versenyezhet hosszú távon. Tudommásom szerint többen fejlesztenek determinisztikus protokollokat a Ethernetre, de szerintem önmagában egy "akkor válaszolj, ha kérdeztelek" jellegű protokoll önmagában is megteszi.
Engem inkább az HUB / switch szükségessége zavar, ami megölheti a teljes rendszert. Mert ha már a költség a fő szempont akkor UTP.
Persze a vonatkozó programok fejlesztése valószínűleg idő és költség igényes.
Na persze így nem lehetne méreg dárga pl. Profibus illesztőket eladni.
Sajna az FFB projektről nem sok mindent hallottam idáig, de majd nyári gyakorlaton megkérdek egy-két embert az automat. tanszéken Az ethernet csatolófelület tényleg rohamosan terjed... Ha jól láttam ma már kb. 10 PLC-ből legalább 6-nak van integrált ipari ethernet csatolófelülete... Ha egyszer vége lesz a vizsgaidőszaknak, nyári gyakorlaton mi is megpróbálkozunk valami ISA-s hálókártyát illeszteni a microcontrolleres fejlesztőeszközökhöz [PIC, 8051] aztán ha netán összejönne, lebonyolítani valami alapszintű kommunikációt 2 eszköz között...
Hi!! sztem. ahol az FFB, Profi, ASi technikák jól beváltak és működnek ott nemhiszem hogy fogják az egész hűbelebancot és hipp-hopp lecserélik ipari ethernetre... :) Az sem elhanyagolható tényező hogy az ipari eth.nettel nem kompatibilis PLC-kbe többszáz rúgó egy ethernet interface...
Az ethernet alapvetően véletlen hozzáférésű közeget biztosít. Nem befolyásolható, hogy egy adott ethernet eszköz egy adott időn belül szóhoz jusson. (Ennek főként nagy terhelés esetén van jelentősége.)
Nem tudom, hogy speciális eszkozökkel, módszerekkel mennyire lehet ezen javítani.
Ezért én bizonyos valós idejű vezérlési feladatoknál látom az ethernetet nehezen használhatónak.
Az Ethernet rohamosan terjed az automatizálásban. Már a terep felé is kacsintgat. Mi történik a Foundation Fieldbus-szal, Profibus-szal és a többiekkel? Melyek azok az alkalmazások, ahol az Ethernet nem győzhet?
