En guide til ODOT I/O-fejlfinding

dække over

I industrielle produktionsaktiviteter er kvaliteten og stabiliteten af ​​hardwareprodukter afgørende for sikker og effektiv drift af hele produktionslinjen.Vi bør dog ikke overse softwarekonfiguration.Softwareproblemer kan også føre til systemnedbrud, datatab eller produktionslinjens manglende evne til at udføre sine opgaver korrekt, hvilket kan have en betydelig indvirkning på hele produktionsprocessen.Derfor er fejlfinding i både hardware- og softwareaspekter af det industrielle produktionsmiljø et nødvendigt skridt for at sikre, at udstyret fungerer problemfrit, garanterer produktionseffektivitet og opretholder sikkerhed og pålidelighed.

1

Lad os i dag dykke ned i et tilfælde i den virkelige verden, hvor softwarekonfiguration har påvirket produktionen.Lad os sørge for, at vi udfører fejlfinding effektivt i fremtiden for at sikre effektiviteten og pålideligheden af ​​automatiserede produktionslinjer!

1

2

Kundefeedback: Udstyret på stedet oplever problemer med, at CN-8032-L-modulet falder offline, hvilket resulterer i, at maskinen udløser et nødstop, og produktionslinjen stopper automatisk drift.Manuel indgriben er påkrævet for at genoprette normal drift, hvilket forårsager afbrydelser af almindelig produktion og test.Hvis problemet med moduler, der falder offline, ikke kan løses effektivt, vil det påvirke det endelige produktionsoutput.

 

2

Efter kommunikation på stedet med det tekniske personale blev det bekræftet, at ud af tre produktionslinjer oplevede to af dem det samme problem med moduler, der faldt offline på det samme sted.Cirka 1 sekund efter at de er gået offline, vil modulerne automatisk oprette forbindelse igen.Kunden havde tidligere forsøgt moduludskiftninger, hvilket ikke løste problemet.En indledende vurdering indikerede, at problemet sandsynligvis ikke var relateret til modulets kvalitet.Følgende fejlfindingstrin blev taget:

1. Opdaterede modulfirmwareoplysninger og program GSD-filer for at eliminere problemer med firmwarekompatibilitet.

2. Udskiftning af moduler igen for at udelukke potentielle individuelle modulfejl.

3. Verificeret netværks-, switches og strømforsyningshardwareoplysninger, hvilket stort set eliminerer hardware-relaterede problemer.

4. Ændrede netværksstrukturen for at eliminere potentielle netværksrelaterede faktorer.

5. Brug af filtre på strømforsyningen for at udelukke strømrelaterede problemer.

6. Undersøgt og løst eventuelle netværks IP-adressekonflikter.

7. Midlertidigt deaktiveret routeren, der forbinder til det eksterne netværk, hvilket reducerede hyppigheden af ​​frafald, men løste ikke problemet fuldstændigt.

8. Fangede netværkspakker og identificerede ikke-cykliske tjenestedatapakker i Profinet, hvilket fører til PLC-fejl på grund af pakketimeout.

9. Baseret på det foregående trin, undersøgte kundens program.

Ved at analysere netværksdatapakker blev det opdaget, at kunden brugte Siemens' Modbus kommunikationsprogram.Under udførelsen af ​​specifikke funktionsblokke indtastede de utilsigtet hardware-identifikationen for et funktionsmodul i programstifterne.Dette resulterede i, at PLC'en kontinuerligt sendte UDP-datapakker til det funktionsmodul, hvilket førte til en "ikke-cyklisk service timeout"-fejl og fik maskinen til at gå offline.

 

3

3

Problemet i ovenstående tilfælde adskiller sig fra den typiske PN-kommunikationstimeout forårsaget af netværksinterferens eller afbrydelser.Ikke-cykliske servicetimeouts er normalt relateret til kundeprogrammering, CPU-ydeevne og netværksbelastningskapacitet.Selvom sandsynligheden for, at dette problem opstår, er relativt lav, er det ikke umuligt, og fejlfinding af programmet eller netværksmiljøet kan udføres for at løse det i fremtiden.

Softwareproblemer er ofte mindre synlige, men med en samarbejdsorienteret og systematisk tilgang til fejlfinding kan vi identificere årsagen og løse problemer for at sikre problemfri produktion!

Så dette afslutter vores tekniske blog for denne session.Indtil næste gang!


Indlægstid: 17. oktober 2023