I dag deler jeg en praktisk artikkel for å hjelpe deg å forstå hvordan et perfekt PLS-program ser ut, og gir PLS-programmeringsstandarder og forslag til praktisk arbeid.
Designkrav for et perfekt PLS-program:
Et komplett PLS-program handler ikke bare om å få systemet til å kjøre; det krever også fullstendige kommentarer, en godt-strukturert arkitektur, god skalerbarhet, et omfattende alarm- og beskyttelsessystem og et forhånds-simuleringssystem.
1. Enkelhet
Gjør PLS-programmet så enkelt som mulig. Enkelhet betyr å bruke et standardisert programrammeverk og enkle instruksjoner. I store trekk innebærer dette å optimere programstrukturen og forenkle programmet med flytkontrollinstruksjoner. Mer spesifikt betyr det å erstatte enkelt-funksjonsinstruksjoner med kraftigere og ta hensyn til rekkefølgen på instruksjonene.
2. Lesbarhet
Det utformede programmet skal være svært lesbart. Dette hjelper ikke bare programmereren bedre å forstå programmet og letter feilsøking, men gjør det også enkelt for andre å forstå og for brukere å vedlikeholde. Det bør også legge til rette for programspredning når det er nødvendig.
For å sikre god lesbarhet bør programdesignet være så oversiktlig som mulig. Vær oppmerksom på hierarki og modularitet, til og med bruk objekt-orienterte designmetoder. Bruk standard designpraksis så mye som mulig.
Hvis programmeringsspråk brukes i spesielle tilfeller, bør stigediagrammer brukes i de fleste tilfeller for lettere lesbarhet. I/O-allokering bør være systematisk for enklere memorering og forståelse. Legg til kommentarer når det er nødvendig. Bruken av interne komponenter bør også være systematisk; unngå å bruke dem tilfeldig.
Lesbarhet bør vurderes fra begynnelsen av programdesign. Dette er ikke lett å oppnå helt, for under programfeilsøking kan tillegg eller fjerning av instruksjoner og endringer i bruken av interne komponenter gjøre et opprinnelig oversiktlig program noe rotete. Tillat derfor justeringer under feilsøking i designfasen, og ryd deretter opp etter feilsøking. Dette vil resultere i et program av høyere kvalitet.
Programkommentarer bør minst inneholde følgende:
A. Systemkommentarer: Opphavsrettsinnehaver og formålet med hele programmet; B. Blokkkommentarer: Hovedformål og forfatter av blokken; C. Segmentkommentarer: Formålet med kodesegmentet; D. Variablekommentarer: Viktigheten er åpenbar-, inkludert I/O-kommentarer og mellomliggende variabelkommentarer. Når det gjelder konfidensialitetshensyn, bør disse løses gjennom krypteringsalgoritmen eller blokkkryptering av programmet, snarere enn ved å redusere kommentarer.
3. Riktighet
PLS-programmet må være korrekt og verifisert gjennom faktisk drift for å bevise dets korrekte funksjon. Dette er det mest grunnleggende kravet til et PLS-program; hvis dette ikke oppnås, uansett hvor gode de andre aspektene er, er de ubrukelige.
For å sikre at programmet er korrekt, må instruksjoner og interne enheter brukes nøyaktig. Nøyaktig bruk av instruksjoner er knyttet til nøyaktig forståelse av dem; derfor må betydningen og bruksbetingelsene til instruksjonene være grundig forstått. Om nødvendig kan små programmer skrives for å teste noen uklare instruksjoner.
For den samme instruksjonen, på grunn av forskjeller i PLS-produksjonsbatcher eller seriemodeller, kan noen instruksjonsdetaljer variere. Programmeringshåndboken bør konsulteres nøye.
Riktig bruk av interne enheter er også viktig. Noen PLS-er har for eksempel strøm-beskyttelse, mens andre ikke har det. Det er viktig å sikre at enheter som krever-avslutningsbeskyttelse brukes, og omvendt.
Kort sagt, det mest grunnleggende kravet til PLS-programmer er å bruke instruksjoner nøyaktig og riktig utnytte interne komponenter for å sikre at det programmerte programmet kjører riktig.
For et enkelt eksempel krever Siemens PLS-er variabler med lagringsfunksjonalitet som mellomvariabler for stigende og fallende kanter, for eksempel M-punkter eller DB-punkter. Bruk av FCs temp-variabel ville forårsake problemer.
4. Pålitelighet
Programmer må ikke bare være korrekte, men også pålitelige. Pålitelighet gjenspeiler stabiliteten til PLS-programmet, som også er et grunnleggende krav.
Noen PLS-programmer fungerer riktig under normale driftsforhold eller under lovlige operasjoner, men fungerer ikke ordentlig under unormale driftsforhold (som et midlertidig strømbrudd etterfulgt av rask strømgjenoppretting) eller etter ulovlige operasjoner (som å trykke knapper ut av rekkefølge eller trykke på flere knapper samtidig). Slike programmer er upålitelige, ustabile eller dårlig utformet.
Gode PLS-programmer kan identifisere unormale driftsforhold og sømløst integrere dem med normale forhold, slik at programmet kan tilpasse seg ulike situasjoner. Et godt PLS-program kan avvise ulovlige operasjoner uten å etterlate noen "spor", og aksepterer bare lovlige operasjoner.
Forrigling er en vanlig metode for å avvise ulovlige operasjoner; relékretser bruker ofte denne metoden, og PLS-er kan også arve denne tilnærmingen.
5. Enkel modifikasjon
Et program skal være enkelt å endre. En av egenskapene til en PLS er dens bekvemmelighet og fleksibilitet i å tilpasse seg ulike situasjoner. Dette oppnås ved å modifisere eller redesigne programmet.
Redesign av programmet brukes når applikasjonskravene til PLS-prosessen må endres. Ikke bare omskrives programmet, men I/O må også omfordeles. I de fleste tilfeller er det ikke nødvendig å omskrive programmet; mindre modifikasjoner er tilstrekkelig. Dette krever at programmet er enkelt å endre.
Enkel modifikasjon betyr også fleksibilitet, som bare krever mindre endringer for å oppnå formålet med å endre parametere eller modifisere handlinger.
6. Utvidbarhet
Mange programmer kan være forhånds-programmert før distribusjon på nettstedet, men det kan hende at flere programmer må legges til på-siden. For å unngå å forstyrre den generelle systemstrukturen, må det reserveres tilstrekkelig plass i hvert funksjonsområde for sikkerhetskopiering av maskinvare. Programvaren bør utformes med tanke på manuell, automatisk og semi-automatisk drift, og plass bør tildeles deretter.
7. Omfattende alarmsystem
PLS-systemer brukes ofte i industrielle miljøer, hvor enhver ulykke kan forårsake tap, store som små. For å sikre forebygging av ulykker eller minimere tap ved en ulykke, må PLSens alarm- og beskyttelsesfunksjoner vektlegges. Derfor fremheves dette som en viktig komponent i systemet.
8. Programsimulering
For å sikre-feilsøkingsfremdrift på nettstedet eller for kundedemonstrasjoner, kreves ofte en helautomatisk simulering av programmet før distribusjon. Dette nødvendiggjør å legge til en simuleringsprogramdel til det eksisterende programmet, som kobles fra etter normal-operasjon på stedet. For å gjøre det mulig for programmet å utføre simulering, kreves følgende trinn:
(1) Konverter de faktiske PLS I/O-punktene til mellomliggende variabler eller datablokkvariabler;
(2) Skriv simuleringsprogrammer for hvert utstyr i henhold til prosesskrav.
Et godt PLS-program kan betraktes som et som oppfyller kravene ovenfor.
PLS programmeringsspesifikasjoner
1. Velg riktig PLS-modell og I/O-punkttelling. Velg spesielle funksjonsmoduler for spesifikke funksjonskrav.
2. Vær kjent med de valgte PLS-programmeringsinstruksjonene og kompileringsprogramvaren.
3. Planlegg de myke komponentene, inkludert interne releer, holdereleer, dataregistre, tidtakere og tellere.
4. Planlegg programmet, generelt ved å følge sekvensen for feilutvinning, feilhåndtering, manuell håndtering, automatisk håndtering og utgangshåndtering. Større prosjekter eller utstyr bør deles inn i funksjonelle enheter, som heiser, overføringsenheter og løfte-/roterende enheter i en automatisert produksjonslinje. Disse skal programmeres i segmenter og blokker i henhold til enhetsstrukturen ovenfor.
5. Legg til korte segmentkommentarer før hvert segmenterte eller blokk{1}}baserte program, og forklarer funksjonen. Om nødvendig, angi tilsvarende prosessflyt. Rekkefølgen på segmenterte eller blokk-baserte programmer i det overordnede programmet bør generelt følge prosessflytsekvensen for lesbarhet.
6. Før programdesign bør utstyret abstraheres. Vanlige faktorer som stopp, nødstopp, overbelastning, over-grense, tidsavbrudd, sikkerhetslysgardin, kollisjonsstopp og dørbryter bør trekkes ut og plasseres i oppstartskretsen- eller oppstarts-hovedkontroll- og forriglingskretsen. Dette fungerer som det overordnede premisset for hele programstrukturen. På bakgrunn av dette deles programmet så inn i to hovedfunksjonsområder: automatisk og manuell.
7. Vanlige faktorer i det manuelle funksjonsområdet til programstrukturen, som manuell betjening og faktorer som setter utstyr og personsikkerhet i fare, bør trekkes ut og plasseres i den manuelle hovedkontroll- og forriglingskretsen for å beskytte, skjerme og alarmere for manuell kontroll.
8. Vanlige faktorer i det automatiske funksjonsområdet til programstrukturen, for eksempel automatisk drift, over-grense- og tidsavbruddsfaktorer, bør trekkes ut og plasseres i den automatiske hovedkontroll- og forriglingskretsen for å beskytte, skjerme og alarmere utstyr under automatisk kontroll. Et generelt prinsipp er å strengt begrense innkjøring av utstyr samtidig som utstyrsutgang begrenses løst, for å sikre sikkerhet.
9. En hovedtilbakestillingsfunksjon bør utformes i programmet for å lette rask og enkel gjenoppretting av normal utstyrsdrift i tilfelle feil. Hovedtilbakestillingen bør fullt ut vurdere sikkerheten til utstyr og personell under tilbakestillingsprosessen.
10. Når du bytter fra automatisk modus til manuell modus, skal programmet fjerne utgangene og mellomtilstandene fra automatisk modus. Spesielt når du bruker SET-instruksjonen i automatisk modus, må den slettes ved hjelp av RESET-instruksjonen i manuell modus.
11. Doble utganger er strengt forbudt i programmering; det vil si den samme utgangssetningen eller den samme utgangsspolen som vises to eller flere ganger i programmet. For det samme utgangspunktet under forskjellige modusforhold, bruk et mellomrelé for overføring, og kombiner dem til slutt til et enkelt utgangspunkt.
12. Ved bruk av berøringsskjerm skal kontrollområdet og statusområdet som deles av berøringsskjermen og PLS ikke brukes til annen funksjonell programmering.
13. Før du bruker noen spesiell PLS-modul, kontroller om kontrollområdet og statusområdet opptar arbeidsord. Hvis ja, ikke programmer disse arbeidsordene til andre formål.
14. PLS-innganger, -utganger, mellomreleer, tidtakere, tellere og dataregistre må merkes med kinesiske tegn. Inn- og utganger må også inneholde komponentnavn og tagnummer. De korresponderende inngangspunktene er generelt satt til NO-kontakter koblet til eksterne brytere. For innganger som krever NC-kontakter, må dette spesifiseres i kommentarfeltet. Alle kommentarer bør være klare og entydige, unngå misforståelser og minimere bruken av generiske termer.
15. Etter at prosjektfeilsøkingen er fullført, må det endelige programvareprogrammet beholdes. Det lagrede filnavnet skal inneholde prosjektnummer, forfatter, dato og versjonsnummer.
16. Angående programkryptering: Passordet til det krypterte programmet må lagres i en dedikert fil, som tydelig angir brukernavn, passord og tillatelser. Denne filen bør distribueres til minst to personer for å lære passordet og forhindre at programmet blir utilgjengelig på grunn av passordtap.
Programmeringsforslag
1. Når en PLS og en vertsdatamaskin (eller berøringsskjerm) danner et overvåkingssystem, må skjermen ofte vise kontrollmoduser som "manuell" og "automatisk" (vanligvis kan flere moduser bare ha en). "MOV"-instruksjonen kan brukes i programmet. For eksempel, når "manuell" er valgt, flyttes konstanten 1 inn i register VB10; når "automatisk" er valgt, flyttes 2 inn i samme register VB10. Ved å kontrollere dataene i registeret kan kontrollmodusen til systemet bestemmes. Fordelen med denne tilnærmingen er dens enkle forståelse og unngår behovet for komplekse prosedyrer som forrigling.
2. Når programmet involverer analog signalkontroll, hvis det leste analoge signalet praktisk talt ikke har noen feil, kan tidsfiltrering brukes til å forsinke inngangen. Hvis de leste dataene har en stor feil, er andre filtreringsmetoder nødvendig, for eksempel gjennomsnittsberegning. Se relevant dokumentasjon for ytterligere informasjon.
3. Under programfeilsøking, hvis en betingelse er oppfylt, men utgangsspolen ikke er aktivert, sjekk om denne delen av programmet er innenfor slike setninger, for eksempel "JUMP go to". En annen mulighet er at betingelsen er oppfylt etter et programavbrudd, men det er ingen utgang; dette indikerer vanligvis at denne delen av programmet ikke blir skannet.
4. I sekvensielle kontrollprogrammer, dvs. når en handling er fullført og den neste handlingen initieres, er +10+10 kontrollmodus veldig praktisk. Ideen er som følger: Et register er forhåndsinnstilt til 0 under initialisering. Etter systemoppstart økes den med 10, noe som bringer registerverdien til 10. Med registeret på 10 kan den første handlingen utføres. Etter den første handlingen økes registeret med 10 igjen, noe som bringer registerverdien til 20, slik at den andre handlingen kan utføres. Etter den andre handlingen økes den med 10 igjen, noe som bringer registerverdien til 30. På denne måten, ved å kontrollere verdien i registeret, kan den ønskede handlingen bestemmes. Når en hopphandling er nødvendig, kan inkrementet endres fra 10 til 20, 30 osv., avhengig av de spesifikke kravene.
Hvorfor øke med 10 i stedet for 1? Fordi etter å ha økt med 10, hvis et segment må settes inn, kan det settes inn i hvilken som helst av de 10 tilgjengelige sporene.
5. Når du designer et program, hvis det oppstår en prosess-relatert feil (ikke kontrollert av kontrollsystemet), er det best å opprettholde feilfenomenet og gi visuelle og hørbare alarmer til operatøren tilbakestiller systemet, slik at de er klar over feilen. Ellers, hvis systemet stopper, kan andre anta at det er et problem med programmet. Disse punktene bør generelt vurderes ved utforming av et nytt system.
6. Ofte kalte subrutiner kan gjøres til undermoduler for hyppige samtaler.
7. Siden hvert trinn i arbeidssyklusen til en produksjonsmaskin krever en viss tid å utføre, og disse tidene har visse grenser, kan en timer startes samtidig med starten av trinnet som skal overvåkes. Tidsinnstillingen skal være 20–30 % lengre enn den normale varigheten av handlingen. Timerens utgangssignal kan brukes til alarmer eller automatiske avstengningsenheter. Når tiden for et trinn overskrider den angitte tiden, når den tilsvarende tidtakerens forhåndsinnstilte tid, og før neste trinn begynner, gir timeren et feilsignal. Dette signalet stopper den normale arbeidssyklusen og starter alarm- eller avstengningsprosedyren; dette er det vi vanligvis kaller over-syklusbeskyttelse.
8. Noen sikkerhetsdeteksjonsbrytere (som nødstoppknapper, sikkerhetslysgardiner, grensebrytere osv.) bør bruke normalt lukkede (NC) innganger.
9. Av hensyn til sikkerhet og energisparing, bør utganger utformes for å aktiveres bare når det er nødvendig og stoppe når handlingen er fullført, i stedet for å være utformet for å sende ut kontinuerlig til et stopp er nødvendig.
10. Driftsprinsippet for aktuatorer bør være: bedre å stå stille enn å bevege seg uregelmessig.
11. Enkelt-enhetsutstyrskontroll: Hver enhet må ha en manuell/automatisk byttefunksjon, og en start/stopp-funksjon under manuell drift. Ved bytte fra automatisk til manuell drift må utstyret ikke stoppe; ved overgang fra manuell til automatisk avhenger utstyrets start/stopp av det automatiske programmet.
12. Hver enhet av utstyr (pumpe, vifte og annet stort utstyr) må roteres etter 24 timers drift, og det må være en kumulativ driftstidsrekord, med mindre start/stopp-sekvensen er satt av vertsdatamaskinen; ellers må operatøren stille inn det manuelt.
