Idag delar jag med mig av en praktisk artikel för att hjälpa dig förstå hur ett perfekt PLC-program ser ut, och ger PLC-programmeringsstandarder och förslag för praktiskt arbete.
Designkrav för ett perfekt PLC-program:
Ett komplett PLC-program handlar inte bara om att få systemet att köra; det kräver också fullständiga kommentarer, en väl-strukturerad arkitektur, bra skalbarhet, ett omfattande larm- och skyddssystem och ett förkört simuleringssystem.
1. Enkelhet
Gör PLC-programmet så enkelt som möjligt. Enkelhet innebär att använda ett standardiserat programramverk och enkla instruktioner. I stort sett handlar det om att optimera programstrukturen och förenkla programmet med instruktioner för flödesstyrning. Mer specifikt innebär det att ersätta instruktioner för enkla-funktioner med mer kraftfulla och att vara uppmärksam på instruktionernas ordning.
2. Läsbarhet
Det designade programmet bör vara mycket läsbart. Detta hjälper inte bara programmeraren att bättre förstå programmet och underlättar felsökning, utan gör det också lätt för andra att förstå och för användare att underhålla. Det bör också underlätta programspridningen när det behövs.
För att säkerställa god läsbarhet bör programutformningen vara så tydlig som möjligt. Var uppmärksam på hierarki och modularitet, även genom att använda objekt-orienterade designmetoder. Använd standarddesignpraxis så mycket som möjligt.
Om programmeringsspråk används i speciella fall bör stegdiagram användas i de flesta fall för lättare läsbarhet. I/O-allokering bör vara systematisk för enklare memorering och förståelse. Lägg till kommentarer vid behov. Användningen av interna komponenter bör också vara systematisk; undvika att använda dem på måfå.
Läsbarhet bör beaktas från början av programdesign. Detta är inte lätt att uppnå helt, för under programfelsökning kan tillägg eller borttagning av instruktioner och ändringar i användningen av interna komponenter göra ett ursprungligen tydligt program något rörigt. Tillåt därför justeringar under felsökning i designfasen, och gör sedan ordning efter felsökning. Detta kommer att resultera i ett program av högre kvalitet.
Programkommentarer bör åtminstone innehålla följande:
A. Systemkommentarer: Upphovsrättsinnehavaren och syftet med hela programmet; B. Blockkommentarer: Huvudsyftet och författaren till blocket; C. Segmentkommentarer: Syftet med kodsegmentet; D. Variabelkommentarer: Viktigheten är självklar-, inklusive I/O-kommentarer och intermediära variabelkommentarer. När det gäller konfidentialitet, bör dessa åtgärdas genom krypteringsalgoritmen eller blockkryptering av programmet, snarare än genom att minska kommentarer.
3. Rätthet
PLC-programmet måste vara korrekt och verifierat genom faktisk drift för att bevisa dess korrekta funktion. Detta är det mest grundläggande kravet för ett PLC-program; om detta inte uppnås, oavsett hur bra de andra aspekterna är, är de värdelösa.
För att säkerställa att programmet är korrekt måste instruktioner och interna enheter användas korrekt. Korrekt användning av instruktioner är kopplad till korrekt förståelse av dem; därför måste innebörden och användningsvillkoren för instruktionerna förstås ordentligt. Vid behov kan små program skrivas för att testa några oklara instruktioner.
För samma instruktion, på grund av skillnader i PLC-tillverkningssatser eller seriemodeller, kan vissa instruktionsdetaljer variera. Programmeringsmanualen bör noggrant konsulteras.
Korrekt användning av interna enheter är också viktigt. Till exempel har vissa PLC:er avstängningsskydd-, medan andra inte har det. Det är viktigt att se till att enheter som kräver-avstängningsskydd används och vice versa.
Kort sagt, det mest grundläggande kravet för PLC-program är att korrekt använda instruktioner och korrekt använda interna komponenter för att säkerställa att det programmerade programmet körs korrekt.
Som ett enkelt exempel kräver Siemens PLC:er variabler med lagringsfunktionalitet som mellanvariabler för stigande och fallande kanter, såsom M-punkter eller DB-punkter. Att använda FC:s tempvariabel skulle orsaka problem.
4. Tillförlitlighet
Program måste inte bara vara korrekta utan också tillförlitliga. Tillförlitlighet speglar stabiliteten i PLC-programmet, vilket också är ett grundläggande krav.
Vissa PLC-program fungerar korrekt under normala driftsförhållanden eller under laglig drift, men fungerar inte ordentligt under onormala driftsförhållanden (som ett tillfälligt strömavbrott följt av snabb strömåterställning) eller efter olagliga operationer (som att trycka på knappar ur sekvens eller trycka på flera knappar samtidigt). Sådana program är opålitliga, instabila eller dåligt utformade.
Bra PLC-program kan identifiera onormala driftsförhållanden och sömlöst integrera dem med normala förhållanden, vilket gör att programmet kan anpassa sig till olika situationer. Ett bra PLC-program kan avvisa illegala operationer utan att lämna några "spår", accepterar endast lagliga operationer.
Interlocking är en vanlig metod för att avvisa illegala operationer; reläkretsar använder ofta denna metod, och PLC:er kan också ärva detta tillvägagångssätt.
5. Enkel modifiering
Ett program ska vara lätt att modifiera. En av egenskaperna hos en PLC är dess bekvämlighet och flexibilitet för att anpassa sig till olika situationer. Detta uppnås genom att modifiera eller göra om programmet.
Omdesign av programmet används när applikationskraven för PLC:s process behöver ändras. Programmet skrivs inte bara om, utan I/O måste också omfördelas. I de flesta fall är det inte nödvändigt att skriva om programmet; mindre ändringar är tillräckliga. Detta kräver att programmet är lätt att modifiera.
Enkel modifiering innebär också flexibilitet, som endast kräver mindre ändringar för att uppnå syftet med att ändra parametrar eller modifiera åtgärder.
6. Expanderbarhet
Många program kan vara för-förprogrammerade innan de distribueras på webbplatsen, men ytterligare program kan behöva läggas till på-webbplatsen. För att undvika att störa den övergripande systemstrukturen måste tillräckligt med utrymme reserveras i varje funktionsområde för backuphårdvara. Programvaran bör utformas med manuell, automatisk och halv-automatisk drift i åtanke, och utrymme bör tilldelas därefter.
7. Omfattande larmsystem
PLC-system används ofta i industriella miljöer, där varje olycka kan orsaka förluster, stora som små. För att säkerställa förebyggande av olyckor eller minimera förluster vid en olycka måste PLC:ns larm- och skyddsfunktioner betonas. Därför lyfts detta fram som en viktig komponent i systemet.
8. Programsimulering
För att säkerställa-felsökningsframsteg på webbplatsen eller för kunddemonstrationer krävs ofta en helautomatisk simulering av programmet före implementering. Detta kräver att en simuleringsprogramsektion läggs till i det befintliga programmet, som kopplas bort efter normal-operation på plats. För att programmet ska kunna utföra simulering krävs följande steg:
(1) Konvertera de faktiska PLC I/O-punkterna till mellanvariabler eller datablockvariabler;
(2) Skriv simuleringsprogram för varje utrustning enligt processkrav.
Ett bra PLC-program kan anses vara ett som uppfyller ovanstående krav.
PLC-programmeringsspecifikationer
1. Välj lämplig PLC-modell och antal I/O-punkter. Välj speciella funktionsmoduler för specifika funktionskrav.
2. Var bekant med de valda PLC-programmeringsinstruktionerna och kompileringsmjukvaran.
3. Planera de mjuka komponenterna, inklusive interna reläer, hållreläer, dataregister, timers och räknare.
4. Planera programmet, i allmänhet genom att följa sekvensen av felutvinning, felhantering, manuell hantering, automatisk hantering och utgångshantering. Större projekt eller utrustning bör delas in i funktionella enheter, såsom hissar, överföringsanordningar och lyft-/rotationsanordningar i en automatiserad produktionslinje. Dessa bör programmeras i segment och block enligt ovanstående enhetsstruktur.
5. Lägg till korta segmentkommentarer före varje segmenterat eller block-baserat program och förklara dess funktion. Ange vid behov motsvarande processflöde. Ordningen för segmenterade eller block-baserade program inom det övergripande programmet bör i allmänhet följa processflödessekvensen för läsbarhet.
6. Innan programmet utformas bör utrustningen abstraheras. Vanliga faktorer som stopp, nödstopp, överbelastning, över-gräns, timeout, säkerhetsljusridå, kollisionsstopp och dörrbrytare bör dras ut och placeras i start-uppkopplingskretsen eller start-huvudkontroll- och förreglingskretsen. Detta fungerar som den övergripande utgångspunkten för hela programstrukturen. Utifrån detta delas sedan programmet in i två huvudsakliga funktionsområden: automatiskt och manuellt.
7. Vanliga faktorer i det manuella funktionsområdet för programstrukturen, såsom manuell drift och faktorer som äventyrar utrustning och personlig säkerhet, bör extraheras och placeras i den manuella huvudkontroll- och förreglingskretsen för att skydda, avskärma och larma för manuell styrning.
8. Vanliga faktorer i det automatiska funktionsområdet för programstrukturen, såsom automatisk drift, över-gräns och timeout-faktorer, bör extraheras och placeras i den automatiska huvudkontroll- och spärrkretsen för att skydda, skärma och larma för utrustning under automatisk kontroll. En allmän princip är att strikt begränsa utrustningens inträde samtidigt som utrustningens utträde löst begränsas, vilket säkerställer säkerheten.
9. En huvudåterställningsfunktion bör utformas i programmet för att underlätta snabb och enkel återställning av normal utrustningsfunktion vid fel. Huvudåterställningen bör fullt ut beakta säkerheten för utrustning och personal under återställningsprocessen.
10. När du växlar från automatiskt läge till manuellt läge, bör programmet rensa utgångarna och mellantillstånden från automatiskt läge. Speciellt när SET-instruktionen används i automatiskt läge, måste den raderas med RESET-instruktionen i manuellt läge.
11. Dubbla utgångar är strängt förbjudna vid programmering; det vill säga samma utgångssats eller samma utgångsspole dyker upp två eller flera gånger i programmet. För samma utgångspunkt under olika lägesförhållanden, använd ett mellanrelä för överföring och kombinera dem slutligen till en enda utgångspunkt.
12. Vid användning av en pekskärm får kontrollområdet och statusområdet som delas av pekskärmen och PLC inte användas för annan funktionell programmering.
13. Innan du använder någon speciell PLC-modul, kontrollera om dess kontrollområde och statusområde upptar arbetsord. Om så är fallet, programmera inte dessa arbetsord för andra ändamål.
14. PLC-ingångar, utgångar, mellanreläer, timers, räknare och dataregister måste annoteras med kinesiska tecken. In- och utgångar måste också innehålla komponentnamn och etikettnummer. Motsvarande ingångspunkter är i allmänhet inställda på NO-kontakter anslutna till externa omkopplare. För ingångar som kräver NC-kontakter måste detta anges i kommentarerna. Alla kommentarer bör vara tydliga och entydiga, undvika missförstånd och minimera användningen av generiska termer.
15. Efter att projektfelsökningen har slutförts måste det slutliga mjukvaruprogrammet behållas. Det sparade filnamnet ska innehålla projektnummer, författare, datum och versionsnummer.
16. Angående programkryptering: Lösenordet för det krypterade programmet måste lagras i en dedikerad fil, som tydligt anger användarnamn, lösenord och behörigheter. Den här filen bör distribueras till minst två personer för att lära sig lösenordet och förhindra att programmet blir otillgängligt på grund av lösenordsförlust.
Programmeringsförslag
1. När en PLC och en värddator (eller pekskärm) bildar ett övervakningssystem behöver skärmen ofta visa kontrolllägen som "manuell" och "automatisk" (i allmänhet kan flera lägen bara ha ett). "MOV"-instruktionen kan användas i programmet. Till exempel, när "manuell" väljs, flyttas konstanten 1 till register VB10; när "automatisk" väljs flyttas 2 till samma register VB10. Genom att kontrollera uppgifterna i registret kan systemets styrsätt bestämmas. Fördelen med detta tillvägagångssätt är att det är lätt att förstå och undviker behovet av komplexa procedurer som förregling.
2. När programmet involverar analog signalkontroll, om den lästa analoga signalen praktiskt taget inte har något fel, kan tidsfiltrering användas för att fördröja ingången. Om den lästa datan har ett stort fel behövs andra filtreringsmetoder, såsom medelvärdesberäkning. Se relevant dokumentation för ytterligare information.
3. Under programfelsökning, om ett villkor är uppfyllt men utgångsspolen inte är aktiverad, kontrollera om denna sektion av ditt program finns inom sådana satser, som "JUMP go to". En annan möjlighet är att efter ett programavbrott är villkoret uppfyllt men det finns ingen utmatning; detta indikerar vanligtvis att den här delen av programmet inte skannas.
4. I sekventiella kontrollprogram, dvs när en åtgärd är klar och nästa åtgärd initieras, är kontrollläget +10+10 mycket bekvämt. Tanken är följande: Ett register är förinställt till 0 under initialisering. Efter systemstart ökas det med 10, vilket bringar registervärdet till 10. Med registret på 10 kan den första åtgärden utföras. Efter den första åtgärden inkrementeras registret med 10 igen, vilket bringar registervärdet till 20, vilket gör att den andra åtgärden kan utföras. Efter den andra åtgärden inkrementeras den med 10 igen, vilket bringar registervärdet till 30. På så sätt kan den önskade åtgärden bestämmas genom att kontrollera värdet i registret. När en hoppåtgärd behövs kan inkrementet ändras från 10 till 20, 30, etc., beroende på de specifika kraven.
Varför öka med 10 istället för 1? För efter att ha ökat med 10, om ett segment behöver infogas, kan det infogas i någon av de 10 tillgängliga luckorna.
5. När ett program utformas, om ett processrelaterat-fel (som inte kontrolleras av styrsystemet) inträffar, är det bäst att upprätthålla felfenomenet och ge visuella och hörbara larm tills operatören återställer systemet, så att de är medvetna om felet. Annars, om systemet stannar, kan andra anta att det finns ett problem med programmet. Dessa punkter bör generellt beaktas vid utformning av ett nytt system.
6. Ofta anropade subrutiner kan göras till submoduler för frekventa samtal.
7. Eftersom varje steg i en produktionsmaskins arbetscykel kräver en viss tid att utföra, och dessa tider har vissa gränser, kan en timer startas samtidigt med starten av det steg som ska övervakas. Timerns tidsinställning bör vara 20 %–30 % längre än åtgärdens normala varaktighet. Timerns utsignal kan användas för larm eller automatiska avstängningsanordningar. När tiden för ett steg överskrider den angivna tiden, når motsvarande timerförinställd tid, och innan nästa steg börjar, avger timern en felsignal. Denna signal stoppar den normala arbetscykeln och initierar larm- eller avstängningsproceduren; detta är vad vi vanligtvis kallar över-cykelskydd.
8. Vissa säkerhetsdetekteringsbrytare (såsom nödstoppsknappar, säkerhetsljusridåer, gränslägesbrytare, etc.) bör använda normalt stängda (NC) ingångar.
9. Av säkerhets- och energibesparingsskäl bör utgångar utformas så att de endast aktiveras när det behövs och stoppas när åtgärden är slutförd, snarare än att de är utformade för att matas ut kontinuerligt tills ett stopp krävs.
10. Funktionsprincipen för ställdon bör vara: bättre att stå still än att röra sig oregelbundet.
11. Styrning av en-enhetsutrustning: Varje enhet måste ha en manuell/automatisk växlingsfunktion och en start/stoppfunktion under manuell drift. Vid byte från automatisk till manuell drift får utrustningen inte stanna; vid byte från manuellt till automatiskt beror utrustningens start/stopp på det automatiska programmet.
12. Varje enhet av utrustning (pump, fläkt och annan stor utrustning) måste roteras efter 24 timmars drift, och det måste finnas ett kumulativt drifttidsrekord, såvida inte start/stoppsekvensen ställs in av värddatorn; annars måste operatören ställa in den manuellt.
