Meldas 320M Tape Mode: Drip-Feed Programs via RS-232

Problem: Program Too Large for Meldas 320M Memory

The Mitsubishi Meldas 320M is a machining-centre CNC of late-1980s/early-1990s vintage, fitted to a range of OEM machines (Leadwell and others). Its resident part-program memory is small by modern standards, so 3D surfacing or long engraving programs generated by CAM will not fit. Two documented paths exist to run oversized programs:

1. Expand resident memory with the MC461 plug-in memory card.
2. Run the program directly from a PC using the control's Tape Mode (drip-feed / DNC) over the RS-232 serial port.

Both are valid; the choice depends on whether the enlarged memory is still big enough for your worst-case program, and whether you already have a PC cabled to the control.

Option A: MC461 Memory Expansion Card

The MC461 plug-in card adds 128 kB of part-program storage to the control. Vendor figures for that increment are:

Before ordering, size your real workload against the character figure, not the tape length. A quick check on the PC:

REM Windows - character count of the NC file
for %F in (PROG.NC) do @echo %~zF bytes

# Linux/macOS
wc -c PROG.NC

One byte of ASCII in the file corresponds to roughly one stored character, so a 63,000-character increment holds a file of about 63 kB minus overhead. Strip the fat before you measure:

• Delete all comments in parentheses and blank lines.
• Suppress redundant modal words — repeat only the axis words that change (G01 X10.5 instead of G01 X10.5 Y0. Z-2. F200 on every line).
• Drop trailing zeros where the control's decimal handling allows it.
• Increase CAM chordal tolerance / reduce point density on 3D toolpaths — this is usually the single biggest saving.

If the trimmed program still exceeds the expanded memory, or if programs vary widely job to job, go to Tape Mode. Memory expansion is a fixed ceiling; drip-feed has effectively none.

Option B: Tape Mode Drip-Feed from a PC

In Tape Mode the control does not store the program. It reads blocks from the serial port, buffers them, and executes them as they arrive. Program size is limited only by the PC file system.

Hardware and software required

Throughput check before you commit

At 9600 baud with the common 1 start / 8 data / 1 stop framing, one character costs 10 bits:

Characters per second = 9600 bits/s / 10 bits/char = 960 char/s

If average block length = 30 characters (incl. CR/LF):
  Blocks per second = 960 / 30 = 32 blocks/s

Required block rate at feedrate F with average move length L (mm):
  blocks/s = F [mm/min] / (60 * L [mm])

Example: a 3D finishing pass with 0.1 mm average move length at F2000 needs 2000 / (60 * 0.1) = 333 blocks/s — far beyond what 9600 baud delivers. The control will starve and dwell between blocks, leaving witness marks. Either raise the chordal tolerance so blocks get longer, or reduce feedrate. Compute the sustainable feedrate directly:

F_max [mm/min] = 60 * L * (960 / avg_chars_per_block)

For 30-character blocks and 0.1 mm moves: F_max = 60 * 0.1 * 32 = 192 mm/min. If 7-bit even-parity framing is used the character cost is still 10 bits per frame in most configurations; confirm the actual framing set in your I/O parameters before relying on the number.

Setup procedure

1. Match the serial parameters on both ends. Set baud rate, data bits, parity, stop bits and handshake in the control's input/output parameter screen, then set the terminal program identically. Note the exact values on a label inside the cabinet — they are the first thing you will re-check after any failure.
2. Use hardware handshake if the port supports it. The control must be able to throttle the PC when its buffer fills. If the wiring or the control only supports software flow control, select XON/XOFF on both sides. Never run drip-feed with flow control off.
3. Prepare the file. Plain ASCII, CR+LF (or the terminator your control expects) at end of block, no BOM, no tabs, no extended characters. Save as .txt or .nc — never as a word-processor format.
4. Select TAPE mode on the machine operation-mode selector.
5. Arm the control first, then send. Press CYCLE START so the control is waiting on the port, then trigger the text/file send from the PC. Sending before the control is listening loses the leading characters.
6. Add character pacing. In the terminal program, set a small per-character and per-line delay (start at 0 ms character / 10 ms line and increase only if you see dropped characters). Excessive pacing starves the buffer at high feedrates.
7. Dry-run the first job with the Z axis raised and single block on for the first dozen blocks, confirming the displayed block text matches the file line for line.

TAPE I/O Error on the Last Block

A reported and reproducible failure on 320M drip-feed is a TAPE I/O error raised when the final block is read. The transfer itself runs cleanly; only the end of the file misbehaves. The cause is a mismatch between what the control expects as an end-of-transmission sequence and what the terminal program actually sends after the last data character.

Diagnostic sequence

1. Confirm the last line is terminated. Most editors leave the final line without a trailing CR/LF. The control then sits waiting for an end-of-block that never arrives, times out and faults. Open the file in a hex-capable editor and confirm the file ends with the end-of-block bytes (0D 0A for CR+LF), not with a program word.
2. Check the program-end structure. Tape-format programs conventionally open and close with the rewind-stop code %, with M30 (or M02) as the last executable block. Test both structures: % ... M30 ... %, and without the trailing %. One of the two will normally clear the fault on a given control.
3. Try appending an EOT/end-of-file character after the closing sequence, or removing it if your file already carries one. HyperTerminal-style ASCII sends do not add one; some DNC packages do.
4. Test with padding. Append several blank lines (bare CR+LF) after M30. This gives the reader harmless filler to consume during the shutdown of the read.
5. Change the transfer program. If HyperTerminal is in use, retest with dedicated DNC software. This is the same class of defect that produces the occasional corrupted character noted above.
6. Verify flow control on shutdown. If the PC drops DTR/RTS the instant the file ends, the control can register a line fault. Configure the terminal to hold the port open after the send completes, and close it manually.

Choosing Between the Two Options

A common practical arrangement: keep the PC permanently cabled as an external program store — uploading and downloading finished programs into control memory as normal — and reserve Tape Mode for the few jobs that genuinely will not fit. That preserves full block-processing speed for routine work while still covering the outliers.

Cable and EMI Practices

• Use shielded serial cable, shield bonded at one end only (normally the control cabinet) to avoid a ground loop between the PC and machine earth.
• Route the cable away from servo/spindle power conductors. Cross at 90° where a crossing is unavoidable.
• USB-to-RS-232 adapters vary widely in reliability under industrial noise. If the transfer works from a native serial port but fails from an adapter, the adapter is the suspect — try a different chipset before rewriting the program.
• Do not hot-plug the serial connector while the control is in Tape Mode.

FAQ