The engineer sees one PC transfer files successfully to one CNC while another produces garbled characters, stops after a block, times out, or receives nothing. The number that matters is not the machine count; it is the complete communication profile assigned to each control. Character framing, parser timing, cable wiring, and file delimiters must all match the receiving CNC.
Electrical and Timing Limits
A serial character is a timed electrical waveform. The receiver samples that waveform according to its configured baud rate, data width, parity, and stop-bit format. A mismatch changes the interpreted byte before the DNC application can process it. This is signal timing, not program logic.
Inter-character and inter-block delays act at a different layer. They compensate for a control that parses or stores incoming data more slowly than the PC can transmit it. Excessive delay makes a valid transfer unnecessarily slow; insufficient delay can cause dropped characters, buffer overruns, or a transfer that stops at a repeatable location.
| Quantity or rule | Failure when incorrect | Where to read it |
|---|---|---|
| Baud rate | No reception or repeated corrupt characters | CNC communication configuration and DNC profile |
| Data bits, parity, stop bits | Wrong symbols, parity errors, rejected blocks | CNC serial-channel parameters or communication manual |
| Protocol or handshake | Transfer never starts, pauses indefinitely, or overruns | CNC interface documentation and cable specification |
| Inter-character delay | Characters disappear during continuous transmission | DNC transmit profile; determine by controlled testing if undocumented |
| Inter-block delay | Blocks are truncated or reception stops at line boundaries | DNC transmit profile and CNC input behavior |
| End-of-block character | Multiple lines merge or every block is rejected | Known-good CNC program and control documentation |
| Start, end, or removal sequence | Header text enters program memory or the control never recognizes completion | Known-good upload and DNC framing configuration |
| Receive timeout | A slow or paused upload terminates early | DNC receive profile and transfer log |
Configuration Strategy Comparison
| Approach | Benefit | Technical risk | Use |
|---|---|---|---|
| One global profile | Minimum setup effort | Assumes every CNC uses identical framing, handshake, delimiters, and timing | Only for controls already proven identical |
| Clone and adjust profiles | Fast deployment across related controls | Hidden differences can remain in cable wiring, machine parameters, or file framing | Useful as a starting point, followed by full verification |
| Dedicated profile per CNC | Preserves every machine-specific value and directory | Requires disciplined naming and records | Recommended for the mixed-control installation |
The installation includes controls from Allen-Bradley, Deckel, Fanuc, Heidenhain, Mazatrol, Num, Selca, Siemens, and MSX families. A single global setup is therefore the wrong control boundary. Create an independent profile for every CNC, even when two machines share a family name. Clone a verified profile only when the cable, CNC channel configuration, and transfer test all match.
Per-Control Profile Data
DCN20 separates communication, common machine data, transmit settings, and receive settings. Record the fields as one version-controlled machine profile rather than as isolated values.
| Profile group | Fields to capture | Purpose |
|---|---|---|
| Communication |
COM port, baud, data bits, parity, stop bits, protocol, ASCII/error-display options |
Defines character generation and flow control |
| Machine | Machine name, machine directory, code directory | Prevents programs from being routed to the wrong control |
| Transmit | Delay before first sequence, inter-character delay, added parity character, end-of-block character, inter-block delay, removal sequence, first sequence | Controls outbound framing and pacing |
| Receive | Removal sequence, end-of-block sequence, timeout | Controls upload parsing and completion detection |
Machine parameter numbers cannot be transferred between control families by analogy. The requested Num 750 example mentioning P37, eight data bits, and two stop bits is a desired documentation format, not a verified configuration. Read the actual channel parameter from that CNC, its communication manual, or its parameter backup before entering a value.
Profile Commissioning Procedure
- Give the CNC a unique profile name containing the control family and machine identifier. Assign a separate program directory.
- Identify the physical CNC communication channel and its configured electrical interface. Obtain the cable pinout for that channel; software settings cannot correct crossed data conductors or missing handshake conductors.
- Read the CNC values for baud rate, data bits, parity, stop bits, and handshake or protocol. Copy them into the matching DCN20 communication fields.
- Start with timing values documented for the control. If no timing is documented, begin with a short, known-good program and adjust only one delay field at a time. Record every test value and result.
- Upload a program already accepted by the CNC. Use it to identify the actual line ending, opening sequence, closing sequence, and any characters that the PC must remove.
- Configure transmit framing to reproduce that accepted structure. Keep receive-removal rules separate from transmit-added sequences; treating both directions as identical can delete valid program content.
- Test PC-to-CNC reception with the short known-good program before transferring a production file. Confirm the destination memory area and machine operating state locally.
- Save the profile and export or document the CNC communication parameters, cable drawing, DNC fields, test filename, and verification result.
Directional Framing and Pacing
Upload and download are two independent transactions. A CNC may transmit without hardware flow control yet require it while receiving, or it may emit framing characters that it does not accept on input. A successful CNC-to-PC upload therefore proves the cable transmit path and part of the character format, but it does not prove the reverse path.
Use removal sequences only after viewing the received byte stream or a known-good file. A broad removal rule can silently strip valid program characters. Set the end-of-block character from the CNC’s accepted program format, then use inter-block delay only to solve a measured pacing problem. Delay cannot repair incorrect parity, stop bits, handshake selection, or cable wiring.
Verification and Fault Isolation
Verify at three levels. First, confirm that DCN20 opens the intended COM port without an operating-system or application error. Second, confirm character integrity: readable text, stable line endings, and no repeated parity indication. Third, confirm CNC acceptance by loading the test program, viewing its blocks locally, and comparing it with the source file.
| Observed symptom | First checks | Next action |
|---|---|---|
| No characters in either direction | COM-port selection, cable path, interface type, handshake state | Test the channel and conductors before changing delimiters |
| Consistently garbled text | Baud, data bits, parity, stop bits | Match the CNC framing exactly |
| Readable text with merged blocks | End-of-block character or sequence | Compare with a known-good upload |
| Transfer stops at a repeatable block | Handshake, buffer pacing, inter-block delay | Inspect the last accepted block and change one timing variable |
| Upload works; download fails | Reverse data path, receive state, directional handshake | Verify the PC transmit conductor and CNC receive configuration |
| Header or trailer appears in CNC memory | Receive-removal sequence | Remove only the confirmed transport sequence |
FAQ
Why does one DNC profile fail across several CNC controls?
Each control can use different character framing, handshake, cable wiring, timing, and file delimiters. Assign and verify a dedicated DCN20 profile for every CNC.
Why does the CNC receive garbled characters?
Start with baud, data bits, parity, and stop bits. Timing delays affect pacing, but they do not correct a character-framing mismatch.
Why does a DNC transfer stop after several blocks?
Check handshake operation and whether the failure repeats at the same block. If framing is correct, increase only the relevant inter-character or inter-block delay and repeat the same short test.
Why does CNC-to-PC work while PC-to-CNC fails?
The two directions use different conductors and may invoke different receiver or handshake behavior. Verify the PC transmit path, CNC receive state, and inbound framing independently.
When should I stop troubleshooting DNC communication?
Stop changing settings when the CNC parameter meaning, interface type, or cable pinout cannot be identified, or when tests could overwrite machine programs. Preserve the parameter backup, DCN20 profile, cable drawing, error display, and last received bytes. Escalate those records with the exact control model to the manufacturer’s official support channel.