I dag deler jeg en praktisk artikel for at hjælpe dig med at forstå, hvordan et perfekt PLC-program ser ud, og giver PLC-programmeringsstandarder og forslag til praktisk arbejde.
Designkrav til et perfekt PLC-program:
Et komplet PLC-program handler ikke kun om at få systemet til at køre; det kræver også komplette kommentarer, en vel-struktureret arkitektur, god skalerbarhed, et omfattende alarm- og beskyttelsessystem og et forud-kørt simuleringssystem.
1. Enkelhed
Gør PLC-programmet så enkelt som muligt. Enkelhed betyder at bruge en standardiseret programramme og enkle instruktioner. Det handler i store træk om at optimere programstrukturen og forenkle programmet med flowstyringsinstruktioner. Mere specifikt betyder det at udskifte enkelt-funktionsinstruktioner med mere kraftfulde og være opmærksom på rækkefølgen af instruktionerne.
2. Læsbarhed
Det designede program skal være yderst læsbart. Dette hjælper ikke kun programmøren til bedre at forstå programmet og letter fejlfinding, men det gør det også nemt for andre at forstå og for brugere at vedligeholde. Det bør også lette programudbredelsen, når det er nødvendigt.
For at sikre god læsbarhed bør programdesignet være så klart som muligt. Vær opmærksom på hierarki og modularitet, selv ved at bruge objekt-orienterede designmetoder. Brug standarddesignpraksis så meget som muligt.
Hvis der bruges programmeringssprog i særlige tilfælde, bør stigediagrammer bruges i de fleste tilfælde for lettere læsbarhed. I/O-allokering bør være systematisk for lettere at huske og forstå. Tilføj kommentarer, når det er nødvendigt. Brugen af interne komponenter bør også være systematisk; undgå at bruge dem tilfældigt.
Læsbarheden bør overvejes fra begyndelsen af programdesign. Dette er ikke let at opnå helt, for under programfejlretning kan tilføjelse eller fjernelse af instruktioner og ændringer i brugen af interne komponenter gøre et oprindeligt klart program noget rodet. Tillad derfor justeringer under fejlretning i designfasen, og ryd derefter op efter fejlretning. Dette vil resultere i et program af højere kvalitet.
Programkommentarer skal mindst omfatte følgende:
A. Systemkommentarer: Ophavsretsindehaveren og formålet med hele programmet; B. Blokkommentarer: Hovedformål og forfatter af blokken; C. Segmentkommentarer: Formålet med kodesegmentet; D. Variablekommentarer: Vigtigheden er tydelig-, inklusive I/O-kommentarer og intermediære variablekommentarer. Med hensyn til fortrolighedshensyn bør disse behandles gennem krypteringsalgoritmen eller blokkryptering af programmet, snarere end ved at reducere kommentarer.
3. Rigtighed
PLC-programmet skal være korrekt og verificeret gennem faktisk drift for at bevise dets korrekte funktion. Dette er det mest grundlæggende krav til et PLC-program; hvis dette ikke opnås, uanset hvor gode de andre aspekter er, er de ubrugelige.
For at sikre programmets korrekthed skal instruktioner og interne enheder bruges nøjagtigt. Nøjagtig brug af instruktioner er forbundet med nøjagtig forståelse af dem; Derfor skal instruktionernes betydning og brugsbetingelser forstås grundigt. Om nødvendigt kan der skrives små programmer for at teste nogle uklare instruktioner.
For den samme instruktion kan nogle instruktionsdetaljer variere på grund af forskelle i PLC-produktionspartier eller seriemodeller. Programmeringsmanualen bør konsulteres omhyggeligt.
Den korrekte brug af interne enheder er også vigtig. Nogle PLC'er har f.eks. nedluknings-beskyttelse, mens andre ikke har. Det er vigtigt at sikre, at der bruges enheder, der kræver nedluknings-beskyttelse, og omvendt.
Kort sagt er det mest fundamentale krav til PLC-programmer at bruge instruktionerne nøjagtigt og bruge interne komponenter korrekt for at sikre, at det programmerede program kører korrekt.
For et simpelt eksempel kræver Siemens PLC'er variable med lagringsfunktionalitet som mellemvariable for stigende og faldende kanter, såsom M-punkter eller DB-punkter. Brug af FC's temp variabel ville give problemer.
4. Pålidelighed
Programmer skal ikke kun være korrekte, men også pålidelige. Pålidelighed afspejler stabiliteten af PLC-programmet, hvilket også er et grundlæggende krav.
Nogle PLC-programmer fungerer korrekt under normale driftsforhold eller under lovlige operationer, men fungerer ikke korrekt under unormale driftsforhold (såsom et midlertidigt strømafbrydelse efterfulgt af hurtig strømgenoprettelse) eller efter ulovlige operationer (såsom at trykke på knapper ude af rækkefølge eller trykke på flere knapper samtidigt). Sådanne programmer er upålidelige, ustabile eller dårligt designet.
Gode PLC-programmer kan identificere unormale driftsforhold og problemfrit integrere dem med normale forhold, hvilket gør det muligt for programmet at tilpasse sig forskellige situationer. Et godt PLC-program kan afvise ulovlige operationer uden at efterlade nogen "spor" og kun acceptere lovlige operationer.
Interlocking er en almindelig metode til at afvise ulovlige operationer; relækredsløb bruger ofte denne metode, og PLC'er kan også arve denne tilgang.
5. Nem modifikation
Et program skal være nemt at ændre. Et af kendetegnene ved en PLC er dens bekvemmelighed og fleksibilitet til at tilpasse sig forskellige situationer. Dette opnås ved at ændre eller omdesigne programmet.
Redesign af programmet bruges, når applikationskravene til PLC'ens proces skal ændres. Ikke kun er programmet omskrevet, men I/O skal også omfordeles. I de fleste tilfælde er det ikke nødvendigt at omskrive programmet; mindre ændringer er tilstrækkelige. Dette kræver, at programmet er nemt at ændre.
Nem modifikation betyder også fleksibilitet, der kun kræver mindre ændringer for at opnå formålet med at ændre parametre eller ændre handlinger.
6. Udvidelsesmuligheder
Mange programmer kan være forud-programmeret før implementering på webstedet, men yderligere programmer skal muligvis tilføjes på-webstedet. For at undgå at forstyrre den overordnede systemstruktur skal der reserveres tilstrækkelig plads i hvert funktionsområde til backup-hardware. Softwaren skal være designet med manuel, automatisk og semi-automatisk drift i tankerne, og pladsen bør tildeles i overensstemmelse hermed.
7. Omfattende alarmsystem
PLC-systemer bruges ofte i industrielle miljøer, hvor enhver ulykke kan forårsage tab, store som små. For at sikre forebyggelse af ulykker eller minimere tab ved en ulykke, skal PLC'ens alarm- og beskyttelsesfunktioner fremhæves. Derfor fremhæves dette som en vigtig komponent i systemet.
8. Programsimulering
For at sikre-fejlretningsfremskridt på webstedet eller til kundedemonstrationer kræves der ofte en fuldautomatisk simulering af programmet før implementering. Dette nødvendiggør tilføjelse af en simuleringsprogramsektion til det eksisterende program, som afbrydes efter normal-drift på stedet. For at gøre det muligt for programmet at udføre simulering, kræves følgende trin:
(1) Konverter de faktiske PLC I/O-punkter til mellemvariable eller datablokvariable;
(2) Skriv simuleringsprogrammer for hvert stykke udstyr i henhold til proceskrav.
Et godt PLC-program kan betragtes som et, der opfylder ovenstående krav.
PLC-programmeringsspecifikationer
1. Vælg den relevante PLC-model og I/O-punkttælling. Vælg specielle funktionsmoduler til specifikke funktionskrav.
2. Vær bekendt med de valgte PLC-programmeringsinstruktioner og kompileringssoftware.
3. Planlæg de bløde komponenter, herunder interne relæer, holderelæer, dataregistre, timere og tællere.
4. Planlæg programmet, generelt efter sekvensen af fejludtrækning, fejlhåndtering, manuel håndtering, automatisk håndtering og outputhåndtering. Større projekter eller udstyr bør opdeles i funktionelle enheder, såsom elevatorer, overførselsanordninger og løfte-/rotationsanordninger i en automatiseret produktionslinje. Disse skal programmeres i segmenter og blokke i henhold til ovenstående enhedsstruktur.
5. Tilføj korte segmentkommentarer før hvert segmenteret eller blok-baseret program, der forklarer dets funktion. Angiv om nødvendigt det tilsvarende procesflow. Rækkefølgen af segmenterede eller blok-baserede programmer inden for det overordnede program bør generelt følge procesforløbssekvensen for læsbarhed.
6. Inden programdesign skal udstyret abstraheres. Fælles faktorer såsom stop, nødstop, overbelastning, over-grænse, timeout, sikkerhedslysgardin, kollisionsstop og dørkontakt bør trækkes ud og placeres i start-op-kredsløbet eller opstart-hovedkontrol- og interlock-kredsløb. Dette fungerer som den overordnede præmis for hele programstrukturen. Ud fra dette opdeles programmet så i to hovedfunktionsområder: automatisk og manuel.
7. Fælles faktorer i det manuelle funktionsområde af programstrukturen, såsom manuel betjening og faktorer, der bringer udstyr og personlig sikkerhed i fare, bør udtrækkes og placeres i det manuelle hovedkontrol- og spærrekredsløb for at beskytte, afskærme og alarmere for manuel kontrol.
8. Fælles faktorer i det automatiske funktionsområde i programstrukturen, såsom automatisk drift, over-grænse og timeout-faktorer, bør udtrækkes og placeres i det automatiske hovedkontrol- og spærrekredsløb for at beskytte, afskærme og alarmere for udstyr under automatisk kontrol. Et generelt princip er strengt at begrænse udstyrs adgang, mens udstyret løst begrænses, hvilket sikrer sikkerheden.
9. En master reset-funktion bør designes i programmet for at lette hurtig og nem gendannelse af normal udstyrsfunktion i tilfælde af funktionsfejl. Master-nulstillingen bør fuldt ud tage højde for sikkerheden for udstyr og personale under nulstillingsprocessen.
10. Når du skifter fra automatisk tilstand til manuel tilstand, bør programmet slette udgangene og mellemtilstandene fra automatisk tilstand. Især når SET-instruktionen bruges i automatisk tilstand, skal den slettes ved hjælp af RESET-instruktionen i manuel tilstand.
11. Dobbelt udgange er strengt forbudt i programmering; det vil sige, at den samme output-sætning eller den samme output-spole optræder to eller flere gange i programmet. For det samme udgangspunkt under forskellige tilstandsforhold skal du bruge et mellemrelæ til overførsel og til sidst kombinere dem til et enkelt udgangspunkt.
12. Ved brug af berøringsskærm må kontrolområdet og statusområdet, der deles af berøringsskærmen og PLC'en, ikke bruges til anden funktionel programmering.
13. Før du bruger et særligt PLC-modul, skal du kontrollere, om dets kontrolområde og statusområde optager arbejdsord. Hvis det er tilfældet, skal du ikke programmere disse arbejdsord til andre formål.
14. PLC-indgange, -udgange, mellemrelæer, timere, tællere og dataregistre skal være annoteret med kinesiske tegn. Input og output skal også indeholde komponentnavne og tag-numre. De tilsvarende indgangspunkter er generelt indstillet til NO-kontakter forbundet til eksterne kontakter. For indgange, der kræver NC-kontakter, skal dette angives i bemærkningerne. Alle kommentarer skal være klare og utvetydige, undgå misforståelser og minimere brugen af generiske termer.
15. Efter at projektfejlretningen er afsluttet, skal det endelige softwareprogram bibeholdes. Det gemte filnavn skal indeholde projektnummer, forfatter, dato og versionsnummer.
16. Vedrørende programkryptering: Adgangskoden til det krypterede program skal gemmes i en dedikeret fil, der tydeligt angiver brugernavn, adgangskode og tilladelser. Denne fil bør distribueres til mindst to personer for at lære adgangskoden og forhindre, at programmet bliver utilgængeligt på grund af tab af adgangskode.
Programmeringsforslag
1. Når en PLC og en værtscomputer (eller berøringsskærm) danner et overvågningssystem, skal skærmen ofte vise kontroltilstande såsom "manuel" og "automatisk" (generelt kan flere tilstande kun have én). "MOV" instruktionen kan bruges i programmet. For eksempel, når "manuel" er valgt, flyttes konstanten 1 ind i register VB10; når "automatisk" er valgt, flyttes 2 ind i samme register VB10. Ved at kontrollere dataene i registret kan systemets kontroltilstand bestemmes. Fordelen ved denne tilgang er dens lette forståelse og undgår behovet for komplekse procedurer som sammenlåsning.
2. Når programmet involverer analog signalstyring, hvis det læste analoge signal praktisk talt ikke har nogen fejl, kan tidsfiltrering bruges til at forsinke inputtet. Hvis de læste data har en stor fejl, er andre filtreringsmetoder nødvendige, såsom gennemsnit. Se relevant dokumentation for yderligere information.
3. Under programfejlfinding, hvis en betingelse er opfyldt, men udgangsspolen ikke er aktiveret, skal du kontrollere, om denne sektion af dit program er inden for sådanne sætninger, såsom "JUMP go to". En anden mulighed er, at betingelsen er opfyldt efter en programafbrydelse, men der er ingen output; dette indikerer normalt, at denne del af programmet ikke bliver scannet.
4. I sekventielle kontrolprogrammer, dvs. når en handling er fuldført og den næste handling påbegyndes, er +10+10 kontroltilstanden meget praktisk. Ideen er som følger: Et register er forudindstillet til 0 under initialisering. Efter systemstart øges den med 10, hvilket bringer registerværdien til 10. Med registret på 10 kan den første handling udføres. Efter den første handling øges registeret med 10 igen, hvilket bringer registerværdien til 20, hvilket gør det muligt at udføre den anden handling. Efter den anden handling øges den med 10 igen, hvilket bringer registerværdien til 30. På denne måde kan den ønskede handling bestemmes ved at kontrollere værdien i registeret. Når en hop-handling er nødvendig, kan stigningen ændres fra 10 til 20, 30 osv., afhængigt af de specifikke krav.
Hvorfor øges med 10 i stedet for 1? Fordi efter en stigning med 10, hvis et segment skal indsættes, kan det indsættes i en hvilken som helst af de 10 tilgængelige slots.
5. Ved design af et program, hvis der opstår en proces-relateret fejl (ikke styret af kontrolsystemet), er det bedst at vedligeholde fejlfænomenet og give visuelle og hørbare alarmer, indtil operatøren nulstiller systemet, så de er opmærksomme på fejlen. Ellers, hvis systemet stopper, kan andre antage, at der er et problem med programmet. Disse punkter bør generelt overvejes, når et nyt system designes.
6. Ofte kaldede underrutiner kan laves om til undermoduler til hyppige opkald.
7. Da hvert trin i en produktionsmaskines arbejdscyklus kræver en vis mængde tid at udføre, og disse tider har visse grænser, kan en timer startes samtidig med starten af det trin, der skal overvåges. Timerens tidsindstilling skal være 20 %–30 % længere end den normale varighed af handlingen. Timerens udgangssignal kan bruges til alarmer eller automatiske nedlukningsenheder. Når tiden for et trin overskrider den specificerede tid, når den tilsvarende forudindstillede tid, og før næste trin begynder, udsender timeren et fejlsignal. Dette signal stopper den normale arbejdscyklus og starter alarm- eller nedlukningsproceduren; det er det, vi almindeligvis kalder over-cyklusbeskyttelse.
8. Nogle sikkerhedsdetekteringskontakter (såsom nødstopknapper, sikkerhedslysgardiner, endestop osv.) bør bruge normalt lukkede (NC) indgange.
9. Af hensyn til sikkerhed og energibesparelse bør udgange designes til kun at aktiveres, når det er nødvendigt og stoppe, når handlingen er afsluttet, i stedet for at være designet til at udsende kontinuerligt, indtil et stop er påkrævet.
10. Driftsprincippet for aktuatorer bør være: bedre at forblive stille end at bevæge sig uregelmæssigt.
11. Enkelt-enhedsudstyrskontrol: Hver enhed skal have en manuel/automatisk omskiftningsfunktion og en start/stopfunktion under manuel drift. Ved skift fra automatisk til manuel drift må udstyret ikke stoppe; ved skift fra manuel til automatisk, afhænger udstyrets start/stop af det automatiske program.
12. Hver enhed af udstyr (pumpe, ventilator og andet stort udstyr) skal roteres efter 24 timers drift, og der skal være en kumulativ driftstidsrekord, medmindre start/stop-sekvensen er indstillet af værtscomputeren; ellers skal operatøren indstille det manuelt.
