Siemens S7-1200 Programming Guide: Setup to First Project

The Siemens S7-1200 is a compact PLC family programmed with STEP 7 inside TIA Portal. A reliable first project follows seven stages: identify the exact CPU and firmware, configure the matching device, create symbolic tags, separate reusable logic from hardware mapping, simulate what can be simulated, download over a controlled network connection, and commission each output against an approved I/O list.

This guide covers both established S7-1200 installations and the newer S7-1200 G2 family. Do not assume that a project, accessory or procedure transfers unchanged between generations; start with the order number and current Siemens documentation.

Download the S7-1200 project and commissioning checklist (CSV)

S7-1200 project roadmap

1. Identify the exact controller

Record the full article number, hardware generation, firmware revision, supply voltage and onboard I/O variant. “S7-1200” is not a complete hardware specification.

Siemens describes S7-1200 G2 as the second generation of the family, with integrated PROFINET, onboard I/O, high-speed counting and motion capabilities in a narrower footprint. The official S7-1200 G2 system manual also documents compatibility differences from the first generation. Check its associated product-information updates before wiring: Siemens issued an August 2025 terminal-block safety update for specific relay-related connectors and modules.

For an existing machine:

1. Photograph the CPU and module order numbers.
2. Upload or archive the current project before making changes.
3. Record firmware and the TIA Portal version used by the validated project.
4. Confirm replacement compatibility in Siemens Industry Online Support.
5. Treat generation changes as migrations, not drop-in substitutions.

2. Size the CPU and I/O

Count more than digital points. The controller decision should include:

• digital inputs and outputs, including voltage and output technology;
• analog ranges, resolution and isolation needs;
• high-speed counters, pulse outputs and motion axes;
• PROFINET devices and other communications;
• work memory and retained data;
• expansion-module limits and physical width;
• safety requirements, which may require a fail-safe CPU and approved design process;
• future spare capacity.

Use at least 15–25% design allowance where the project standard permits it, but do not hide undefined scope inside “spares.” Reserve named spare channels and terminal positions in the I/O list.

3. Create the TIA Portal device

Create a project, add the exact CPU from Devices & networks, and select the order number and firmware that match the hardware. Then:

1. Add signal and communication modules in physical order.
2. Set the device name and IP parameters from the approved network schedule.
3. Configure channel properties and diagnostics.
4. compile the hardware configuration;
5. save a baseline archive before application logic begins.

If the installed device is absent from the catalog, stop and resolve the TIA Portal, hardware-support-package or firmware compatibility issue. Choosing a “close enough” CPU creates unreliable diagnostics and download risk.

4. Build a symbolic I/O map

Direct physical addresses scattered through the program make migrations and troubleshooting harder. Create one mapping routine that transfers physical I/O to descriptive application tags.

Name a signal by what it means when TRUE. OverloadHealthy is clearer than Overload because it tells the reader how the normally-closed field circuit is interpreted.

5. Structure OBs, FBs, FCs and DBs

• Organization blocks (OBs) define execution entry points. Keep the main cyclic OB readable.
• Function blocks (FBs) own reusable behaviour and persistent instance data—for example a motor, valve or pump.
• Functions (FCs) suit stateless calculations or conversions.
• Data blocks (DBs) hold instance data, configuration, recipes and shared process values.

A useful rule is: the main OB should coordinate, not contain the entire machine.

OB1
 ├─ FC_MapInputs
 ├─ FB_ModeManager
 ├─ FB_Conveyor_01
 ├─ FB_Pump_01
 ├─ FC_AlarmSummary
 └─ FC_MapOutputs

For each equipment FB, separate:

• requests: auto start, manual start, stop, reset;
• permissives: conditions required before starting;
• interlocks/trips: conditions that stop or prevent operation;
• outputs: run command and status;
• diagnostics: cause, timestamp or state useful to the HMI.

6. Program a motor as a state, not only a seal-in rung

A training motor can be reduced to a start/stop latch. A production motor normally needs mode, permissive, feedback, timeout and trip handling.

StartRequest := AutoStart OR (ManualMode AND StartPB);
ReadyToStart := StopCircuitOK AND OverloadHealthy AND ProcessPermissive;

IF ResetPB AND OverloadHealthy THEN
    TripLatched := FALSE;
END_IF;

IF RunCommand AND NOT RunFeedback AND StartFeedbackTimer.Q THEN
    TripLatched := TRUE;
END_IF;

IF StopRequest OR NOT ReadyToStart OR TripLatched THEN
    RunCommand := FALSE;
ELSIF StartRequest THEN
    RunCommand := TRUE;
END_IF;

This is an illustrative pattern, not safety logic. Emergency-stop and other safety functions belong in a risk-assessed safety system using approved components and validated safety software.

7. Simulate the abnormal cases

PLCSIM can verify application behaviour that does not depend on unavailable hardware or exact device timing. Build a test sheet before opening the simulator.

Minimum motor tests:

1. Start with all permissives healthy.
2. Start with one permissive missing.
3. Remove a permissive while running.
4. Apply overload while stopped and while running.
5. Fail to receive running feedback.
6. Restore feedback after timeout.
7. Switch Auto/Manual during operation.
8. Cycle power or restart the CPU and verify retained state intentionally.

Record expected output, observed output and pass/fail. Watching a green rung once is not a test record.

8. Download without creating an uncontrolled start

Before download:

• use an approved maintenance window;
• identify who controls the machine;
• place outputs and drives in a safe condition;
• compare the accessible device by order number, MAC/IP details and station name;
• review what changes on download or restart;
• know how to return to the validated version.

After download, prove inputs first. Then force or command outputs only under the site's commissioning procedure. Remove every force, verify the force table is empty and archive the commissioned project.

S7-1200 troubleshooting map

Project quality checklist

• Exact CPU, firmware and module order numbers are documented.
• Hardware, network and safety requirements are separated.
• All physical I/O is mapped to descriptive tags.
• Outputs have intentional safe/startup states.
• Equipment logic has permissive, trip and feedback behaviour.
• HMI commands cannot bypass PLC interlocks.
• Simulation covers abnormal and restart cases.
• Download and rollback plans are approved.
• Field I/O checks and functional tests are recorded.
• The final project archive matches the running controller.

Primary references

• Siemens, S7-1200 G2 programmable controller system manual, V1.0.1, April 2025.
• Siemens, S7-1200 G2 system-manual product update, August 2025.
• Siemens Industry Online Support should be used to verify the current manual, firmware and TIA Portal compatibility for the exact order number.

Continue learning

• TIA Portal programming tutorial
• Siemens PLC programming tutorial
• Siemens PLC error codes
• PROFINET tutorial