Simovert CU2: Restoring PG Comms to Download Parameters

Problem Details

A SIMOVERT VC drive on a shiploader luffing (raise/lower) drive is being repaired. The control unit is a CU2 identified by order numbers 6SE7090-0XX84-0AF0 and 6SE7090-0XX84-0AJ0. The symptoms reported:

• Fault F044 appears, most often on the first power-up of the drive, and clears after a reset.
• The existing (in-service) CU2 communicates normally with the Siemens PG.
• The replacement CU2 will not establish communication with the same PG on the same cable, so the parameter set cannot be downloaded to it.

Two order numbers were quoted for one control unit. Confirm which number is stamped on the CU printed-circuit board and which one belongs to the associated firmware/software module or slot option, because a firmware level difference between the old and the new card is a legitimate cause of both download refusal and inconsistent parameter handling. Record both labels before you go further.

Root Cause Analysis

The most probable and cheapest cause to eliminate first is the parameter mismatch. Do that before you condemn hardware.

Solution: Align the Serial Parameters, Then Download

The PMU keypad on the front of the control unit gives you parameter access without any serial link. Use it to configure the new card to the same communication settings as the working card, then bring the PG online.

1. Document the working card. With the in-service CU2 fitted and the drive safely stopped, read and write down at minimum:
   P683 = ____
P684 = ____
P685 = ____
P686 = ____
   Record the software/firmware version parameter and the drive type/rating parameters at the same time. Confirm the exact meaning of each of these indices in the parameter list that matches the firmware on your CU; the index-to-function mapping is firmware-dependent and must not be assumed.
2. Upload the complete parameter set from the working card to the PG while it is still communicating. This is your restore file. Do not remove the working card until the upload is verified readable.
3. Power down and swap the card following the drive's ESD and DC-link discharge instructions. Wait for the DC-link to fully discharge before touching any card.
   Warning: Masterdrives DC-link capacitors retain hazardous voltage after the supply is opened. Observe the discharge time printed on the unit and verify absence of voltage at the DC terminals before removing the CU.
4. Set the new card from the PMU. Raise the access level to permit expert parameter changes, then enter the recorded values into P683-P686. Also confirm that the parameter-access/parameterization-enable parameter allows writing from the serial interface, not only from the keypad.
5. Re-attempt the PG connection with exactly the same cable, port and tool settings that work on the old card. If the tool offers a bus scan or "search for drive" function, use it before opening a stored project - it will report which node address and baud rate actually answer.
6. Download the saved parameter file. Use the drive's documented download sequence (the special-function/download parameter must be armed before the transfer and closed out afterwards, per your parameter list). Do not interrupt supply during transfer.
7. Save to non-volatile memory and cycle power. Re-read a handful of parameters, including P683-P686 and the motor data, to confirm they persisted.

If comms still fail after matching P683-P686

• Force a known state: perform a factory-setting/parameter-reset on the new card from the PMU, then set only the serial parameters. This clears any stale settings inherited from the card's previous application.
• Reduce the baud rate on both the drive and the PG tool to the lowest supported value and retry. Long or unshielded cables in a shiploader environment fail at high baud first.
• Check node address collisions if the PG cable is landed on a multi-drop segment. Two nodes at the same address produce exactly this "nothing answers" behaviour.
• Verify the physical port pinout on the CU against the drive wiring diagram. Confirm signal common is connected; an RS485 pair without a common reference is a classic intermittent-comms trap.
• Bench-test the card on a spare drive or with the OEM's service department. If a factory-reset card at default baud on a 1 m cable still will not answer, the serial driver is suspect.

Handling the F044 Fault

The source condition is that F044 appears mostly at first power-up and clears after a reset. Treat this as a separate investigation from the download problem - do not assume the replacement CU will cure it.

1. Look up F044 in the fault list for your unit and firmware version. Do not rely on a fault code meaning quoted for a different Masterdrives family; codes are family- and firmware-specific.
2. Read the fault memory and the associated fault value/index parameters immediately after the trip, before resetting. The fault value usually narrows the cause far more than the code alone.
3. Because the fault is biased toward the first power-up, log these at the moment of the trip:
   • Supply voltage and phase balance at the drive input terminals
   • DC-link voltage at the instant of trip
   • Ambient/cabinet temperature after an overnight cold soak
   • Whether the mechanical brake on the luffing arm is still applied and whether the arm is loaded
4. Check whether the drive is being commanded to run before pre-charge and initialisation have completed. A control system that issues an ON command too early after main contactor closure is a common cause of first-power-up-only trips on hoist and luffing drives.
5. Inspect the encoder/feedback wiring, screen termination and connector at the motor. Shiploader booms subject cables to constant flexing; an intermittent feedback break shows up on the first heavily loaded move of the shift.

Verification and Handover

Preventive Practice for Spare CU Cards

• Store spare control units pre-loaded with the correct application parameter set and the correct firmware level, matched to the specific drive tag.
• Never buy a spare CU on order number alone if a separate firmware/software module is part of the assembly - confirm both labels.
• Keep one known-good PG cable dedicated to drive work and label it; do not troubleshoot with an unproven cable.
• Record fault memory contents at every trip rather than resetting blind. On a machine that trips only at first power-up you get one opportunity per day to capture data.