Siemens T400 Module Backup and Replacement in Masterdrives

Overview of the T400 Technology Module

The Siemens T400 is a SIMADYN D technology module that augments a SIMOVERT MASTERDRIVES (CUVC) or DC MASTER (VCU) drive with high-speed closed-loop control and user-programmable technology functions. In normal operation the CUVC handles torque and speed control of the motor, while the T400 runs a CFC (Continuous Function Chart) program in parallel to deliver functions that the standard drive firmware cannot: winder tension control, sectional-drive synchronisation, registration control, position control, and similar high-level automation tasks.

Two encoder inputs are available on the T400's front connector and accept incremental (HTL/TTL) or SSI absolute transducers. Communication with the host drive is through the dual-port RAM (DPR) of the CUVC/VCU, with optional routing via SCB1, SCB2, or CB1 communications boards when the T400 is mounted in a stand-alone SRT400 subrack. The full functional description is in the Siemens SIMADYN D documentation set.

Reference: SIMADYN D T400 Technology Module - Function Description

T400 Hardware Architecture and Variants

The T400 is a 3U format module that mounts in the MASTERDRIVES electronics box or, in stand-alone SIMADYN D applications, in an SRT400 subrack. Several hardware layout revisions exist; the MLFB printed on the front label and the hardware revision code visible on the diagnostic display are required to identify the correct variant. A bare-board T400 contains a CPU, two encoder interface channels, RAM and flash, the dual-port RAM interface to the host drive, and the MPI/PROFIBUS interface for engineering access.

Two field-relevant accessories sit on the PCB:

• A small serial EEPROM in a low-profile socket, holding board-specific data (calibration, serial number).
• An optional chip socket, populated only on T400s that ship with copy protection enabled.

Field experience shows three hardware revisions in active service. Each revision needs a matching set of SIMADYN D libraries; mixing revisions and library sets is the most common reason for cascade failures on commissioning day. Verify the hardware revision by reading r001 and by visually checking the PCB silk-screen before installing the spare.

The two encoder inputs share a common front connector but are independent channels. SSI absolute encoders and HTL/TTL incremental encoders can be mixed (one of each), with the configuration held in the T400's r-parameters. Encoder faults (broken wire, count overflow, SSI parity error) are reported back to the CUVC as a status word and may be wired through the CFC to drive a CUVC fault.

Engineering Software Stack

Three Siemens software packages are used with the T400. None of them is optional in the workflow.

The CFC source is held in a STEP 7 S7 program. The user edits, compiles, and downloads the chart to the T400 over MPI or PROFIBUS. After download, the T400 runs the chart from RAM; the operator must explicitly issue a Copy RAM to ROM to persist the program across a power cycle. Forgetting this step is one of the most common reasons a "working" T400 fails after a planned power-down.

D7-SYS versions are not all interchangeable. A CFC compiled under an older D7-SYS will open under a newer D7-SYS, but the project tree, library paths, and chart visualisation will be re-generated. The reverse (opening a new CFC under an old D7-SYS) is not supported and is a typical source of 500+ compile errors when the older tool cannot resolve the newer library set.

Step-by-Step: Backing Up the T400 Program

Two distinct artifacts must be preserved before a T400 is decommissioned: the CFC source in the STEP 7 project and the technology parameters held at runtime. They are independent; one does not back up the other.

1. Open the STEP 7 project that was used to commission the drive. Confirm that it opens without error and that the T400 is visible in HW Config.
2. Archive the project. In STEP 7, use File > Archive to produce a single-file backup. Store this file on a network share with revision control; do not rely on a local laptop.
3. From the S7 program folder, copy the imported SIMADYN D library list. The list is required to recompile the CFC on a different engineering PC.
4. Save the symbol table and any connection names used by the CFC.
5. Use Drive-ES to dump the drive and T400 parameter set to a file. Store this file alongside the STEP 7 archive.
6. Write down r000, r001, and r011 from the diagnostic display and tape the note to the inside of the cubicle door.

