Den högre kostnaden för PLC: er uppvägs av testningen (ofta i otäcka miljöer) som de skickas till (eller bör). Kan du designa ett anpassat mikrokontrollersystem? Ja, men då måste du antagligen certifiera det.

Anpassningsbarhet är egentligen inte ett stort problem när du har en stor anläggning full av utrustning; faktiskt vill du ha motsatsen, du vill att saker ska vara så standardiserade som möjligt.

Dessutom är stege-logik redan ganska mycket standardiserad - förutom leverantörsspecifika funktioner - som gör felsöknings- / portningsprogramvara mellan PLC: er till en enklare uppgift än vad den portar mellan olika mikrokontroller.

Jag tror att en viktig faktor är människor. Ingenjörerna som kan utforma en mikrokontroller för att driva en fabrik är upptagna med att göra satser av små enheter. Ingenjörer som arbetar med varumärkes-PLC: er använder standardprogramvarupaket, de behöver inte hantera programmering på lägre nivå, de flesta problem som de stöter på någon annan har redan löst med den hårdvaran (kommandon till konstiga enheter, IO-problem, PID). Ingenjörerna är utbytbara, med en bra specifikation eller kodkommentering behöver du inte ingenjören som byggde ett system där när du behöver ändra koden.

Det är också lite som att fråga varför skulle någon köpa en dator när de kunde bygga sin egen.

Miljöfrågan (fysisk, elektrisk isolering, EMI, etc.) är enorm och har redan täckts av andra svar.

Du måste också överväga hur PLC: er ger dig en mycket deterministisk miljö . De är väl förstådda och har funnits sedan 1970-talet.

Du vet hur lång tid varje steg kommer att ta och du garanteras beteendet baserat på kända ingångsparametrar. Med ren mikrokontrollerprogrammering kan det bli komplicerat att ta reda på exakt hur en förändring i en funktion kommer att påverka hela programmets funktion.

Ladderlogik är lätt att förstå och programmera för maskinstyrning. Vi har elektriker som programmerar dem utan att ingenjörerna är involverade. De kan enkelt felsöka ledningens elektriska system själva och göra lämpliga reparationer. De kan också skriva sina egna program och göra ändringar i befintliga. Felsökningsmiljön är mycket bättre (och jag menar WAY) än vad du normalt kan åstadkomma med inbäddade mikroer.

Med säkerhetssystem blir det ännu viktigare att använda säkerhets-PLC: er och deras överflödiga funktioner och vakthundar för att säkerställa korrekt funktionalitet.

Du vet att du har några PLC: er i sub $ 100 / ea-intervallet: CLICK® Series Programmable Logic Controllers (PLCs) (Stackable Micro Brick) och mycket i sub $ 500 intervall med begränsad IO.

Det finns vissa moduler som i grunden är industrialiserade "mikrokontroller" -paket. Till exempel kan de flesta PID-temperaturregulatorer ses som sådana.

Med detta sagt kan du börja se platser i branschen där datorer med realtidsoperativsystem tar hand om kontrolluppgifter och maskinstyrning direkt. Detta kommer att fortsätta att växa speciellt med nätverksansluten IO.

Inte alla som arbetar med PLC: er är elektroniksexperter.

Jag började göra PLC som en ren processkille. Jag kunde inte använda en multimeter, förstod inte riktigt skillnaden mellan spänning och ström. Jag hade gjort lite C i en college-klass, men det var det.

Språk på hög nivå är enorma. Jag kunde lära mig i princip hela introduktionen av en PLC under ett par veckors träning, och det räckte för grundläggande PLC-programmering. Jag behövde aldrig oroa mig för bibliotek, I / O-hantering, minnestilldelning, något av dessa saker.

Och som nämnts tidigare säkerhetsapplikationer. Jag skulle inte lita på någons hembrytade mikrokontroller som de gör anspråk på för SIL-3.

Tänk på slutanvändare: En PLC är mer vänlig för en person med en lätt EE-bakgrund. Lättare att använda, lättare att underhålla plus en PLC ger viss automatisk fabrikskontroll på högsta nivå. Tänk på en enorm anläggning som behöver 10 000 olika funktioner, du kan inte bygga dem alla, tid / kostnad är enorm jämfört med att använda COTS (billigt från hyllan).

