Writing a CNC lathe program correctly is only one part of production. Transferring the program to the machine safely, calling the right program, checking the tool path before machining, correctly interpreting alarms and backing up programs regularly are also important parts of CNC production. In the real shop, most problems come not from poor knowledge of a G code but from operating errors: calling the wrong program, using an old version, missing lines during transfer, going to automatic without simulation, pressing reset without reading the alarm, uncontrolled editing while the program runs, not backing up offsets, and transferring without matching communication settings.
So a CNC programmer/operator is not only someone who writes code; they manage the program, check it, run it safely and protect the production data. In this lesson we cover memory layout, program creation/calling/editing, version control, graphics/single block/dry run/machine lock, restarting mid-program, alarm types and handling, RS-232/USB data transfer, backup and the program approval process. The aim is not to memorise the keys of one panel, but to teach the program-management and safe-operation logic valid on all controls.
xF0x9Fx93xB7 IMAGE AREA — Program-management cycle: write → check → transfer → run → back up
Suggested alt text: “CNC lathe program management and safe operation cycle”
1. What Is in CNC Memory? Program, Offset, Parameter
CNC memory holds not only part programs but also tool geometry/wear offsets, work coordinate offsets, macro variables, setting data, parameters, error-compensation data, tool-life info and the alarm history. These are not at the same risk level:
- Program data: defines how the part is machined; can be created and edited by the operator/programmer.
- Offset data: defines the real position of tools and the part on the machine; even a correct program crashes hard with a wrong offset.
- Parameters: set the basic behaviour of the control and machine; not changed during normal part setup.
A key distinction: editing programs and offsets is part of the production job; changing parameters is, in most cases, the job of authorised maintenance/service personnel.
2. Program Number, Identity and Comment Lines
On FANUC programs the program number is usually the O address (e.g. O1250). If numbers are chosen at random, versions of the same part get confused, operations cannot be separated, and an old program is used by mistake. A numbering system must be set up (e.g. O1250 = part 125 op 1, O1251 = op 2). There is no single universal method; what matters is that the system is clear, repeatable and recorded. Short comment lines are added at the program start:
% O1250 (PART: SHAFT BODY) (DRAWING NO: MG-125) (OPERATION: 1) (MATERIAL: C45) (RAW STOCK: DIA 60) (REVISION: B) (WARNING: USE TAILSTOCK) %
Comments show the operator the job identity and critical warnings; but on old controls memory may be limited, so they should be useful without being unnecessarily long.
3. Program Creation, Editing and Version Control
Program creation/editing is usually done in EDIT mode: new program, add/delete line, word search, change value, copy program. In deletion, watch the P–Q profile lines especially; if a line between N100–N180 used by G71 is deleted, the cycle profile breaks. Changing the active program while the machine runs automatically is very risky; adding/deleting/changing a line can make the machine behave unexpectedly. If needed: stop machining safely, retract the tool to a safe point, record the stopped line, edit in EDIT, check with surrounding lines, re-run the simulation, and restart from a suitable line in single block. Changing one number looks small (e.g. N120 X40.0) but can affect the G71 profile, the G70 finish and the next shoulder.
Version control: when a program changes, old and new versions must not mix. The revision is stated in the program ((REV B)) and in the shop records: what, who, when and which drawing revision changed (e.g. (REV B: GROOVE MOVED FROM Z-42.0 TO Z-44.0)). If there are many uncontrolled copies of the same part in memory (O1250, O1251, O9250…), which is current becomes unclear and the risk of wrong production arises. Program search is by O number; but not only the number — the part name, drawing no, operation, revision, raw size and tool list must also be checked. Binding the wrong program to the right part is one of the most dangerous human errors.
4. Inspecting the Program Before Running
After the program is called, a quick line-by-line technical check is done:
- Start: G20 or G21, is G40 written, G98/G99, G50 speed limit, correct work coordinate?
- Tool sections: do the T codes match the list, are S/F suitable, is the M03/M04 direction right, is coolant present, is the approach coordinate outside the raw stock?
- Profile and cycles: are P–Q lines present, does the profile match the drawing, are the G71 pass/finishing allowances right, are the G76 thread pitch/root diameter right, are groove/hole depths safe?
- Program end: is the tool retracted safely, coolant off, spindle stopped, M30 present?
xF0x9Fx93xB7 IMAGE AREA — Graphics/tool-path check screen and profile verification
Suggested alt text: “CNC lathe graphic tool path check”
5. Graphics, Single Block, Dry Run and Machine Lock
Most FANUC controls can show the tool path as graphics; you check whether the profile resembles the part, the approach side, the Z direction, the diameter order, the G02/G03 arc directions, the G71 profile and the program-end retract. But the chuck jaws, turret body, tool holder, long bar, tailstock and nozzle mostly do not appear at true size; even a correct graphic does not replace the physical collision check on the real machine (the tool-tip path can be right while the back of the holder hits the chuck).
Single block stops after each line; on new/changed programs, the active line, tool position, distance to the chuck, spindle direction and coolant are checked (single-block behaviour in cycles varies by control). Dry run runs the program at a different test speed; but the dry-run speed can exceed the programmed feed, so rapid must be low, single block on, the tool outside the part, and the operator ready on the E-stop — the idea that “if dry run is on there is no danger” is wrong. Machine lock advances the program while blocking axis motion; but when the lock is released, the program position and the real machine position can differ, so do not continue directly — re-match the positions safely.
6. Restarting Mid-Program and Stopping Mid-Cycle
When a program is interrupted, moving the cursor to a line and starting with cycle start is not safe; the modes activated in earlier lines (G96/G97, G98/G99, G54, G41/G42, tool number, spindle direction, coolant, speed limit, cycle parameters) may be missing. For example if a program is started straight from the G71 at N70, the tool may not be called, the spindle may not run and the speed limit may not be active. For a safe restart, the control’s restart function or the builder’s procedure is used.
Stopping mid-cycle: if the machine is stopped during G71/G72/G73/G74/G75/G76 and the tool is retracted by hand, the CNC may not account for that manual move when the cycle continues; after intervention, the absolute and incremental positions must be verified. Safe approach: feed hold, make the spindle/tool safe, record where it stopped, reset if needed, take the tool to a safe start, assess the air-cut chance and restart in single block. If a thread cycle is interrupted, do not continue from the middle of the same pass; take the tool to the start and restart from a suitable pass.
xF0x9Fx93xB7 IMAGE AREA — Alarm screen: alarm number, message and the stopped block
Suggested alt text: “CNC lathe alarm screen and alarm types”
7. CNC Alarms and Alarm Handling
An alarm is a message that the control has detected a condition preventing safe/correct operation; the screen shows the alarm type, number, description, program number and stopped block (e.g. 010 IMPROPER G-CODE / O1000 N00030 → an invalid G code at N30 of O1000). The first reaction should not be pressing RESET repeatedly. The right order: check the machine’s physical state (E-stop if there is danger), record the alarm number/message and stopped line, check the tool’s real position and any part/tool damage, identify the alarm source, fix the cause, then reset and restart from a safe point under control. Recording the number/photo before the message is cleared makes fault investigation easier.
| Alarm Type | Common Causes |
|---|---|
| Program | Invalid G code, two G codes from the same group, missing X/Z, wrong P/Q, impossible arc geometry, missing cycle parameter, decimal/address error |
| Servo | Axis overload, tool/turret crash, axis jam, motor/drive fault, encoder problem, excessive position error, stroke limit |
| Spindle | Excessive cutting load, too large a pass/high feed, part jam, drive/motor heat, chuck imbalance, encoder fault |
| Machine / PMC | Chuck not open/closed, low hydraulic pressure/oil level, tailstock position, door open, turret not locked, tool change incomplete, conveyor/coolant |
The alarm history is recorded with date/time and is very valuable for analysing intermittent/recurring faults (e.g. a turret alarm every time the same tool is called → check the station, turret lock, T code, tool overhang). Deleting the history does not solve the problem; the recurrence pattern is important technical information.
xF0x9Fx93xB7 IMAGE AREA — Data transfer: computer ↔ CNC (RS-232 / USB / network)
Suggested alt text: “CNC lathe program transfer RS-232 USB”
8. Program Transfer: Methods and RS-232C
Short programs can be typed on the panel; long programs are prepared on a computer and transferred, and programs in memory are backed up to a computer. Transfer methods: RS-232C/RS-422 serial, PCMCIA/CF memory card, USB, Ethernet/FTP, DNC software. RS-232 and memory cards are common on old FANUC controls; USB/Ethernet more common on new systems. The logic does not change: set source/target → match communication settings → check the format → transfer → verify what arrived → graphic/line check.
RS-232C transfers data serially (bit by bit) between computer and CNC. For a successful transfer, these settings must match on both sides:
| Setting | Description |
|---|---|
| Baud rate | Communication speed (300–19200; e.g. 4800). Both sides must match. On long cable/noise, a lower speed is more stable. |
| Data bits | 7 or 8 |
| Parity | Even / Odd / None (e.g. 7-E-2 or 8-N-1) |
| Stop bits | 1 or 2 |
| Flow control | XON/XOFF (software) or RTS/CTS (hardware) |
| Channel / encoding | I/O channel and ASCII encoding |
RS-232 cable: not every cable is the same (9/25 pin, null modem, hardware flow control); wrong wiring may prevent communication entirely. The cable should be shielded, well grounded, kept away from heavy motor cables and not unnecessarily long; use the builder’s wiring diagram to avoid port damage.
9. Sending/Receiving, Memory Card/USB and DNC
The transferred program must be in correct text format (start/end %, program number, EOB, ASCII). Since non-Latin characters can corrupt on old controls, plain letters are preferred in comments (CAP, DIS, ISLEME, FINIS).
% O1001 N10 G21 G40 G99 ; N20 T0101 ; N30 G97 S900 M03 ; N40 M30 ; %
Computer→CNC: match communication settings, check the cable, select the proper mode, check whether the same O number exists, ready the CNC to receive, start sending from the software, do not break the connection until done, then check the first/last lines and the graphic. CNC→Computer: ready the computer to receive, set a file name, select the program and start the output, open the resulting file in a text editor and check it. A meaningful file name: O1250_REV_B_2026-07-08.NC. Memory card/USB is usually easier, but the file system, name length, ASCII format and write protection are checked; do not remove the media before read/write finishes (data corrupts). DNC runs a long program line by line from the computer without saving it to memory; if communication drops the machine stops/alarms, so the computer must not sleep and the connection must be stable.
xF0x9Fx93xB7 IMAGE AREA — Tidy archive/folder structure and the program–production-file relationship
Suggested alt text: “CNC lathe program backup and archive structure”
10. Backup: Program, Offset, Parameter and Archive
CNC memory is not a permanent, infinitely safe archive; programs can be lost due to a dead memory battery, control fault, wrong deletion, parameter reset or service. So programs are backed up regularly to a computer/secure server. An offset backup (tool numbers, geometry offsets, nose radius/direction, work coordinates) serves as a reference to the previous setup and for recovery after data loss; but since geometry offsets depend on the tool’s real mounting, they must not be loaded to another machine/re-set tool without checking. A parameter backup is critical after service/battery change/memory reset but is taken and loaded only by authorised personnel; a wrong machine’s parameters ruin axis direction, stroke, turret and spindle settings.
CNC_PROGRAMS ├── PART_125 │ ├── DRAWING │ ├── OPERATION_1 │ │ ├── O1250_REV_A.NC │ │ └── O1250_REV_B.NC │ ├── OPERATION_2 │ │ └── O1251_REV_A.NC │ └── TOOL_LIST └── BACKUPS
With each program, the drawing, tool list, workholding drawing, soft-jaw size, work coordinate, cutting values, first-part measurement report and revision history are stored; thus the program stops being a meaningless code file and becomes part of the production file.
11. Post-Transfer Check and the Program Approval Process
Even if the program looks successfully transferred, it is not run directly: the O number, the opening comments, the first lines, the final M30, the minus signs, decimal points, parentheses, P–Q lines and the graphic shape are checked (a corrupt-character alarm can occur especially in serial transfer). The approval process has five stages: (1) Programmer check — coordinates vs. drawing, tools, cycle parameters, speeds/feeds; (2) Machine setup — clamping, work zero, offsets, tool directions, chuck/tailstock distances; (3) Simulation — graphics, dry run, single block; (4) First part — low rapid, intermediate measurement, rough size before finishing, thread/groove check; (5) Production approval — the first part is measured against the drawing, and the revision and starting offset values are recorded.
In series production the program is not constantly changed; normal changes are limited to small wear offsets and controlled optimisation. If the geometry will change, the reason is recorded, the revision is raised and the first part is re-approved. A dimensional error is fixed first with the wear offset, not the program coordinate (e.g. if Ø40 is 0.05 mm large, use the offset instead of changing X40.0 to X39.95, otherwise other surfaces machined by the same tool are spoiled). Fix the cause instead of hiding the alarm: constant reset grows the real fault; for a “low hydraulic pressure” alarm, check the sensor, oil level, pump, leak and filter — bridging the sensor or disabling a safety switch is not a fix.
12. Example Program-Check Scenario
% O4100 (SHAFT BODY REV C) G21 G40 G99 ; G50 S2500 ; T0101 ; G96 S180 M03 ; M08 ; G00 X62.0 Z2.0 ; G71 U2.0 R0.5 ; G71 P100 Q180 U0.4 W0.2 F0.28 ; N100 G00 X30.0 ; N110 G01 Z0 F0.12 ; N120 X36.0 Z-3.0 ; N130 Z-20.0 ; N140 X44.0 ; N150 Z-45.0 ; N160 X50.0 Z-55.0 ; N170 Z-70.0 ; N180 X56.0 ; G00 X100.0 Z100.0 ; M09 ; M05 ; M30 ; %
Before running: Identity — is O4100 the right program, is Rev C consistent with the drawing, is the raw Ø60? Mode — G21/G40/G99, G50 S2500. Tool — is T0101 really the OD roughing tool, is offset 01 right? Speed — is G96 S180 suitable for material/insert, is 2500 rpm safe for the chuck/part, is M03 the right direction? Approach — with raw Ø60, are X62 and Z2 safe? Cycle — is the first G71 U a radial 2 mm, are N100/N180 present, do the profile diameters grow, are U0.4/W0.2 suitable? Retract — are X100 Z100 safe for stroke and tailstock? After these checks, the program is run in graphics and the first part is machined in single block.
xF0x9Fx93xB7 IMAGE AREA — Reliable workflow (drawing → program → check → production → backup)
Suggested alt text: “CNC lathe reliable production workflow”
13. Managing Program, Machine and Production File Together
In professional production, three information groups are inseparable: the program (G/M codes, coordinates, cycles, speeds/feeds), the machine setup (tool offsets, work zero, chuck jaws, tailstock, machine-specific M codes) and the production document (drawing, tool list, workholding plan, control measurements, revision history). Moving only the program to another machine does not mean the same part will be produced automatically; on the new machine the turret structure, offsets, M codes, chuck, work zero, stroke and cycle format can differ, so the program is first adapted and re-verified.
Reliable production is a chain: drawing → machining/tool plan → CNC program → program check → data transfer → tool/part setup → graphics/simulation → first run in single block → first-part measurement → program approval → backup → series production. Skipping a stage lowers the reliability of the next: a correct but un-backed-up program means the work is redone on data loss; a correctly transferred but revision-unchecked program produces the wrong size; a graphic done but real-holder-unchecked run causes a crash.
A program is not just a text that is written and run: it is defined, archived, transferred, checked, run safely, monitored via alarms, revised when needed and backed up for reuse. A good programmer knows which version is in production; a good operator does not just reset an alarm but investigates its cause; a good shop does not leave programs in a single machine’s memory but archives them tidily with the drawing, tool list and revision info.
Common Mistakes in Program Management
- Binding the wrong program to the right part; not checking the drawing revision.
- Assuming the transfer is complete without checking the program end (M30/last tool section).
- Guessing the RS-232 settings (corrupt characters/missing lines).
- Thinking that if the graphic is right, the machine is safe too (holder/chuck jaws not shown).
- Resetting an alarm without reading it; continuing directly after a manual move mid-cycle.
- Mistaking parameters for offsets; deleting a program without a backup; not naming files.
Assessment Test
- Which should not be changed during normal part setup? A) Program B) Tool offset C) Parameters D) Comment line
- (True/False) Even if the graphic check looks right, it does not replace the physical collision check on the real machine.
- What should be done first when an alarm occurs? A) Keep pressing RESET B) Check the state, record the alarm and fix the cause C) Bypass the sensor D) Delete the program
- Which must match on both sides in RS-232 transfer? A) Only the cable colour B) Baud rate, data bits, parity, stop bits C) The program number D) The number of tools
- (True/False) Restarting a program mid-way by moving the cursor to a line and pressing cycle start is always safe.
- A Ø40 diameter comes out 0.05 mm large. What should be done first? A) Change the program coordinate B) Use the tool wear offset C) Change a parameter D) Reset the alarm
- Which statement about CNC memory is correct? A) It is an infinitely safe archive B) Data can be lost via battery/fault/deletion, so it must be backed up regularly C) It only holds programs D) No backup is needed
Show Answer Key
1) C – Parameters are not changed in normal setup (authorised personnel). 2) True – Graphics does not replace the physical check. 3) B – First check the state, record the alarm and fix the cause. 4) B – Baud/data/parity/stop must match on both sides. 5) False – It is unsafe due to missing modes; use the restart function. 6) B – First the wear offset. 7) B – Memory is not permanent; back it up.
Open-Ended Questions
- Explain the difference in risk between program, offset and parameter data.
- Explain the benefits and limits of the graphic check.
- What is the risk of restarting a program mid-way?
- Which settings must match in RS-232 transfer?
- Why is a program backed up, and which documents are kept with the backup?
Summary
In this lesson we saw that a CNC program does not end at being written; it must be defined, archived, transferred safely, checked, monitored via alarms and backed up. We learned the program/offset/parameter distinction, version control, graphics/single block/dry run/machine lock, alarm types and the handling order, data transfer with RS-232/USB/DNC, and the program approval process. A good programmer, besides writing code, knows which version is in production; a good operator investigates the cause of an alarm; a good shop archives programs tidily with the drawing, tool list and revision info.
Next and final lesson: we evaluate the produced part’s conformity in Lesson 9 — Measurement, Tolerances and Surface Quality.