I industriell produksjon er kvaliteten og stabiliteten til maskinvareprodukter avgjørende for sikker og effektiv drift av hele produksjonslinjen.Vi bør imidlertid ikke overse programvarekonfigurasjon.Programvareproblemer kan også føre til systemkrasj, tap av data eller manglende evne til produksjonslinjen til å utføre oppgavene på riktig måte, noe som kan ha en betydelig innvirkning på hele produksjonsprosessen.Derfor, både i maskinvare- og programvareaspekter av det industrielle produksjonsmiljøet, er feilsøking et nødvendig skritt for å sikre at utstyret fungerer jevnt, garanterer produksjonseffektivitet og opprettholder sikkerhet og pålitelighet.
La oss i dag fordype oss i et tilfelle der programvarekonfigurasjon har påvirket produksjonen.La oss sørge for at vi gjør feilsøking effektivt i fremtiden for å sikre effektiviteten og påliteligheten til automatiserte produksjonslinjer!
1
Tilbakemelding fra kunder: Utstyret på stedet opplever problemer med at CN-8032-L-modulen faller frakoblet, noe som resulterer i at maskinen utløser en nødstopp og produksjonslinjen slutter automatisk.Manuell inngripen er nødvendig for å gjenopprette normal drift, noe som forårsaker forstyrrelser i vanlig produksjon og testing.Hvis problemet med moduler som faller frakoblet ikke kan løses effektivt, vil det påvirke den endelige produksjonen.
2
Etter kommunikasjon på stedet med teknisk personell, ble det bekreftet at av tre produksjonslinjer opplevde to av dem det samme problemet med moduler som faller offline på samme sted.Omtrent 1 sekund etter avbrudd frakoblet, kobles modulene automatisk til igjen.Kunden hadde tidligere forsøkt modulbytte, noe som ikke løste problemet.En første vurdering indikerte at problemet sannsynligvis ikke var relatert til modulens kvalitet.Følgende feilsøkingstrinn ble tatt:
1. Oppdatert modulfastvareinformasjon og programmer GSD-filer for å eliminere problemer med fastvarekompatibilitet.
2. Byttet ut moduler igjen for å utelukke potensielle individuelle modulfeil.
3. Verifisert maskinvareinformasjon om nettverk, brytere og strømforsyning, som i stor grad eliminerer maskinvarerelaterte problemer.
4. Modifisert nettverksstrukturen for å eliminere potensielle nettverksrelaterte faktorer.
5. Bruk av filtre på strømforsyningen for å utelukke strømrelaterte problemer.
6. Undersøkte og løste eventuelle nettverks-IP-adressekonflikter.
7. Midlertidig deaktivert ruteren som koblet til det eksterne nettverket, noe som reduserte frekvensen av frafall, men ikke løste problemet fullstendig.
8. Innfangede nettverkspakker og identifiserte ikke-sykliske tjenestedatapakker i Profinet, noe som fører til PLS-feil på grunn av pakketidsavbrudd.
9. Basert på forrige trinn, undersøkte kundens program.
Ved å analysere nettverksdatapakker ble det oppdaget at kunden brukte Siemens sitt Modbus-kommunikasjonsprogram.Under utførelsen av spesifikke funksjonsblokker la de utilsiktet inn maskinvareidentifikatoren til en funksjonsmodul i programpinnene.Dette resulterte i at PLS-en kontinuerlig sendte UDP-datapakker til den funksjonsmodulen, noe som førte til en "ikke-syklisk tjenestetidsavbrudd"-feil og fikk maskinen til å gå offline.
3
Problemet i tilfellet ovenfor skiller seg fra den typiske tidsavbruddet for PN-kommunikasjon forårsaket av nettverksinterferens eller -avbrudd.Ikke-sykliske tjenestetidsavbrudd er vanligvis relatert til kundeprogrammering, CPU-ytelse og nettverksbelastningskapasitet.Selv om sannsynligheten for at dette problemet oppstår er relativt lav, er det ikke umulig, og feilsøking av programmet eller nettverksmiljøet kan utføres for å løse det i fremtiden.
Programvareproblemer er ofte mindre synlige, men med en samarbeidende og systematisk tilnærming til feilsøking kan vi identifisere årsaken og løse problemer for å sikre jevn produksjon!
Så dette avslutter vår tekniske blogg for denne økten.Til neste gang!
Innleggstid: 17. oktober 2023
