For most new Siemens PLC projects, the single best decision you can make is to use Structured Text (SCL) and Statement List (STL) as your primary languages, not Ladder Diagram (LAD). I didn't learn that from a textbook—I learned it from six years of mistakes, roughly $3,200 in wasted orders, and a lot of late-night debugging that could have been avoided.
When I started in 2017, I was taught that Ladder was king. It was visual, familiar to electricians, and supposedly easy to debug. That might have been true for simple relay logic replacements, but for the kind of systems we build today—batch control, complex recipes, data logging to SQL databases—LAD is often the worst choice. On a particularly painful $3,200 order in September 2020, I had programmed the entire sequence in LAD. It worked in simulation. But when the system went live, the scan cycle was so long that the pressure control loop oscillated wildly. We had to stop production, rewrite three networks in SCL, and I ate the overtime cost ($890 in redo plus a 3-day production delay).
"The question everyone asks is 'which Siemens PLC should I buy?' The question they should ask is 'which language should I use?'"
Most beginners fixate on hardware specs—CPU speed, memory, number of I/O points. I did the same. But the language choice determines how fast you can write, debug, and reuse code. LAD looks intuitive initially, but what it saves you in screen time, it costs you in development time for anything beyond basic AND/OR logic.
Here's the truth that took me three years and two major reworks to accept: Modern TIA Portal environments and the S7-1500 family make SCL and STL not just viable, but often superior. The old argument that 'LAD is standard' stems from an era when most PLC programmers came from electrical maintenance backgrounds and documentation for STL was poor. That's changed. Today's TIA Portal documentation for SCL is comprehensive, and the code is fundamentally easier to version-control and test.
Consider a simple example: implementing a PID auto-tune sequence. In LAD, you have to juggle multiple network levels with set-reset coils that are difficult to trace when the sequence gets stuck at step four. In SCL, you write a CASE statement with eight lines of code—clear, readable, and easily modified. I've seen engineers (myself included) waste an entire shift debugging a LAD network that had an overlapping timer condition. The same logic cleared in 20 minutes in STL.
But—and this is where I need to be careful—Siemens Master course training (which I recommend to anyone starting) still teaches LAD as the primary language for many modules. That's not wrong: for simple safety interlocks or basic conveyor logic, LAD is fine. The risk is that engineers never outgrow it.
This was true a decade ago when digital options for training were limited and courses were expensive. Today, a motivated engineer can learn SCL basics in a day on Siemens' own SITRAIN portal. I should add that my own conversion happened after a disaster in Q1 2022 where a contractor delivered an entire production line in LAD (ugh, again). The client insisted on SCL for maintenance compatibility—we had to rewrite 70% of the code.
Of course, there are cases where LAD still wins: small standalone machines with simple on/off logic, legacy system maintenance, or when the maintenance team has zero programming background. For those, the 'old' way is still fine. But for anything involving arrays, math functions, data logging, or communication with HMIs—which is most modern systems—SCL and STL are the safer bets.
Saved a bit of time by sticking with LAD for a quick project? Ended up spending $400 on additional engineering time when the customer requested minor logic changes a year later. Net loss on a $1,500 project: significant. The 'budget language' choice looked smart until we had to maintain the code.
So if you're starting a project today—or evaluating which Siemens system to buy—be honest about what you'll actually be programming. If it's just a light control panel for a small conveyor, use LAD. If it's anything more complex, invest the extra day in SCL training. Your future self (and your budget) will thank you.
Lastly, I realize this advice challenges a lot of corporate standards. I've run into Siemens system integrators who mandate LAD for 'consistency.' That's fine—as long as they've actually evaluated the trade-offs. Most standard operating procedures were written when S7-300s were common and TIA Portal didn't exist. The fundamentals of logic haven't changed, but the execution has transformed. What worked as best practice in 2020 may not apply in 2025.