How Do You Check Okuma Dry Run Status in a Program?

A machine crashes after dry run is left active, even though the CNC program itself has not changed. Prevent the recurrence by reading the control’s logical I/O state at program start and stopping execution when the dry-run indication is active. The exact VORD operand is machine- and control-specific, so commissioning starts at the I/O monitor rather than with a copied address.

Safe commissioning state

1. Place the machine in a non-cutting test condition and remove any setup in which unexpected axis motion could contact the chuck, fixture, stock, or tooling.
2. Set the feed-rate control to zero and enable single block before testing the panel-state logic. Do not move on until cycle start cannot produce an uncontrolled sequence.
3. Toggle dry run manually and confirm that its panel indication changes normally. The diagnostic task is to find the logical signal representing that persistent state.
4. Record the control family and the machine on which the address was measured. Treat the result as a machine-local configuration value.

Dry run changes how motion feed is governed during prove-out. On controls where single-block operation separates feed and rapid override behavior, a feed override alone does not provide equivalent control over every motion. Use the operating sequence: feed-rate control to zero, single block on, dry run on, prove each block, then dry run off. The program check backs up that procedure; it does not replace it.

Control and addressing branch

Before anything else, confirm which operand format the control accepts. The controls discussed here support logical I/O interrogation, but their maps and accepted labels differ.

VIRD addresses inputs and VORD addresses outputs on P controls. For a maintained operating mode, the output that drives the dry-run indication can be the useful state because it remains active after the push button is released. Confirm this behavior by watching the value through both transitions.

Use logical—not physical—I/O information. A numeric operand combines the logical address and bit. For example, VORD[0031] represents logical address 003, bit 1. A documented panel example uses VORD[001E] for dry run, where 001 is the address and E is the displayed hexadecimal bit identifier. This different dry-run operand is direct proof that one machine’s value must not be treated as universal.

Live dry-run bit identification

1. Open the control’s I/O or Check Data monitor and select the panel-related pages.
2. With dry run off, record the displayed input and output bit states.
3. Press dry run once. Page through the monitor until a labeled bit changes and remains in its new state after the button is released.
4. Press dry run again. Confirm that the same bit returns to its original state. Ignore bits that only pulse while the button is physically pressed if the objective is to detect the maintained mode.
5. Record the Check Data address, the individual bit, its off value, and its on value. Do not move on until both transitions have been repeated.

On the P300 display, two 16-bit groups can be presented as input and output columns with bits 0 through F. The hexadecimal value at the bottom summarizes a group’s state, but the program operand comes from the Check Data number plus the selected bit. Avoid inferring the bit order from the combined hexadecimal value; toggle the function and use the highlighted bit position.

The SS heading helps locate a page group; it is not the final VORD operand. Where an output is displayed with an address in the output range, the P-control convention may require subtracting 512 before constructing the VORD index. One example converts output address 518, bit 7, to VORD[00067]. Validate the resulting operand against the live monitor instead of relying on the arithmetic alone.

Polarity and syntax validation

Read the candidate operand from a small test subprogram before adding a production interlock. Determine polarity from observed state, not from the signal name.

On the LT200-MY/P200 example, normal execution continued when VORD[0015] EQ 0; any other value generated the DRY RUN ON message. Another panel-check example treated VORD[001E] EQ 1 as dry run on. These are separate machine mappings, not interchangeable alternatives.

A 7000 test required a space between EQ and 1. Use:

IF [VORD[ABCD] EQ 1] GOTO Nxxxx

If program space is constrained, the branch can name the sequence label directly; the literal GOTO is unnecessary in the established syntax:

IF[VORD[001E]EQ 1]NALRM

Dry-run enforcement response

Once polarity is proven, choose a response that prevents automatic motion rather than merely displaying advisory text. The P200 routine used an operator message followed by a selected alarm output:

IF[VORD[0015]EQ 0]NCK0
VUACM[1]='DRY RUN ON'
VDOUT[992]=1
NCK0

In this mapping, the branch reaches NCK0 only when dry run is off. When dry run is on, the routine writes the warning and activates VDOUT[992]. Test the alarm behavior on the target control and confirm that program execution cannot pass the check without operator action.

A separate panel-check pattern used a common alarm branch:

OINCK
IF[VORD[0005]EQ 1]NALRM
IF[VORD[0006]EQ 1]NALRM
IF[VORD[0007]EQ 1]NALRM
IF[VORD[001E]EQ 1]NALRM
GOTO NILED
NALRM
VUACM[1]='ILLEGAL FUNCTION'
VDOUT[993]=1
NILED
RTS

The first three operands in that example check X-, Y-, and Z-axis mirror states; the fourth checks dry run. Retain only checks whose addresses and polarity have been proven on the target machine. A guessed symbolic variable such as VNDRYR is not a substitute for a verified logical I/O operand.

Restart and companion-state checks

Dry run is one branch of the start-state decision. The LT200-MY/P200 routine also checked machine lock, block delete, spindle override, coolant state, load monitor, individual modes, system link, feed-rate state, and single block. Each additional check needs its own monitor test and polarity record.

The sample returned immediately when VORD[0016] EQ 1, identified there as machine lock on. Decide deliberately whether machine lock should bypass the remaining checks in the local operating procedure. Do not inherit that bypass without testing its consequence.

Restart handling used VRSTT to select a different decision path. During restart, it required the sum of VIRD[0030], VIRD[0031], and VIRD[0032] to equal zero for the accepted feed-rate condition, and required VORD[0013] EQ 1 for single block. Outside restart, the P200 routine checked its normal feed-rate and panel states. This separation prevents a restart-only setup—feed control at zero and single block on—from becoming the normal production requirement.

Machine-local installation and final verification

1. Create one machine-local panel-check subprogram and give equivalent routines the same callable name across machines. Keep the verified address map inside each machine so transferred part programs call the correct local implementation.
2. For the LT200-MY/P200 arrangement, the A-side program called OCHKA, the B-side called OCHKB, and OCHK1 was the alternative without a bar feeder. A file named like LT200MY-P200.SSB could be stored for loading at control boot. Confirm the local boot-loading method before depending on automatic availability.
3. Place the call before motion that relies on the checked operating state. Verify that every applicable program path executes it.
4. With dry run off, run the check in single block and confirm that it returns normally.
5. Turn dry run on, rerun the check, and confirm the exact warning appears and execution stops at the intended alarm branch.
6. Turn dry run off without editing the program. Confirm that the same call now passes, proving that the decision follows live I/O rather than a stale variable.
7. Repeat the on/off test after a control restart and after loading a transferred part program. The full LT200-MY/P200 panel routine was reported to take about 0.5 second; measure the actual target-machine delay if cycle-start latency matters.

FAQ