PLC Signals in Macros

A part program normally runs blind. It was written, or generated, before the machine was loaded, so it assumes the setup it was written for. If only one of two fixtures is loaded today, a program that assumes both will drill into empty air.

Macro interface inputs close that gap. The PLC publishes a word of signals that the running program can read and branch on, so the program adapts to what the machine senses at the moment it starts rather than to what was true when someone selected it.

Reading the signals

The signals appear to the program as numbered variables it can read:

Variable	Reads
#1000 … #1031	one signal each, 0 or 1
#1032	all 32 at once, as a number

(Which fixtures are loaded right now?)
#30 = 0
IF [#1000 EQ 1] THEN #30 = #30 + 1
IF [#1001 EQ 1] THEN #30 = #30 + 2
IF [#30 EQ 0] GOTO 9890

They are read-only. A program that assigns to one is rejected rather than silently ignored. The signals are the PLC’s statement about the machine, and a part program that could overwrite them could lie to itself.

They are also never vacant. A signal always reads 0 or 1, so IF [#1000 EQ 1] means what it looks like it means, on the very first block of a program, with no initialization dance.

What the machine builder does

The signals carry no meaning of their own. Which physical condition lands on which bit is decided by the machine builder in the PLC program: a fixture sensor on bit 0, a latched door on bit 1, an air-pressure switch on bit 2. It is documented in the macro that reads them. The control transports the bits and interprets none of them.

The word is published on the same cycle boundary as live axis positions, so what a program reads is the machine’s current state, not a stale snapshot.

The direction that was missing

The PLC already had a rich channel into the CNC: feed hold, overrides, single block, dry run, block delete, machine lock, spindle-at-speed. Every one of those modulates how a program runs: they act on the interpreter and the kernel.

None of them let the PLC say something to the program itself. That is a different thing: not “slow this down” but “there is no part in fixture 2.” Only the program can act on that, because only the program knows which of its remaining blocks would have gone there.

PLC ──── feed hold, overrides, dry run ────▶ interpreter / kernel   (how it runs)
    └─── macro interface inputs ──────────▶ part program           (what it does)

Latch it, don’t poll it

The signals are live. That is the point at the top of a program, and a hazard everywhere after it.

The discipline is to read them once, in the program’s setup macro, validate them, and latch the result into a variable that the rest of the program reads:

(setup macro - reads the live bits once)
#401 = #30

(every hole macro reads the LATCHED value, never #1000)
IF [#401 EQ 2] GOTO 200

Without the latch, an operator opening a fixture door halfway through a job would change where the job’s remaining holes go. With it, the job that started is the job that finishes, and the next job re-reads the machine.

Latch into a volatile variable, not a persistent one. Which fixtures are loaded is job state; it must not survive a power cycle and come back to authorize a run against an empty machine.

Where to go next

• Cycle Programming: authoring a part as a table of holes instead of a toolpath.
• PLC & Structured Text: the side that publishes them.