Om du är en riktig EE, gör det inte ta ett sådant jobb, det är ett tråkigt, lågteknologiskt jobb. Ett riktigt EE-jobb är att använda en MCU för att skapa en PLC-låda för andra killar att leka med.

En annan faktor som ännu inte nämnts är att vissa PLC-leverantörer har investerat betydande ansträngningar för att visa att deras system kan lita på att de fungerar som specificerat, även i närvaro av olika typer av motgångar (i närvaro av motgångar som skulle göra det normalt omöjlig drift, kan enheten lita på utlösaren en felsignal eller orsaka att andra utgångar går i ett felsäkert tillstånd). Även om det skulle vara möjligt att programmera många typer av mikrokontroller för att tillhandahålla sådan robusthet även i närvaro av glitchar som kan vända en eller flera registerbitar under drift (t.ex. genom att utföra överflödiga beräkningar med användning av olika formler, så att en extrem sammanfallning skulle krävas för att glitch båda beräkningarna på ett sådant sätt att de ger konsekventa resultat) den ansträngning som krävs för att skriva och validera sådan programvara skulle vara enorm i förhållande till komplexiteten i vad programvaran faktiskt gjorde. Det är mycket lättare att använda en PLC som har sådana säkerhetsfunktioner utformade.

Enligt min erfarenhet har jag sett både mikrokontroller och PLC används i industriella miljöer.

Den avgörande faktorn är "Vem ska stödja / underhålla / modifiera utrustningen efter att den har tagits i drift?"

I industriella miljöer lägger man mer tid på att läsa (se felsökning) kod än vad man lägger på att skriva den. Detta betyder inte att du försöker hitta problem i koden, utan använder koden för att diagnostisera problem i fältet. Ofta är de personer som krävs för att göra sådan felsökning elektriker, som är bekvämare att läsa elektriska scheman än kod i textformat (alltså populariteten för den grafiska typen "programmeringsspråk" som stege-logik). På större webbplatser, med dedikerade automationsingenjörer, blir detta mindre av en faktor.

Nära relaterade till ovanstående är historiska tröghetsfrågor för en viss lösning. Den tekniska bakgrunden för personal och tidigare erfarenhet av hårdvara / leverantörer leder till förutsättningar för projekt som vanligtvis är organiserade kring linjer som ("vi använder redan leverantör X och har reservdelar till hands - allt som implementeras i framtiden behöver använda X-YZ ").

Också relaterat till och blivit mer av ett problem under de senaste åren är" Hur kommer denna utrustning att kommunicera med resten av min utrustning / fabrik / webbplats / företag ". Detta löses vanligtvis för PLC: er och mer av ett problem för mikrovolymkontrolllösningar med låg volym.

Jag har sett mikrokontroller implementerade där en mycket anpassad lösning var motiverad (men sedan vanligtvis bara implementerad som ett leverantörsprojekt och stöds av leverantören). Orsaker är normalt relaterade till körhastighet eller behovet av att ha hårdvaran och koden mycket nära varandra (ingen möjlighet till kommunikationsfördröjningar och kravet på att separera den kritiska processen från annan icke-relaterad kod)

Mikrokontrollern är en enhet, PLC är en utrustning. Använd mikrokontroller "i ändarna" om du är en oklanderlig hobbyist eller om du tillverkar en massprodukt. För skräddarsydda industriella lösningar är PLC det enda valet.

De kan båda uppnå samma mål. Medan ett mikrocontrollerdrivet system kan vara billigare är programmering i C-kod ett stort åtagande. Att vara skicklig på C-språk är massor av träning involverad.

Med detta sagt finns det ett område där jag arbetar som använder MCU för att kommunicera med ett C ++ - program för att spåra och reglera ström och spänning hos stora likriktarladdningskretsar för industribatterier (200+ AH-batterier). Det finns cirka 100 likriktare. Att hitta den gamla AD-DA med STD-styrenheten och reläkortet är nästan omöjligt. När dessa kort går dåligt är det allt.

