S7-300 to S7-1500 — what you keep in the DB and what you rewrite

TS ControlsThe answer

Keep the logic that is proven. Rebuild the interface to the HMI, other PLCs, and SCADA once, cleanly. Much of the pain in these migrations comes from carrying S7-300 addressing habits into an S7-1500 and then fighting them for years.

Know what the migration tool gives you. Migrating a STEP 7 Classic project into TIA Portal and then moving the program to an S7-1500 gets you a project that is close to compiling, with a list of errors and warnings to work through. It does not get you a well-built S7-1500 program. Expect blocks migrated with standard (not optimized) block access, so absolute addressing still works. Expect instance and global DBs with absolute offsets that the HMI, other PLCs, or SCADA may be reading directly. Expect some system functions (SFCs and SFBs) and older instructions to be replaced, or flagged for you to replace by hand. And expect the symbol table to carry over as it was, mess included.

What to keep: process logic that has run production for years, meaning sequences, interlocks, and fault handling. Converting it carries less risk than rewriting it, as long as you test it. Do not rewrite a sequence because it is ugly. That is the part that holds years of fixes nobody wrote down.

What to rebuild, starting with the HMI and the external interface. Create a clean interface DB, or a few, built from UDTs: commands in, status out, and alarms as a structured array. Point the HMI only at these. This is the one place a rebuild pays for itself, because every absolute address WinCC still reads is something that breaks the next time someone inserts a variable in that DB.

Next, the hardware and the I/O mapping. S7-300 modules do not plug into an S7-1500 rack, so the hardware configuration is new: ET 200SP or ET 200MP, or the existing ET 200M modules on PROFINET through an interface module where that is supported. Keep a documented map of each old address to its new tag.

Then communication. PUT/GET to other PLCs works on an S7-1500, but it has to be allowed in the CPU’s protection settings, and it only reaches data with absolute addresses, which rules out optimized DBs. Where the other side supports it, consider configured connections or I-Device instead.

Then safety. If the S7-300 was an F-CPU, the safety program migrates as a separate effort with its own acceptance testing. Plan for it as its own line item.

Optimized or standard access? Moving every block to optimized access in the same outage is a bigger change than the hardware swap. A sensible path is to leave the migrated process blocks on standard access for the cutover, make every new block and the new interface DBs optimized, and convert the legacy blocks later, one at a time, when you are in them for another reason.

The HMI moves too. If it is WinCC flexible, it has to be migrated to a TIA Portal HMI device as well. Decide whether it becomes a Comfort Panel or a WinCC Unified panel. Unified is not a straight conversion, so plan time for reworking screens. Either way, point the tags at the new interface DBs instead of the old addresses.

Before the cutover weekend, compile with no warnings you do not understand. Use PLCSIM Advanced, or PLCSIM where it is enough, to run the sequences and the HMI against the new interface. Keep a printed and a digital copy of the I/O map at the panel. Keep the S7-300 ready to reinstall as the fallback until the S7-1500 has run production.

Siemens has moved the S7-300 to spares-only, so replacement modules only get harder to find. That is the reason to plan the migration on your schedule instead of after a failure.

Need hands on it? Send the project file, the symptom, and your outage window to sales@ts-controls.com or through the RFQ form, or call the office at (877) 524-6674, Monday–Friday, 9:00am–5:00pm Eastern. Line down right now? Call (877) 790-4697, 24/7, subject to personnel availability.