Self-Taught PLC Programmer: 14 Things I Wish I Knew When I Started

The honest version

Reddit r/PLC has a top-pinned post titled "READ FIRST: How to learn PLC's and get into the Industrial Automation World" with 1,055 upvotes and 253 comments. It's the canonical learning guide. PLCS.net's forum has dozens of "where do I start?" threads with detailed answers from senior engineers.

This post compiles the lessons that come up over and over — the things working controls engineers tell newcomers when they're being honest, not when they're polishing a marketing message.

Lesson 1: The scan cycle is the most important concept you'll learn

If you only internalise one thing from your first three months, make it the PLC scan cycle. Every weird bug you'll write in your first year will trace back to misunderstanding when inputs update, when outputs update, and what happens between.

The four phases — read inputs → execute program → write outputs → housekeeping — repeat every 1-100 ms. Inputs only change at scan start. Outputs only change at scan end. A rung that reads an output you just wrote sees the previous scan's value. This is the model your brain has to fight against if you came from regular programming, where everything happens "now."

Lesson 2: Start with ladder logic, but learn structured text fast

Ladder logic is the lingua franca. Every plant electrician reads it; every PLC supports it; it mirrors relay schematics, which is intuitive once you've worked with electrical systems. Start here.

But ladder is awful for math, loops, and string handling. The moment you're trying to express "iterate over an array of recipes and pick the one matching the barcode," ladder produces unreadable rungs. Structured Text is what you switch to. Every working senior controls engineer is fluent in both.

Don't try to do everything in ladder because that's how you started. Don't switch to ST too early either — beginners writing pure ST often produce code maintenance electricians can't trace at 2 AM.

Lesson 3: The IDE is half the battle

PLC programming is dominated by vendor-specific IDEs that each have their quirks. Studio 5000 (Allen-Bradley), TIA Portal (Siemens), GX Works3 (Mitsubishi), Sysmac Studio (Omron), CODESYS, Beckhoff TwinCAT.

Pick one based on what you'll use at work or what's most prevalent in your region. North America: learn Allen-Bradley first. Europe/Asia: Siemens. Don't try to learn all of them at once. The concepts transfer; the IDEs do not.

Free options to learn at home: CODESYS Development System, OpenPLC Editor, the free 90-day Studio 5000 trial. Free PLC Software list covers all the options.

Lesson 4: Get hardware in front of you as fast as possible

The fastest path to "I get it" is wiring an actual PLC to actual sensors and actuators. Watch a digital input go on when you press a switch. Make a contactor close. Drive an LED indicator from an output coil.

Cheapest path:

• $50 Click PLC + free CCW software (AutomationDirect)
• $30 Arduino Mega 2560 + OpenPLC (real industrial logic on hobby hardware)
• $80 Siemens LOGO! 8 + free LOGO!Soft Comfort

Or a $200 used SLC-500 or MicroLogix 1100 from eBay if you want Allen-Bradley experience. Spend a few weekends actually wiring inputs and outputs. Don't try to learn entirely from videos.

Lesson 5: Understand 4-20 mA before you do anything analog

Half of industrial process control rides on 4-20 mA signals. Understand:

• Why 4 mA is "live zero" — it lets you detect a broken wire (raw value would be 0)
• Why 20 mA full-scale matches NEC limits for control circuits
• How to scale raw mA to engineering units in code: EU = (mA - 4) / 16 * (Max - Min) + Min
• HART smart transmitters that ride digital data on top of the analog signal

A surprising amount of "weird analog reading" troubleshooting comes down to scaling, grounding, or wire breaks that a 4-20 mA mental model would catch in seconds.

Lesson 6: Tag names are documentation

Motor1 is a useless tag name. Conv1_RunCmd says it's an output command for conveyor 1. E_Stop_OK says it's TRUE when the system is healthy. Bad tag names are the single biggest contributor to unmaintainable PLC code.

Adopt a naming convention before you write a tag. Equipment prefix + function + suffix. See the PLC code organization guide for examples.

Lesson 7: Wiring is a controls engineer's responsibility too

You can't be a good PLC programmer if you don't understand the wiring underneath. Learn:

• 24 VDC sourcing/sinking (PNP/NPN) sensor wiring
• Relay coil control vs solid-state contact ratings
• Cable shield grounding (one end only, never both)
• The difference between safety ground, signal ground, and AC neutral
• Termination, biasing, and the rules of RS-485

Plants reject programmers who can't troubleshoot at the wiring level. Your code is only as good as the wiring it controls.

Lesson 8: Learn one major communication protocol deeply

EtherNet/IP, PROFINET, Modbus TCP, OPC UA — pick one (matched to your vendor ecosystem) and understand it deeply. The rest you can learn by analogy.