If the STEP 7 project has been lost, the only path back to a working program is the Target System > Load from MC function in D7-SYS, which reads the runtime CFC from the T400's flash. This requires that the source is not write-protected on the target. If the upload returns an empty chart, the protection bit is set and the source must be cleared first by an engineer with the matching CFC project. "Load from MC" is not a substitute for a real project archive: comments, chart layouts, and library references are often lost in the upload. Re-validate every chart against the running machine after a recovery upload.

Resolving 500+ CFC Compilation Errors After Upload

The reported "501 errors" when compiling a T400 CFC in D7-SYS is a classic library mismatch. Each T400 firmware version is tied to a specific revision of the SIMADYN D function-block library. When the imported libraries do not match the firmware level reported in r000, the compiler cannot resolve block types, pin names, or I/O definitions and emits one error per affected element. With even a moderately complex CFC, the error count quickly climbs into the hundreds.

Identify the Firmware Version

On the running T400, navigate to the diagnostic display and write down the version string from r000. Also note the hardware revision shown in r001. These two values determine which library set you must import. Common firmware strings look like V3.1.4 or FW 2.6, but the exact format depends on the T400 revision.

Update Imported Libraries in D7-SYS

1. Open the STEP 7 project containing the T400 CFC.
2. From the menu, choose Extras > SIMADYN D Library Manager (the exact path depends on the D7-SYS version).
3. The Library Manager lists every imported library and the version that the current CFC was last compiled against.
4. For each library flagged as older than the target, or marked as unknown, mark the entry and click Update.
5. Recompile. Errors should drop to zero or to a handful of legitimate source issues.

If the project still references blocks that the imported library set does not contain, the library was never shipped with your D7-SYS installation. Obtain the matching library archive from the original project archive, from the engineering contractor, or from Siemens Industry Online Support under the SIMADYN D option package.

The T400 Serial EEPROM

The small serial EEPROM (typically a 24Cxx/93Cxx I²C or Microwire device) on the T400 board stores non-volatile board-specific data: calibration constants, the module's serial number, and sometimes a runtime identifier. It is not the location where the user CFC program is stored; the CFC lives in the on-board flash memory.

Two practical consequences follow.

1. If a spare T400 is delivered without the EEPROM soldered or socketed, the module will still boot, but the drive will report a serial-number or calibration fault. The diagnostic display will show an invalid serial number.
2. If the EEPROM from the original module is transferred to the spare, the spare takes on the original's identity. This is sometimes intentional (to keep a paired encoder calibration) and sometimes not (because it breaks traceability for spare-tracking purposes).

The EEPROM is usually socketed. If your spare was delivered without one, it must be ordered separately using the MLFB printed in the T400 spare-parts list. The EEPROM is a low-cost item; it is intentionally separate from the T400 MLFB so that boards can be calibrated and tracked independently. Always handle the EEPROM with ESD precautions; a single static discharge can corrupt the calibration data and force a re-calibration of the encoder channels.

The Programmable Chip Socket (Dongle / Hardlock)

Some T400 layouts include a chip socket in the centre of the PCB. The chip installed in this socket is a programmable logic device whose bitstream is matched to the CFC application. Its function is copy protection: the T400 firmware will refuse to load a CFC that is not accompanied by the matching chip. If you swap a T400 board from a protected machine with a bare spare, the spare will not run the protected CFC even if the source compiles cleanly.

Two approaches to handling the dongle.

• Transfer the chip: remove the programmed chip from the donor T400 with an IC extractor and install it in the spare. The spare will then accept the original CFC. This is the field-recommended practice for keeping a cold spare ready.
• Recreate the chip: requires the original bitstream (a .jed or .mcs file in the project archive) and a compatible programmer. Only the original integrator or Siemens will normally have this file.

Downloading the CFC to the Replacement T400

Once the source compiles cleanly and the libraries are in sync, the download is a standard D7-SYS operation.

1. Power the MASTERDRIVES cubicle, with the new T400 installed and the CUVC in commissioning mode (no enable).
2. Connect the engineering PC to the T400's MPI/PROFIBUS interface. The default bus address is visible in the diagnostic display (r011 area).
3. In D7-SYS, select PLC > Download (or Target System > Download in newer builds) and confirm the target module.
4. After download, the T400 reboots into the new program. The diagnostic display should show the new firmware and program version strings.
5. Perform a Copy RAM to ROM so that the program survives a power cycle.

