Okuma Alarms & Parameters

When an Okuma OSP control has a problem, it tells you on the alarm display: an alarm number, a severity letter, a message, and usually an alphanumeric code that means more to a service tech than to you. On the Windows-based OSP-P300/P500 generation the alarm screen is one panel of a full Windows environment (which also means logs and files are reachable like files on a PC), but the alarm system itself behaves the same as on older OSPs. The key distinction to internalize first: an alarm stops something — the question is how much — while a warning or operational message just tells you something, and the severity letter is how OSP encodes that difference.

One accuracy note up front: specific alarm numbers and their exact texts shift between OSP generations (P200, P300, P500) and between mill and lathe packages, so this article works in categories and levels — the part that is stable — and leaves number lookup to the alarm list manual for your control.

Alarm Levels: A, B, C, D

An OSP alarm entry has four parts: the alarm number (your lookup key in the alarm list manual), the severity letter, the message text, and often a trailing alphanumeric code that narrows the cause within that alarm number — write the code down before clearing anything, because service will ask for it. OSP's most useful habit is that severity letter: it alone tells you what just stopped and what you're allowed to do next, before you've read a word of the message. Read the letter first, every time.

Level	What stops	What the operator can do
Alarm A	Everything — the control shuts the machine down hard. Axis movement, spindle, and automatic operation all stop; the control state itself may be compromised.	Usually cannot be cleared with the reset key alone — expect a control power cycle after fixing the cause. If it recurs on power-up, it's a service call, not an operator fix.
Alarm B	The running cycle. Automatic operation stops; the machine itself is intact.	Fix the cause (or correct the program), press reset, restart the cycle. This is the level most day-to-day alarms live at.
Alarm C	Operation stops at a safe point (end of the block/cycle) rather than instantly — the control is objecting, not panicking.	Often clearable directly; treat it as a strongly worded warning. Find out why it fired before running the next part.
Alarm D	Nothing — an operational message. Wrong mode selected, an interlock condition, a required input missing.	Read it and do what it says. These usually clear themselves when you perform the correct operation.

Where the common alarm categories tend to land, and what each one is really telling you:

Category	Typical level	What it means / first checks
Axis / servo	A or B	Following error, overload, overtravel, encoder or drive faults. At level A the drive dropped out — check for a crash, binding, or a cable before power-cycling. A soft-overtravel alarm is friendlier: jog off the limit and reset.
Spindle	A or B	Spindle drive overload/overheat, speed deviation, orientation failure. Speed-arrival and orientation problems often surface mid-cycle as B; a dead drive is an A. Check load history and the belt/gear range before blaming the drive.
ATC / tool change	B	Magazine position, arm sequence, tool clamp/unclamp confirmation not received. Almost always a sequence stopped mid-motion waiting on a switch — recover the ATC to home per the machine builder's procedure before resetting, or you'll fire it again.
Program error	B (sometimes C)	Bad word, undefined variable, impossible arc, missing subprogram, option not installed for the command used. The cursor typically parks on or near the offending block — the fix is in the editor, not the machine.
Macro-raised	B or C	Raised deliberately by a user task/macro (a probing package flagging a broken stylus or out-of-tolerance part is the classic case). The number and text come from whoever wrote the macro — look in the macro package's documentation, not Okuma's alarm list.

Raising Alarms from a Program

OSP does have a facility for user tasks and macro packages to raise genuine alarms — that's what the "macro-raised" category above is — and probe packages use it together with the VDIN/VDOUT data input/output functions that talk to the machine side. But the exact syntax and index assignments are version- and builder-specific, so check the OSP programming manual for your control rather than copying an incantation from the internet. What you can do portably today is a deliberate stop with a message, which covers most of what a homegrown macro actually needs:

( TOLERANCE GATE - MEASURED VALUE ARRIVED IN VC50 )
( FROM THE PROBING ROUTINE THAT RAN BEFORE THIS )
VC51=ABS[VC50-2.500]         ( DEVIATION FROM NOMINAL )
IF [VC51 LE 0.002] N100      ( IN TOLERANCE - CARRY ON )
VC60=VC50                    ( PARK THE EVIDENCE IN COMMON VARIABLES: )
VC61=VC51                    ( VC SURVIVES RESET AND EVEN POWER-OFF, )
( SO THE READING IS STILL THERE AFTERWARD )
M00 (SIZE OUT OF TOL - CHECK VC60 VC61)
N100 ( GOOD PART - CONTINUE )

Two details make this pattern work. First, M00 halts the cycle unconditionally and the operator sees your comment text — a poor man's alarm, but one that behaves identically on every OSP. Second, the parking variables are VC on purpose: per Okuma Variable Types, VS system variables reset to null when the program ends, while VC common variables keep their value through reset and power-off. If the operator resets out of your stop — or the alarm you were diagnosing kills the program — the measured value and deviation are still sitting in VC60/VC61 on the variable display. That "park the evidence before stopping" habit is the single most useful thing a diagnostic macro can do on this control.

The other half of alarm-handling in a program is not causing them in the first place. A subprogram called with a missing argument fails as a program-error alarm at whatever block first touches the undefined value — usually somewhere confusing. OSP's own guard mechanism, documented in Okuma Argument & Local Variables, is the P-prefixed local variable and the EMPTY check: an optional argument named PA12 can be interrogated before use, so the failure happens on your terms, at the top of the subprogram, with a message that names the actual problem:

