Resolving Mazak Alarm 1101 During Work Zero Setting

James Nishida6 min read
Other ManufacturerOther TopicTroubleshooting
Licensed PE Working through this on a live machine? A Maine-licensed engineer can take it from here — included with IMD hardware, by the hour for everything else. Book an engineer

The Mazak Quick Turn 250MY reports 1101 while setting the work zero because the controller detects an interference relationship involving Part 1 and Tool 1. The first resolving branch is the controller's software collision barrier. Temporarily removing the planning process has also allowed zero setting, but recurrence on the same program the next day shows that deleting that process is not a durable correction.

Before anything else, confirm which software barriers, process data, tool records, and offsets are active. Do not bypass a physical guard or safety interlock. If a software collision barrier must be suspended for setup, keep the machine in the approved setup mode, restrict motion, and restore the barrier before automatic operation.

Initial Alarm and State Capture

  1. Load the affected program and select the same zero-setting operation that produces 1101.
  2. Record the displayed part and tool references, especially whether the alarm continues to name Part 1 and Tool 1.
  3. Record the selected turret station, active tool record, work offset, machine mode, planning-process status, and collision-barrier status.
  4. Repeat the zero-setting request once without changing a tool or offset. A repeatable alarm confirms a deterministic state conflict rather than an isolated operator entry.
Reading Meaning Next check
1101 changes with the selected tool The collision model is responding to tool-specific geometry or offsets. Inspect the selected tool record and barrier geometry.
Tool 1 remains named for every turret tool The program or planning data may still associate the operation with Tool 1. Check the planning-process and tool-assignment branch.
The alarm disappears with software barriers inactive A barrier boundary or modeled envelope blocks the zero-setting move. Correct the barrier data, then restore protection.
The alarm remains with barriers inactive The interference decision originates elsewhere in the program, process data, or tool model. Continue to the planning-process branch.

Software Collision-Barrier Branch

A software barrier prevents commanded or manually requested motion when the modeled tool envelope intersects a protected part, chuck, fixture, turret, or machine region. Zero setting can trigger the same calculation as cutting motion because the controller must validate the measuring position and approach path.

  1. Identify every controller collision or interference barrier active for the selected part and turret. Do not confuse these software zones with the machine's physical guard system.
  2. Compare the current tool position and intended zero-setting point with the displayed or configured protected region. Look for a boundary that encloses the intended touch point or its approach path.
  3. Under the machine builder's approved setup procedure, temporarily deactivate only the relevant software barrier.
  4. Request the work-zero operation again at controlled setup speed. Do not move on until either the zero-setting sequence starts without 1101 or the alarm repeats.
  5. If the alarm clears, restore the barrier and correct the modeled part, tool, stock, chuck, fixture, or clearance data that created the false overlap. Leaving collision checking disabled is not the fix.

Planning-Process Branch

Removing the planning process allowed the work zero to be set once. That result makes the process definition a useful isolation point: it may select a tool, generate an approach, or contribute geometry to the interference model. The later recurrence on the same program means the visible program alone does not account for every state used by the check.

  1. Preserve the affected program and create a controlled test copy.
  2. Run the zero-setting check with the planning process present and record the result.
  3. Remove or suppress only that process in the test copy, then repeat from the same machine position with the same selected tool and offset.
  4. If 1101 occurs only with the process present, inspect its tool assignment, part geometry, stock definition, approach direction, and clearance information. Read the actual values from the controller; do not substitute guessed dimensions.
  5. If the test copy also faults after previously working, continue to the tool and retained-state checks. Repeatedly deleting the process can hide the trigger without correcting it.

Tool, Offset, and Turret Branch

Trying every mounted turret tool without clearing the alarm makes damage or bad geometry in one physical tool less likely. It does not eliminate a shared offset problem, an incorrect active-tool association, or a planning record that continues to reference Tool 1.

  1. Confirm that the commanded turret station matches the station physically indexed into position.
  2. Confirm that the controller's active tool record changes when another turret tool is selected. If the display continues to identify Tool 1, trace the operation's tool assignment before changing geometry.
  3. Compare each relevant tool's measured length, orientation, tip position, and holder envelope with the physical assembly. A misplaced decimal, wrong sign, or oversized holder envelope can place the modeled tool inside a barrier.
  4. Check the active work offset against the intended setup. A displaced work coordinate can move the modeled part into the tool even while the physical machine appears clear.
  5. After correcting one discrepancy, repeat the same zero-setting request. Change one input at a time so the clearing action remains identifiable.

Retained-State and Next-Day Branch

The return of 1101 on a program that worked previously points to state outside the unchanged program text. Relevant state includes the active work offset, selected tool, process selection, regenerated planning data, and enabled collision barriers. A date change itself does not cause the alarm; compare the controller state at the successful attempt with the state at the failed attempt.

  1. After a successful test, record the active program, process selection, tool identity, turret station, work offset, and barrier state before leaving the machine.
  2. At the next failed attempt, compare those same readings before editing or reloading anything.
  3. If a value changed, restore the previously verified value and retest. The changed field is the lead diagnostic, but its source still needs correction.
  4. If all displayed values match, reload or regenerate the affected planning data using the controller's documented procedure, then repeat the barrier and tool-assignment checks.
  5. If the alarm persists, provide the machine manufacturer with the alarm screen, program copy, planning data, tool table, offset readings, barrier state, and the exact sequence that reproduces the fault.

Correction and Controlled Verification

  1. Place the machine in the approved setup condition and position the turret clear of the part, chuck, and fixtures.
  2. Select the intended program, work offset, and physical turret tool. Confirm that the displayed tool association follows the selection.
  3. Correct the identified planning assignment, tool geometry, work offset, or software-barrier boundary.
  4. Restore every software collision barrier required for normal operation.
  5. Run the zero-setting approach under controlled setup motion. Confirm that 1101 does not appear and that the resulting zero value matches an independent setup measurement.
  6. Repeat the zero-setting request after reloading the program. If retained state was part of the fault, repeat again after the machine's normal restart procedure.

FAQ

What happens if Mazak alarm 1101 clears when barriers are off?

The software collision model is blocking the zero-setting position or approach. Correct the modeled tool, part, chuck, fixture, clearance, or barrier boundary, then restore the barrier and retest.

What happens if removing the planning process clears alarm 1101?

Compare the process tool assignment, geometry, approach direction, and clearance data with the physical setup. Use a test copy for isolation; repeated process deletion does not correct the underlying state conflict.

What happens if every turret tool produces the same 1101 alarm?

Check whether the controller still reports Tool 1 regardless of the physical selection. A shared work offset, retained tool association, or common collision boundary is more likely than faults in every mounted tool.

What happens if alarm 1101 returns the next day?

Compare the active offset, tool identity, process selection, planning data, and barrier state with the last successful setup. Restore the verified configuration, reload the program, repeat the work-zero operation, and confirm that 1101 remains absent with collision protection active.

Back to blog