En guide till ODOT I/O-felsökning

omslag

Inom industriell produktionsverksamhet är hårdvaruprodukternas kvalitet och stabilitet avgörande för säker och effektiv drift av hela produktionslinjen.Vi bör dock inte förbise mjukvarukonfigurationen.Programvaruproblem kan också leda till systemkrascher, dataförlust eller produktionslinjens oförmåga att utföra sina uppgifter korrekt, vilket kan ha en betydande inverkan på hela produktionsprocessen.Därför, i både hårdvaru- och mjukvaruaspekter av den industriella produktionsmiljön, är felsökning ett nödvändigt steg för att säkerställa att utrustningen fungerar smidigt, garanterar produktionseffektivitet och bibehåller säkerhet och tillförlitlighet.

1

Låt oss idag fördjupa oss i ett verkligt fall där programvarukonfiguration har påverkat produktionen.Låt oss se till att vi gör felsökning effektivt i framtiden för att säkerställa effektiviteten och tillförlitligheten hos automatiserade produktionslinjer!

1

2

Kundfeedback: Utrustningen på plats har problem med att CN-8032-L-modulen faller offline, vilket resulterar i att maskinen utlöser ett nödstopp och att produktionslinjen upphör automatiskt.Manuellt ingripande krävs för att återställa normal drift, vilket orsakar avbrott i regelbunden produktion och testning.Om problemet med moduler som faller offline inte kan lösas effektivt, kommer det att påverka den slutliga produktionen.

 

2

Efter kommunikation på plats med den tekniska personalen bekräftades det att av tre produktionslinjer upplevde två av dem samma problem med moduler som tappade offline på samma plats.Ungefär 1 sekund efter att de släppts offline, återansluts modulerna automatiskt.Kunden hade tidigare försökt byta moduler, vilket inte löste problemet.En första bedömning visade att problemet sannolikt inte var relaterat till modulens kvalitet.Följande felsökningssteg vidtogs:

1. Uppdaterad modulfirmwareinformation och program GSD-filer för att eliminera problem med firmwarekompatibilitet.

2. Byt ut moduler igen för att utesluta potentiella individuella moduldefekter.

3. Verifierad information om nätverk, switchar och strömförsörjning, vilket i stort sett eliminerar maskinvarurelaterade problem.

4. Ändrade nätverksstrukturen för att eliminera potentiella nätverksrelaterade faktorer.

5. Använda filter på strömförsörjningen för att utesluta strömrelaterade problem.

6. Undersökte och löste eventuella konflikter med nätverkets IP-adress.

7. Inaktiverade tillfälligt routerns anslutning till det externa nätverket, vilket minskade frekvensen av avhopp men inte löste problemet helt.

8. Fångade nätverkspaket och identifierade icke-cykliska tjänstedatapaket i Profinet, vilket leder till PLC-fel på grund av pakettimeout.

9. Basad på föregående steg, undersökte kundens program.

Genom att analysera nätverksdatapaket upptäcktes att kunden använde Siemens kommunikationsprogram Modbus.Under exekveringen av specifika funktionsblock matade de oavsiktligt in hårdvaruidentifieraren för en funktionsmodul i programstiften.Detta resulterade i att PLC:n kontinuerligt skickade UDP-datapaket till den funktionsmodulen, vilket ledde till ett "icke-cykliskt service timeout"-fel och fick maskinen att gå offline.

 

3

3

Problemet i ovanstående fall skiljer sig från den typiska timeout för PN-kommunikation som orsakas av nätverksstörningar eller avbrott.Icke-cykliska servicetimeouts är vanligtvis relaterade till kundprogrammering, CPU-prestanda och nätverksbelastningskapacitet.Även om sannolikheten för att detta problem uppstår är relativt liten, är det inte omöjligt, och felsökning av programmet eller nätverksmiljön kan göras för att lösa det i framtiden.

Programvaruproblem är ofta mindre synliga, men med ett samarbetande och systematiskt förhållningssätt till felsökning kan vi identifiera grundorsaken och lösa problem för att säkerställa en smidig produktion!

Så, detta avslutar vår tekniska blogg för denna session.Tills nästa gång!


Posttid: 17-10-2023