Misztikus hálózati, Ethernet hiba. Ja mégsem! - 2019-10-03-

Facebook: / tanyacsenol
Instagram: / tanya_csenol
Ha üzenni, kérdezni akarsz és nem itt, akkor anonim megteheted itt: goo.gl/forms/r... -------------------------------------------------------------------------------------------------------
Galéria : nincs
Kivonat: Egy ügyfelem kért fel, hogy segítsek az ő ügyfele és a közöttük lévő vitás helyzet megoldásában. A probléma, hogy egy soros/ethernet adatgyűjtőt helyben le tudnak kérdezni, de a távolabb lévő PLC erre már nem képes. Mindenki a másikra mutogatott.

[@Ampervadasz750kv]

5:43 Sírva verem az asztalt a nevetéstől. 🤣 Kegyetlen jó volt! Pontosan ilyen szerényen szoktam lekezelni a hasonló kritikus helyzetek kezelését. :D
A legújabb videódban ajánlotted, hogy ezt a vidót nézzem meg, így ide fogalmazok meg választ. :)
Ötlet a problémára.

Legelső: 

A MOXA PCL eszközt egysarkúlag le kell földelni ( negatív ág ) ott a jelelölés, hiányozni szokott.
- Az RS232 -es kapcsolathoz minél rövidebb és árnyékolt kábelt kell használni a PCL és a fejgép/mezőgép/RTU/PLC között (készülék/tápegység kiföldeléseknek is meg kell lennie).

- Áramhurok nem tud kialakulni mert a PCL eszköz galvanikusan elválasztott az adatvonalon. 


- A probléma azért tud így jelentkezni, mert TTL jelszintet használ nem a klasszikus +-15V -ot, akkor nem minden esetben létezne ez probléma.


-A jelenség teljesen normális:

A PCL fő ciklusa kezeli a soros portot (órajel kritikus végrehajtás, tehát azonnali végrehajtású), minden más feladat nem órajel kritikus.
Ezért tapasztalható a végpont “lefagyása”. (hiba csúszik az RTS CTS handshake folyamat vezérlésébe külső zavar miatt)
Iparibb megoldásoknál a port letiltódik és üzemkészség hibajelzést ad Ethernet hálózaton meg egy erősáramú kontaktuson egyszerre kivezetett sorkapcsára.
Szerencsétlen MOXA csak a dolgát teszi. :)
Ezért fontos a minél jobb minőségű lehetőleg minél rövidebb soros mullmodem kábel használata akár árnyékoltan egyik végpontján földelten vagy 1Mohm -on keresztül földelve.
-Pontosan ilyenbe futottam bele pár éve egy nyomdában ahol még ARC NET alapú volt a hálózat kezelése kiherélt S5 Simatic PLC fejgéppel és egy fejgép szerverrel.


-Ez volt az igazi sp-ó-ág mert ez itt egy Ethernet elődű hálózat volt üzemben.

-Sűrűn jöttek sorleállások mert rejtélyes módon véletlenszerű időkben összeomlott a teljes ARC NET hálózat.

Itt minden is volt:
terepi eszközök: BLDC és aszinkronmotor vezérlők, pneumatikus szeleptömbök, szinkronizált virtuális tengely vezérlők, terminálok ezek minden változata stb.

Kb. 100 -as nagyságú gyűrűs topológiával megálmodott förtelmek / sor, több aktív HUB -okkal karbantartó munkaállomásokkal felfűzve.


-Ezen kellett keresni a hibát (ha az egyik sor egyik terepi eszköze megkotlott akkor az összes független sor leállt (!) ), azonban itt nem lehet csak úgy újraindítgatni a rendszert mert lehet többet nem élednek fel az eszközök (rengeteg eszköz NVRAM ban tárolja a paramétereket lemerült gombelemekkel, ezer évesek a tápegységek).

-

Hibakeresés: egy módosítás után 7-10 percet kellett várni a felálláshoz, lekellett követni a szinkronizálási folyamatot, ahol elakadt ott az adott terepi eszköz kimenti iránya, vagy a következő bemeneti iránya, vagy buszlezáró ellenállás hibája, vagy koax sérülése / öregedése okozza a hibát, kivéve, ahol DB9 -es soros vonalhoz hasonlító volt ARC NET.

-A szinkronizációt terepi eszközökön néhány LED szolgáltatta, vagy egy hétszegmenses kijelző.


-Ami biztos, nagyon meg kellett anno ezt a hálózatot tervezni mert nagyon kifejletlen volt, több gyártó prototípus berendezésének kellett együtt dolgoznia, az overhead miatt iszonyúan kicsi az adatátvitel és egy hiba befogja dönteni a teljes szegmenst = nulla hibatűrés.
, nem menedzselhető, elemi elektonika, technológiai és informatikai ismereteket együtt követeli meg + analitikus megközelítés. További problémája a topológiának, hogy a sorrend nem változtatható, ha van egy hibás terepi eszköz akkor nem hagyható ki a szegmensből mert akkor a kiküldött keretek eltolódnak! Igen, mint egy shiftregiszterben. Remélem megvan a pornó faktor. 🤣
-A szinkronizálás során három eszközön is fennakadt a hibakeresés mikor be lett nyögve, hogy az egyik terminál néha elszokta veszíteni a lapszárítóval a kapcsolatot.

A hiba keresését abba hagytuk és egyből erre a gépre fókuszáltunk.


A Lapszárítónál három elosztószekrényben épült fel elemi szinten felépített PLC vezérlés, ahol a vezérlő egység kártyás és nyitott felépítésű volt. A kapcsolatot RS232 -n bonyolította, az ARC hálózattal meg egy pici 386sx terminálon keresztül volt kapcsolata a fejgép szerver felé.

A terminál és az ARC NET kártya hibátlan, a hiba az RS232 kommunikációban volt és a kábel is hibátlan.

A PLC CPU-COM kártyáját kitermelve a soros illesztő vonalában található (inverter) kondenzátorokat kicseréltem ami kb 60ft -nyi alkatrész, kártya visszatol, visszakapcsol, összekábelezés, terminál újraindít, S5 reset, Szerver fejgép start folyamat hibátlanul lefut és lásd üzemkész, beindulhat a befűzés, nyomtatás.


1986 -óta üzemel így a nyomda, majd 1995 -ben kapott ManRoland (Phoenix Contact előd) részleges felújítást és azóta is így üzemel.


Csak besegíteni voltam ott, mert nekem igazi pornó volt az ilyen a múzeumokban is ritkaságnak számító rendszert üzemben látni, javítani, éleszteni…
A hibák nem szüntek meg, azóta is rendszeresek leállások, viszont a lapszárító soha többet nem térdelt le.