Galvo Laser Marking: Adding Arc Text to Legacy Systems

Problem Definition

A vintage (early-1990s) galvanometer laser marking system — a GSI Lumonics Lightwriter-class head driven from a 386-class PC running DOS — is lasing correctly after interlock repair and replacement of a failed G325 galvanometer. The blocking issue is not hardware; it is the vector generator in the bundled marking software.

The shipped software exposes only two text placement modes:

• Linear text at an X/Y offset from field center
• Linear text rotated at an angle about field center

The application is marking bearing rings — text must follow the circumference of the outer and inner race, i.e. each character sits on a circle of radius R and is individually rotated tangentially. Additional requirements, in priority order:

1. Mandatory: arc/radial text on a defined radius
2. Highly desirable: arbitrary X/Y offset of the arc center, so one V-block fixture serves every bearing size
3. Desirable: automatic serialization (incrementing part numbers/date codes)

Why the Legacy Software Cannot Produce Arc Text

DOS-era marking packages of this generation typically store a job as a short list of primitive records (text string, height, pitch, angle, offset) and expand them to vectors at mark time using a stroke font table. The transform applied is a single rigid-body operation on the whole string:

[x']   [ cos a  -sin a ][x]   [Xoff]
[y'] = [ sin a   cos a ][y] + [Yoff]

Arc text requires a per-character transform — each glyph gets its own rotation angle and its own translation onto the circle. That capability is not exposed and cannot be coaxed out of the primitive record set. Two routes exist: generate the per-character vectors outside the software and feed them in, or replace the vector generator (software, and possibly the scan controller board) entirely.

Arc Text Geometry You Must Generate

Whatever route you take, the underlying layout math is the same. Define:

Angular advance for each character, in radians:

d_theta_i = w_i / R          // arc length / radius
theta_i   = theta_0 + sum(d_theta_0 .. d_theta_i-1) + d_theta_i/2

Glyph origin on the circle, and the rotation applied to that glyph's local stroke coordinates:

X_i = Xc + R * cos(theta_i)
Y_i = Yc + R * sin(theta_i)
phi_i = theta_i - pi/2      // text reads upright, outward-facing
phi_i = theta_i + pi/2      // inverted, for text on the inside of a bore

// per-stroke point (u,v) in glyph space -> field coordinates
x = X_i + u*cos(phi_i) - v*sin(phi_i)
y = Y_i + u*sin(phi_i) + v*cos(phi_i)

Practical consequences:

• Total subtended angle = (sum of w_i) / R radians. On a small inner ring this grows fast — check it against the available flat land before committing the fixture.
• Character distortion: at small R/h ratios the top of the glyph is stretched relative to the baseline. Below roughly R < 5h the visual result degrades noticeably; reduce height or accept a shorter string.
• Centering: for text centered on a nominal angle θ_c, set θ_0 = θ_c - (sum w_i)/(2R).
• Inner-ring text is usually mirrored in rotation only (phi = theta + pi/2), not in glyph geometry — do not mirror the strokes or the text reads backwards.

Upgrade Paths, Ranked

For a production bearing-marking cell, Path 2 gives the best return: circular text, arbitrary X/Y offsets and automatic serialization are standard features of vector marking packages, and the optical head and galvos are retained.

Fixture, Offset and Field Calibration

The "one V-block for all bearings" goal is achievable only if the software offset origin and the fixture datum are tied together deterministically.

1. Establish the mechanical datum. A V-block locates a cylinder on its OD, so the part axis sits at a fixed height above the block seat but the axis height changes with OD: for a V-block of included angle 2α, the axis rises by r / sin(α) above the vertex, where r is the part radius. For a 90° block (α=45°), that is 1.414 × r. Build this into your offset table — it is the dominant source of the Y offset varying by part number.
2. Verify the horizontal datum. The V-block centers the part in X automatically; X offset should then be constant across part sizes. Confirm this with a marked test ring rather than assuming it.
3. Prove the field scale. Mark a known square or a pair of crosses at a fixed spacing on anodized coupon stock, measure with calipers or an optical comparator, and correct the software's field-size/scale factor. Scale error shows up as radius error, so an uncorrected field makes arc text miss the land.
4. Check pincushion/barrel correction. Galvo fields are inherently distorted; the correction is usually a lookup table or coefficient in the controller. Mark a full-field grid and measure corner-to-center deviation. Arc text placed off-center is far more sensitive to this than centered linear text.
5. Re-verify after the galvo swap. A replacement G325 will not have identical gain, offset and scale to the failed unit. Confirm zero position and full-scale deflection on both axes before trusting any stored calibration — an axis scale mismatch turns a circle into an ellipse and is the classic post-repair symptom.
6. Build a part-number offset table (part no., Xc, Yc, R, θ_0, character height) and recall it by job file. Do not let operators type offsets from memory.

Serialization

Automatic serialization is a software feature, not a hardware one. When evaluating a replacement package, confirm specifically:

• Persistent counter storage that survives power loss and job reload — a counter held only in RAM will repeat serials after a crash.
• Configurable increment, start value, roll-over limit and zero padding.
• Date/shift code fields with a defined roll-over time.
• Whether the serial field can live on the arc path (some packages support counters only in linear text objects). Test this before purchase.
• An external trigger or host-command interface if the counter must advance from a PLC or part-present sensor rather than a keystroke.

Commissioning Verification

FAQ