Typical download time is in the order of tens of seconds for a moderately complex CFC; a full chart can take one to two minutes over MPI at 187.5 kbit/s. PROFIBUS at 1.5 Mbit/s is roughly an order of magnitude faster. If the download stalls or terminates early, check the write-protect jumper and the bus address before re-trying.

Backing Up Technology Parameters with Drive-ES

The technology parameters held at runtime in the T400 (r-parameters, encoder scaling, position-controller gains, setpoint sources, and similar values) are independent of the CFC source. They are set at commissioning and tuned in production. Drive-ES can read and write them through the CUVC/VCU protocol by enabling the "technology bit" in the read/write command.

1. Start Drive-ES and connect to the CUVC as usual.
2. In the parameter list, enable the technology parameter set. On firmware V2.x the relevant parameter is typically P060 = 6 or the Tech tickbox in the parameter dialog (the exact path depends on the Drive-ES version).
3. Upload the full parameter set to the engineering PC. Save it as a Drive-ES parameter file.
4. Store the file alongside the STEP 7 project archive. Both the CFC source and the parameter set are required to fully restore a spare T400.

The same command with the technology bit enabled can be used to write individual parameters. For a full parameter dump, use the bulk upload in Drive-ES; do not script individual reads against a live T400 at high rate, because the bus traffic can interfere with the CUVC's real-time loop.

Spare-Module Commissioning Workflow

The end-to-end workflow for keeping a cold spare T400 ready is shown below.

Each numbered step in the figure is:

1. Record the running T400's r000, r001, and r011, the STEP 7 project, and a Drive-ES parameter dump.
2. Order the spare T400 with the same MLFB; verify the hardware revision matches.
3. If the running board has a dongle chip, transfer it to the spare before commissioning.
4. If the running board's EEPROM is unique, transplant it or plan for re-calibration.
5. Open the project in D7-SYS, resolve library versions, compile cleanly.
6. Download the CFC to the spare, perform a Copy RAM to ROM.
7. Store the spare in an ESD-safe bag, ideally with a label listing the project version, parameter-dump date, and donor MLFB.

Verification Checklist After a T400 Swap

Run through the following list before returning the drive to production. Each item is a binary pass/fail; do not hand the machine back to operations until every item is green.

• Diagnostic display shows the expected firmware version in r000.
• Diagnostic display shows the expected program version (r002 or equivalent).
• No F-class fault active on the CUVC; any T400-specific fault was acknowledged and cleared.
• Encoder counter matches the mechanical reference within one increment after a homing run.
• Technology parameters, read back via Drive-ES, equal the pre-swap dump.
• CFC runtime: all enabled charts report OK; no chart is in STOP.
• Controlled test of the affected process (a slow traverse, a winder tension step, a registration mark) matches the pre-swap response.
• Drive-ES parameter file is archived alongside the STEP 7 project on the engineering file share.

Troubleshooting Matrix

Safety and Handling Notes

The T400 is a low-voltage module that plugs into a MASTERDRIVES electronics box, but the host drive carries a high-voltage DC bus that can remain lethal for several minutes after mains removal. Before removing or inserting the T400, observe the standard MASTERDRIVES safety procedure: isolate the supply, wait for the DC-link voltage to drop below the safe threshold (typically five minutes after power-off, confirmed by the indicator LED on the CUVC), and verify with a meter.

The T400 itself is an ESD-sensitive device. Use a wrist strap and a grounded mat when handling the board outside the cubicle. Store the spare in a sealed ESD bag with a desiccant, and label the bag with the project version, parameter-dump date, donor MLFB, and the bus address of the donor.

Do not hot-swap the T400 with mains applied. The host CUVC will not tolerate the in-rush, and the module's encoder inputs can be damaged by transients during insertion. If the T400 is to be swapped in a running process, plan a maintenance window and a controlled stop of the section; the T400 cannot be hot-swapped in the way that a PROFIBUS slave can.

Frequently Asked Questions