BMC-20 Ultimax II Drip Feed: Fix Mid-Program Stops

Continuous execution depends on two-way serial flow control. The control accepts blocks until its input buffer fills, pauses the sender, executes buffered blocks, discards completed blocks, and then accepts more data. A working small-file transfer proves basic communication, but it does not prove that the sender honors the pause-and-resume exchange required by drip feed.

Drip-feed operating sequence

The term drip feed here means executing a program while the PC continues supplying blocks through the serial connection. The full program does not have to fit in control memory. For this BMC-20 with Ultimax II, no additional drip-feed setting was identified in the control; commissioning moves to the DNC sender and serial path.

At the beginning of a large transfer, the control fills its available buffer and then requests a transmission pause. That pause is expected behavior. After the operator selects AUTO, presses the RUN PROG softkey, and presses START, execution frees buffer space. The control can then release the sender to transmit subsequent blocks.

A displayed 9% memory value does not, by itself, define whether the display represents used memory, free memory, or another control-specific quantity. The decisive observation is whether serial transmission pauses without an alarm and resumes after execution creates buffer space.

Check 1: Send a program larger than the approximately 1000-line resident-memory limit observed on this installation. Expect the transfer to pause when the buffer fills rather than terminate as a completed download.

Baseline bidirectional communication

Prove the existing communication settings before changing the cable or DNC configuration. Transfer a small known program from the PC to the control, then transfer a control program back to the PC. Successful operation in both directions confirms that the transmit, receive, and signal-ground conductors are present and that the serial framing settings are compatible.

This baseline does not validate drip feed. A short transfer may finish before the control has to pause the PC, so a sender with incorrect flow-control behavior can still pass every small-file test. Preserve the working communication parameters when enabling software handshaking; changing several settings simultaneously obscures which change corrected the fault.

1. Save or record the DNC profile that successfully transfers small programs.
2. Send a short program to the control and compare its beginning and ending blocks with the PC file.
3. Upload a program from the control and compare the received text with the control copy.
4. Retain the same serial framing and communication parameters for the large-program test.

Check 2: Expect complete, readable program text in both directions with no missing, repeated, or corrupted characters. If either direction fails, repair basic serial communication before testing buffer flow control.

Serial cable signal assignment

The final cable mapping uses three functional conductors: receive data, transmit data, and signal ground. The receive and transmit paths cross because each device's transmitter must connect to the other device's receiver.

Hurco round connector	Function	PC DB-25	PC-side function
B	Receive data	2	Transmit data
C	Transmit data	3	Receive data
F	Signal ground	7	Signal ground

B	Receive data	3	Transmit data
C	Transmit data	2	Receive data
F	Signal ground	5	Signal ground

The installed DB-25 cable was reported as A-1, B-2, C-3, D-4, E-5, and F-7, with G and H unused. Its three required paths therefore agree with the final mapping at B-2, C-3, and F-7. Extra connected conductors do not establish whether the DNC application is using hardware or software flow control.

A preliminary cable recollection mentioned jumpers, but the final pin assignment supplied no jumper positions. Do not install guessed jumpers. Commission the documented three-signal path with software handshaking.

Check 3: With power removed from the cable interfaces, verify end-to-end continuity for the three mapped conductors and check that transmit, receive, and ground are not shorted together. Expect B, C, and F to terminate at the stated PC pins.

Software-handshaking configuration

Configure the PC DNC software for software handshaking. This mode carries pause and resume control through the data channel rather than depending on separate hardware-handshake conductors. It matches the three-wire cable assignment and allows the control to regulate the sender as its receive buffer fills and empties.

The DNC application must react to both states. When the control requests a pause, the PC must stop adding characters before the buffer overruns. When execution frees space and the control releases the pause, the PC must continue from the next unsent character. A sender that stops correctly but never resumes leaves the machine executing only the initially buffered portion. A sender that ignores the pause can lose or corrupt blocks at the buffer boundary.

Select software handshaking in the same DNC profile used for successful small transfers. Do not substitute hardware handshaking merely because additional cable conductors are present. Also check that no intermediate serial adapter or communication layer strips the in-band flow-control characters.

Check 4: Start a large transfer while observing the DNC application's transmit status or character count. Expect the count to stop when the control buffer fills and advance again after program execution begins.

Large-program start procedure

Use a controlled commissioning program whose motion and tooling have already been validated. It must be long enough to cross the buffer boundary; otherwise, it tests only ordinary download operation.

1. Connect the verified B-C-F cable to the correct PC serial connector.
2. Load the known-working DNC profile and select software handshaking.
3. Begin sending the large program from the PC. Allow the control to accept data until its buffer becomes full and transmission pauses.
4. On the control, select AUTO.
5. Press the RUN PROG softkey.
6. Press START under the machine's normal controlled proving conditions.
7. Observe the DNC sender as the control executes the initial blocks. The transmitted character or block count must resume and continue beyond its pre-start value.

Do not interpret the initial buffer-full pause as a failed download. Starting a second transfer or resetting the first one at that point can replace the intended streaming session. Maintain the original session while the control consumes buffered blocks.

Check 5: Expect machine execution and PC transmission to overlap: the machine advances through the program while the DNC application's sent count periodically advances as buffer space becomes available.

Stop-point fault isolation

A repeatable stop near the same program line marks the boundary between the initially received data and the data that should have arrived after execution started. On this installation, the program stopped at line 1524. That line is a diagnostic landmark, not a universal buffer capacity.

Observed symptom	Likely mechanism	Next check
Small uploads and downloads work, but a large program stops near the same line	Basic serial data works, but the DNC sender does not complete the pause-and-resume exchange	Select software handshaking and watch the transmitted count after START
Transmission pauses when the buffer fills and never resumes	The sender is not recognizing the control's resume state, or the control-to-PC receive path is interrupted	Verify round-connector C to the PC receive pin and confirm bidirectional transfer
Transmission continues while the control reports a full buffer	The sender is not honoring the control's pause state	Confirm the active DNC profile uses software handshaking
Characters are corrupted before the repeatable stop	Basic communication settings, grounding, or cable integrity are faulty	Return to the small bidirectional transfer and continuity tests
The stop moves with a program edit	A program-content or execution condition may be stopping the control rather than the serial buffer	Read the control message at the stop and compare the last executed block with the source file

At a stop, compare three positions: the last executed control block, the last block shown as transmitted by the PC, and the corresponding block in the source file. If the PC never transmitted beyond the boundary, diagnose handshaking or the return data path. If the PC reports later blocks transmitted but the control never received them intact, inspect flow-control handling, cabling, and communication errors.

Check 6: Repeat the same file from a known start condition. Expect software handshaking to carry execution beyond line 1524; a repeatable stop there means the streaming session still is not resuming correctly.

End-to-end commissioning proof

A valid proof must exceed both the initial buffer fill and the previously observed failure point. Monitor control execution, the DNC send count, and the final program state during one uninterrupted session.

1. Begin with the verified cable and the saved DNC profile configured for software handshaking.
2. Send the full program and confirm that the first buffer-full condition pauses the PC.
3. Start execution with AUTO, RUN PROG, and START.
4. Confirm that the PC resumes sending as the control consumes buffered blocks.
5. Verify execution beyond line 1524 and through multiple subsequent pause-and-resume cycles.
6. At normal program completion, compare the executed ending block with the source-file ending block and confirm that the DNC sender reports the transfer complete.

Check 7: Expect the control to execute the complete program without a resident-memory stop, while the PC alternately pauses and resumes transmission under control of the serial software-handshake exchange.

Frequently asked questions