Deckel Dialog 11 'Datei zu klein' LSV2 Transfer Fix

Problem Details

A Deckel Dialog 11 control aborts an incoming NC program transfer and posts Datei zu klein ("file too small"). The message appears on the control side during or immediately after a serial upload from a PC, typically using an LSV2-capable transfer package. The transfer terminates, and either no program is stored or a truncated program block remains in control memory.

The message is a control-side rejection, not a PC-side error. That distinction matters: the PC transfer tool usually reports a completed or timed-out send while the Dialog 11 reports the file condition. Treat the PC log and the control message as two independent pieces of evidence.

Root Cause Candidates

Work these in order of likelihood. Each one produces the same control message, so isolate by test rather than by guesswork.

Decision Path: Pick the Right Transfer Strategy First

Before troubleshooting the wire, decide what the machine actually has to do. Three operating models are commonly used with Deckel Dialog controls, and they have different failure modes:

1. One-off file transfer. A single program is pushed into control memory, then run from memory. Simplest to commission; only needs a working serial link and enough free memory. Choose this if the current job is a single program and external programming is not a standing requirement.
2. General external programming with upload to the machine. Programs are authored/post-processed on a PC and transferred to control memory as a routine workflow. Requires a repeatable, documented serial configuration and a naming/archiving convention. Choose this when the machine holds programs long enough to run them but the shop wants the PC as the master source.
3. Reload / drip-feed mode (Nachlademodus). The control executes blocks as they arrive over the serial link instead of storing the whole program. Choose this when the program exceeds available control memory — for example long 3D contour or surfacing programs. This mode is far more sensitive to handshake correctness, because the link stays active for the entire cut.

If the program in question is large, option 3 removes the memory constraint entirely and may be the fastest route past a "Datei zu klein" condition that is really a memory/allocation issue. If the program is small, option 3 adds risk without benefit — fix the link and use option 1 or 2.

Solution Procedure

Step 1 — Establish a known-good baseline

1. Create a minimal test program on the PC: a few valid blocks with the correct program start and end structure for the Dialog 11 dialect.
2. Transfer it into control memory. If this succeeds, the physical link and basic serial parameters are functional and the fault is size-, structure-, or memory-related. If it fails identically, the fault is in the link or in the serial parameters.

Step 2 — Verify serial parameters on both ends

1. Read the interface settings out of the control's machine/interface parameters and write them down exactly: baud rate, data bits, parity, stop bits, and handshake method (hardware RTS/CTS vs. software XON/XOFF).
2. Configure the PC transfer software to the identical values. A single mismatched stop bit or parity setting will pass short bursts and corrupt longer ones.
3. Confirm which handshake the control is configured for. Hardware handshake with a 3-wire cable is a classic cause of transfers that die once the control's receive buffer fills — which reads on the control as an incomplete, therefore "too small", file.

Step 3 — Validate the cable

1. Confirm TxD/RxD are crossed correctly for the control's DTE/DCE role.
2. If hardware handshake is configured, confirm RTS/CTS (and any DTR/DSR lines the control requires) are actually wired end-to-end — not looped back at one connector.
3. Keep the run short and away from drives, servo cables and contactor wiring. Use shielded cable with the shield grounded at one end only.

Step 4 — Address the PC layer

1. Prefer a native RS-232 port. Where only USB is available, use an industrial USB-to-serial adapter with a well-supported chipset and current drivers.
2. Use transfer software that is maintained for Windows 10/11 and explicitly supports the Deckel LSV2 protocol. Legacy DOS-era transfer utilities frequently fail on modern Windows because direct UART timing access is no longer available.
3. Disable PC power-management sleep on the USB/serial device for the duration of a drip-feed session.

Step 5 — Check control memory

1. Delete or archive unused programs from control memory and retry.
2. If the file only transfers after clearing memory, the original message was an allocation failure. Either keep memory clear as policy, split the program, or move to reload/drip-feed mode.

Step 6 — Check file structure

1. Confirm the file uses the line-ending convention the control's receiver expects. Mixed or missing terminators can leave the control waiting for a block that never completes.
2. Confirm the program header/number and end-of-program block match Dialog 11 syntax exactly. A post-processor emitting a foreign dialect can be accepted byte-wise but rejected structurally.
3. Strip stray control characters, BOM markers, or trailing binary garbage introduced by an editor.

Verification

Commissioning Notes for Long-Term Use

• Document the working serial parameter set and cable pinout, and attach a copy to the machine. This is the single highest-value artifact once the link works.
• Standardize on one PC and one adapter for machine transfers. Mixed adapters reintroduce timing variability.
• Keep an archive of every program as sent, byte-identical, so a suspect transfer can be compared against a known-good file rather than re-post-processed.
• Decide early between store-and-run and reload mode; the two impose different requirements on link reliability, and mixing them ad hoc makes intermittent faults hard to attribute.
• If an external specialist is engaged, insist on a documented test transfer of both a minimal program and a full-size production program before sign-off.

FAQ