En industriaj produktadaj agadoj, la kvalito kaj stabileco de aparataj produktoj estas decidaj por la sekura kaj efika funkciado de la tuta produktadlinio.Tamen, ni ne devus preteratenti programaran agordon.Programaro-problemoj ankaŭ povas konduki al sistema kraŝoj, datumperdo, aŭ la malkapablo de la produktadlinio plenumi siajn taskojn ĝuste, kiuj povas havi signifan efikon al la tuta produktada procezo.Sekve, en ambaŭ aparataj kaj programaj aspektoj de la industria produktadmedio, problemo-solvado estas necesa paŝo por certigi, ke ekipaĵo funkcias glate, garantias produktan efikecon kaj konservi sekurecon kaj fidindecon.
Hodiaŭ, ni enprofundiĝu en real-mondan kazon kie programara agordo influis produktadon.Ni certigu, ke ni faru problemojn efike en la estonteco por certigi la efikecon kaj fidindecon de aŭtomataj produktadlinioj!
1
Klienta reagoj: La ekipaĵo surloke spertas problemojn kun la CN-8032-L-modulo falanta eksterrete, rezultigante la maŝino ekfunkciigante krizhalton kaj la produktadlinio ĉesas aŭtomatan funkciadon.Mana interveno estas postulata por restarigi normalan operacion, kaŭzante interrompojn al regula produktado kaj testado.Se la problemo de moduloj mallaŭtigitaj ne povas esti efike solvita, ĝi influos la finan produktadon.
2
Post surloka komunikado kun la teknika personaro, estis konfirmite, ke el tri produktadlinioj, du el ili spertis la saman problemon de moduloj falantaj eksterrete en la sama loko.Proksimume 1 sekundon post forigo de eksterrete, la moduloj aŭtomate rekonektus.La kliento antaŭe provis modulajn anstataŭaĵojn, kiuj ne solvis la problemon.Komenca takso indikis, ke la afero verŝajne ne rilatas al la kvalito de la modulo.La sekvaj solvoj de problemoj estis faritaj:
1. Ĝisdatigitaj modulaj firmware-informoj kaj programaj GSD-dosieroj por forigi problemojn pri firmware-kongruo.
2. Anstataŭigitaj moduloj denove por ekskludi eblajn individuajn modulajn difektojn.
3. Kontrolita reto, ŝaltiloj kaj elektroprovizo aparataro informo, plejparte forigante aparataro-rilataj problemoj.
4. Modifis la retan strukturon por forigi eblajn reto-rilatajn faktorojn.
5. Uzante filtrilojn sur la nutrado por ekskludi problemojn rilatajn al potenco.
6. Esploris kaj solvis ajnajn retajn IP-adreskonfliktojn.
7. Provizore malŝaltis la enkursigilon konektantan al la ekstera reto, kio reduktis la ofteco de faloj sed ne tute solvis la problemon.
8. Kaptitaj retaj pakoj kaj identigitaj ne-ciklaj servaj datumpakaĵoj en Profinet, kondukante al PLC-eraroj pro pakaĵetaj tempoj.
9. Bazita sur la antaŭa paŝo, ekzamenis la programon de la kliento.
Analizante retajn datumpakaĵojn, estis malkovrite ke la kliento uzis Modbus-komunikadprogramon de Siemens.Dum la ekzekuto de specifaj funkcioblokoj, ili preterintence enigis la hardvaridentigilon de unu funkciomodulo en la programpinglojn.Tio rezultigis la PLC ade sendanta UDP-datumpakaĵojn al tiu funkciomodulo, kaŭzante "ne-ciklan servotempon" eraron kaj igante la maŝinon iri eksterrete.
3
La problemo en ĉi-supra kazo diferencas de la tipa PN-komunikada tempodaŭro kaŭzita de reto-interfero aŭ interrompoj.Ne-ciklaj servtempotempoj estas kutime rilatitaj al klientprogramado, CPU-efikeco, kaj retŝarĝokapacito.Kvankam la verŝajneco de ĉi tiu problemo okazanta estas relative malalta, ĝi ne estas malebla, kaj solvo de problemoj de la programo aŭ reto medio povas esti entreprenita por trakti ĝin en la estonteco.
Programaraj problemoj ofte estas malpli videblaj, sed kun kunlabora kaj sistema aliro al solvi problemojn, ni povas identigi la radikan kaŭzon kaj solvi problemojn por certigi glatan produktadon!
Do, ĉi tio finas nian teknikan blogon por ĉi tiu sesio.Ĝis la venonta fojo!
Afiŝtempo: Oct-17-2023