( SUBPROGRAM ENTRY - VALIDATE BEFORE TOUCHING METAL )
OGATE
IF [PA12 EQ EMPTY] N900      ( REQUIRED ARGUMENT MISSING? )
IF [PA12 LE 0] N900          ( OR NONSENSE VALUE? )
( ... REAL WORK USES PA12 SAFELY FROM HERE ... )
RTS
N900 M00 (OGATE - PA12 MISSING OR INVALID)
RTS

Five lines of guard turns a cryptic mid-cycle program alarm into a clean stop at the first block of the subprogram — the OSP equivalent of the input-validation habit good macro programmers carry across every control.

Parameters on OSP

OSP splits its parameters by audience rather than lumping everything into one numbered list. The names below are standard OSP vocabulary; all of them live under the control's parameter mode, organized into their own screens.

Family	Who touches it	What lives there
NC parameters	Service / machine builder	The control's fundamental configuration: axis setup, servo data, spindle configuration. Programmers read these to answer "why does the machine behave this way"; changing them is a service activity.
Machine / user parameters	Programmers and setup people	Behavior you legitimately tune: soft limits and barriers, cycle behavior, default modes, I/O settings. This is where most "can we make it do X instead" questions get answered.
Optional parameters (bit)	Programmers, carefully	Individual on/off switches — each parameter word is a row of bits, each bit toggling one behavior (message handling, cycle details, format acceptance). The alarm list and programming manual reference these constantly ("valid when optional parameter bit n is set").
Optional parameters (word)	Programmers, carefully	Numeric values rather than switches — counts, times, distances that feed optional behaviors.

All of these are edited the same way mechanically: put the control in parameter mode, navigate to the family's screen, and change the value — there is no magic beyond knowing which family your setting lives in, and the manual names the family whenever it references a parameter. What varies machine to machine is protection: builders commonly lock parameter writing behind a key switch or protection setting, so "I can see it but not change it" usually means a protection level, not a broken control.

Two classic gotchas. Some parameter changes only take effect after a control restart — if you changed a parameter and the behavior didn't change, don't conclude it was the wrong parameter until you've power-cycled. And options are real on OSP: a whole family of features (and their parameters, and the program words that use them) exist only if the option was purchased. A program error alarm on a command that "works fine on the other machine" is very often an option-lock, not a typo — the alarm text usually says so once you know to look for it.

Diagnostics

Beyond the live alarm display, OSP gives you a handful of tools worth knowing before the bad day arrives:

Tool	What it shows	When it earns its keep
Alarm history	Time-stamped record of past alarms	Reconstructing an unattended failure; separating cause from fallout
Servo / spindle load displays	Live axis and spindle load	Catching mechanical drift early; sanity-checking a suspect drive against a baseline
Windows file access (P300/P500)	Logs and machine data as ordinary files	Getting history off the machine for the distributor or service
Variable display	Current VC/VS/local values	Reading what a macro parked before anyone resets

Alarm history. The control keeps a time-stamped record of past alarms. This is the difference between "the machine alarmed out overnight" and knowing that a level-C spindle-load warning preceded the level-A servo alarm by twenty minutes. Sequence is diagnosis: the first alarm in a cluster is the cause; the rest are consequences.

Load displays. Servo and spindle load are displayed live on the control. A slowly climbing axis load at idle is a mechanical problem (way lube, binding, a chip-packed cover) announcing itself weeks before it becomes an alarm. Glance at these during a known-good cycle so you have a baseline to compare against.

The Windows side (P300/P500). On the Windows-based generation the OSP application runs alongside ordinary file access, so alarm history and machine data can be gotten off the control as files — which is exactly what you want when a distributor asks "send me the alarm history." How much of the Windows environment is exposed varies with how the builder locked down the panel.

From inside a program, the same visibility comes through the named system variables documented in Okuma Variable Types: VSPS reads the actual spindle speed (read-only), and the offset tables are readable and writable through VZOFX[n]/VZOFY[n]/VZOFZ[n] (work offsets) and VTOFH[n]/VTOFD[n] (tool offsets). A macro that logs VSPS into a VC variable at the moment it decides to stop has captured a piece of machine state that no amount of after-the-fact screen reading will recover.

A Debugging Workflow

Step	Do this
1	Read the severity letter before the message. A = machine problem, plan on a power cycle. B = fix and rerun. C/D = the machine is fine; something wants attention.
2	Open the alarm history and find the first alarm in the cluster — that's the cause. Everything time-stamped after it is fallout.
3	If a macro or probe package is in play, read the variable display before anyone resets: the `VC` values it parked are still there; `VS` values are already gone.
4	If the pattern is mechanical (repeating servo/spindle alarms, no program change), compare live servo/spindle load against your known-good baseline.
5	Only now open the alarm list manual — you know the number, the level, and the question you're asking it.

The order matters more than it looks. The letter comes first because an A-level alarm makes every program-side question moot — stop troubleshooting the G-code and start troubleshooting the machine. History comes before variables because the sequence tells you which macro or motion to interrogate: the level-B ATC alarm that followed a level-D "tool clamp confirmation" message is telling you about a switch, not the ATC. Variables come before anyone touches reset because parked VC values are the flight recorder and VS values are already gone. And the manual comes last on purpose — not because it's unimportant, but because by then you know which number to look up and what question you're asking it.

References

Okuma, OSP Operation Manual, Okuma Corporation.
Okuma, OSP Alarm List Manual, Okuma Corporation.
Okuma, OSP Programming Manual, Okuma Corporation.