Det är därför vi för närvarande håller på att uppgradera allt till allen Bradley-linjen för kompakt eller kontroll logix-linjen för PLC: er. Är de dyra? Ja. Är det dyrt att anställa en programmerare som känner till C ++? Ja. Med hjälp av RS Linx / Logix kan flera personer som alla är redo för företaget skriva / redigera program med den programvaran. Koppla ihop det med mängden stöd och expansion, det kan vara snabbare och mer kostnadseffektivt att använda PLC: er.

En annan faktor som är värt att nämna är produktens livscykel. Vanligtvis för PLC: er finns support i många år. Jag stöder fortfarande några Texas Instruments PLC: er från 1985 och 1987. De var välbyggda och extremt tillförlitliga. Reservdelar är tillgängliga från industriella reparationscenter eller på eBay i detta skede och kräver höga priser.

Försök hitta ersättningschips, brädor och liknande för att köra din (sätt in favoritmikro) om 30 år.

Jag gillar ovanstående svar och tänkte att jag också skulle slå in. PLC vs Micro Controller har också mycket att göra med skala och kostnad. Du kan till exempel mycket snabbt programmera en tvättmaskin med en PLC. Men då skulle din tvättmaskin kosta tre gånger så mycket som den gör för att kompensera priset för PLC. Så du utformar en mikrokontroller med ett enda program som ska replikeras 100 000 gånger. Kostnaden för konstruktion för det är hög, men över 100 000 enheter är mycket låga med en låg kostnad för utrustningen.

Alternativt kan du också programmera ett helt kraftverk i en mikrostyrenhet. Men (tillsammans med många av ovanstående svar) kommer du sannolikt att spendera 20 gånger så mycket tid på programmering och ytterligare 20 gånger så mycket tid på att felsöka det - lägre hårdvarukostnad ja, men ingenjörer är dyra, särskilt bra. Eller så kan du använda en PLC med högre hårdvarukostnad, men tidsprogrammeringen är mycket mindre, vilket resulterar i lägre ingenjörskostnader.

Observera också att jag inte vill vara en person som var tvungen att programmera BACnet, Modbus, CIP och en Ethernet-HMI-drivrutin i en Micro-controller. Plcs kan göra det med några extra kort och ett par timmars konfigurering.

Bland de andra fantastiska svaren, i ett ord: standardisering.

Standardhårdvara, standardkommunikation, standardutvecklings-IDE, standardspråk.

Olika märken erbjuder olika smaker, men när du väl har lärt dig ett PLC-märke är det i allmänhet mer licensbörda än tekniskt.

För standard för programmering och elektriska parametrar är det lämpligt att använda PLC istället för mikrokontroller.

Mikrokontroller används när du har att göra med produkter, särskilt lågeffekt och liten storlek, som de för bilar och medicinsk användning. Du använder inte PLC där inne.

Men när du har att göra med maskiner som märkning, skärning etc. kan man enkelt använda PLC.

Dessutom är PLC standardiserad tillämpning av inbäddade marker .

Programmets språk för plc är väldigt enkelt och användarvänligt, de expansionsportar som används i plc är också mer jämfört med mikrokontroller, och huvudsakligen "i mikrokontroller om någon stift är skadad är det svårare att felsöka" för alla dessa anledningar industrier kommer att använda plc istället för mikrokontrollen. det finns några fler men det här är huvudproblemen i branschen

Jag har byggt och använt PLC: er under åren. Jag föreslår att det finns en marknadskonvergens, med WiFi PLC-liknande mikroer som nu kostar $ 49 och säljer som hotcakes.

PLC-tillverkare känner prispress.

Nyare kostnadseffektiva PLCS som Siemens-logotypen kan passa bättre för enkla applikationer.

Bara att träffa marknaden är PLC: er som använder Arduino istället för stege-logik. Mycket bang för pengarna där. Sök i kickstarter för PLC

-Martin

Enkelt svar är att alltid använda PLC. . . . Men om PLC inte är genomförbart på grund av faktorer som kostnad, storlek eller komplexitet i applikationen, ska vi bara gå till Micro-Controller eftersom PLC är mer robusta, det är avsett för industriell miljö (vilket innebär mycket mekanisk vibration, hög temperatur, damm, elektriska spikar etc), testas för tillförlitlighet, använder standardprogrammeringsmetoder som gör det möjligt för ingenjörer med mindre kompetens att göra ändringar etc.