For Allen-Bradley: EtherNet/IP. For Siemens: PROFINET. For multi-vendor: Modbus TCP and OPC UA. See the communication protocols pillar for the broader landscape.

Lesson 9: The community is the most underused resource

PLCS.net forum (plctalk.net), r/PLC on Reddit, MrPLC forums, vendor-specific communities (community.rockwellautomation.com, support.industry.siemens.com), and now Discord servers for OpenPLC and Beckhoff. When you're stuck, post a question. The senior engineers in these communities answer detailed questions in detail. You'll learn faster than any book.

The flip side: lurk first, contribute later. The forums have low tolerance for "do my homework" questions or refusing to read a manual. Show what you've tried.

Lesson 10: Version control matters even when nobody else does it

Most plants don't use Git for PLC code. The PLC contains the only copy. Backups are old. Multiple engineers edit live without communication.

Be the engineer who does it right. Export your project to text (Studio 5000 L5X, TIA Portal SCL, CODESYS export) and commit to Git after every change. When a customer asks "what changed last Tuesday?" you'll be the only one with the answer.

Lesson 11: Comment your code like you're writing for the night-shift electrician

Because eventually, you are. Three levels of comments:

1. Routine header — what this routine controls, who modified it last, why
2. Rung comment — why this interlock exists, including reference to HAZOP item or FDS section
3. Tag description — what the tag means in plant terms

Five years from now, the maintenance tech tracing this rung at 2 AM will silently bless you (or curse you).

Lesson 12: Learn the IEC 61131-3 instruction set, not vendor-specific only

Every vendor has their own quirks, but underneath, IEC 61131-3 defines the standard set of timers (TON, TOF, TP, RTC), counters (CTU, CTD, CTUD), edge detection (R_TRIG, F_TRIG), and bistables (SR, RS). Learn these names. They translate across platforms with minor syntax differences.

Vendor-specific instructions are valuable to know but harder to transfer. AOIs (Allen-Bradley) and FBs (Siemens, IEC) for reusable logic are universal concepts.

Lesson 13: Soft skills separate senior engineers from junior ones

Technical chops get you in the door. Soft skills determine your career trajectory:

• Listening to operators and electricians. They know things you don't. Be quick to ask, slow to "fix."
• Documentation discipline. Your code, your wiring diagrams, your I/O lists. Future-you will thank present-you.
• Saying no when scope creeps. "Yes" to everything in commissioning is how projects die.
• Politely calling out unsafe designs. If something is going to hurt someone, escalate. Don't just code around it.
• Owning mistakes when you make them. The instinct to hide them is wrong. Senior engineers debug each other's bugs without judgement when there's no hiding involved.

Lesson 14: Pick a niche, but stay broad enough to switch

Specialising in one industry (food & beverage, automotive, water utilities, pharma, oil & gas) accelerates your career. Each has its own conventions, regulations, dominant vendors, and pace. Pick one and become the person plants call.

But don't specialise so deeply you can't switch. Junior PLC engineers who only know one vendor or one industry are vulnerable when the local market shifts. Stay current on at least two vendors, two protocols, and one adjacent skill (vision, motion, IIoT, cybersecurity).

What I'd do if I started over today

If I were starting from zero in 2026:

1. Weeks 1-4: Free browser-based PLC simulator (PLCFiddle, OpenPLC simulator). Learn ladder logic basics. Build motor seal-in, traffic light, water tank examples. See PLC Programming Examples.
2. Weeks 5-8: Buy a $50 Click PLC or set up OpenPLC on a Raspberry Pi. Wire actual sensors and actuators.
3. Weeks 9-16: Pick Allen-Bradley or Siemens (based on local job market). Use the 90-day Studio 5000 trial or 21-day TIA Portal trial. Build progressively complex projects.
4. Months 5-6: Add structured text. Learn one communication protocol deeply (EtherNet/IP for AB, PROFINET for Siemens).
5. Months 7-12: Find a junior controls or automation engineer role. Real-plant exposure accelerates everything.
6. Year 2+: Specialise in an industry. Get certified (Rockwell or Siemens). Build a portfolio of well-documented projects.

The industry has a serious skills shortage. Engineers who can demonstrate working PLC code, real wiring competence, and good documentation habits are in extreme demand. The career path is open; the gate is the early effort to get past the first 6 months of "this is confusing."

Related guides

• PLC Programming Roadmap — the longer-form learning path
• PLC Programming Beginner's Guide — the foundation pillar
• Common PLC Programming Mistakes — what to avoid
• Free PLC Software — tools you can practise with
• PLC vs Arduino — when each is the right choice