Engineering specifications
The published operating envelope: materials, mark types, speeds, symbol grades and the source selection matrix that decides which wavelength the application calls for.
Integration architecture
The record already exists. The Control Layer reads it, marks the part, and writes the proof back against the job.
Your ERP or MES keeps the job, the batch and the serial. Your control system knows which physical part is at the head right now. The Light Lane Control Layer sits between them: it reads the PLC tag that identifies the part, pulls the job data from the system that already owns it, composes a fresh mark for that individual part, fires it while the part is moving, and writes the completion back against the job with timestamp, operator, machine and station. Three systems agree inside milliseconds, and the plant never gets a second database to maintain.
- Reads NetSuite, Infor M3, Microsoft Dynamics 365, SAP, Cin7, Unleashed and Fishbowl, alongside the WMS, TMS, CMMS, calibration management and yard management systems sitting beside them
- Connects through defined patterns, REST or SOAP, a read-only database view, a watched file drop, a message queue, an OPC UA or Modbus TCP tag read, and sanctioned middleware, each with a stated authentication model and a stated failure edge
- Outbound only over TLS, least-privilege credentials you issue and revoke, and read access to the agreed PLC tags only
The layer between the plant's systems and the beam
Marking control is the layer between a plant's control and business systems and the marking source. It decides what each individual part's mark says, fires it inside the window that part gives you, and writes the record back. Marking control stands to laser sources exactly as motion control stands to motors: the hardware underneath is bought, the intelligence above it is engineered, and the value moves upward.
That layer stayed open because of how the market around it is built. Laser manufacturers sell a head with its own controller into a distribution channel, so integration arrives as the buyer's problem by design. A global channel selling one coder into forty countries has no path into your Infor M3 instance. ERP and MES vendors own the record and will never drive a galvo. So plants key codes into a laser by hand, or run a second database that starts drifting from the first on day one.
On a production line the control system already knows what is coming. A part reaches the marking station and the PLC has already told the rest of the line what part it is, what run it belongs to, and often what shift and pack it is destined for. The Control Layer reads that tag directly, pulls the job, batch or serial from the system that already owns it, and composes a fresh mark for the part in front of the head: a fixed logo, fixed standards or regulatory text, and the fields that change part to part, date, time, shift, run number, pack size, and a machine readable code generated to ISO/IEC 16022 that ties the part back to its record.
Then it drives the galvo head to fire the mark while the part is still moving. A typical timber brand on a single galvo head holds across roughly 40 to 120 m/min. A full height dense brand, around 40 mm high and up to roughly 600 mm long, tops out around 75 to 85 m/min on one head, because the ceiling is how much stroke length one scanning mirror pair can draw in the time the part spends in its field of view, so above that the specification is a second head sharing the mark on the same encoder. Published figures are typical envelopes from our own testing, and the binding number is the one written into the acceptance criteria after the capability study on your own material.
Two copies of an identifier become two answers
Every plant already runs a system that owns production truth: an ERP such as NetSuite, Infor M3, Microsoft Dynamics 365 or SAP, an inventory and order system such as Cin7, Unleashed or Fishbowl, or an MES sitting over the top of one of those. The Control Layer reads that system and writes back to it, so identity lives in exactly one place and stays there.
That is an architectural decision, and it is the reason a rollout is still trusted in month four. Identity maintained in two places drifts. A batch number corrected in the ERP after a late change never reaches the marking station. A manual override on the floor never gets logged back. Within a few months the record is trusted less than the paper log it replaced, and it gets quietly worked around. Reading from the system of record rather than duplicating it is what keeps the record trustworthy after the commissioning team has gone home, and on a multi-site programme that constraint is set once for the group rather than negotiated site by site.
What the Control Layer owns is narrower and more useful: the PLC read, the mark composition, the fire, and the write back. The definition of a job, a batch or a serial number stays where it was set, and the access requested against it is a read of the named fields plus a write to the single field that carries mark confirmation. Everything else the interface could have asked for is left out of the specification on purpose.
The data round trip, on every part
This is the loop that runs whichever ERP or MES sits behind it. Nothing is pre-rendered and nothing is stored twice.
- Step 1
Your system issues the identifier
The job, batch or serial is created where it always has been, in your ERP or MES. That system stays the record of truth and keeps ownership of what the identifier means.
Why it matters: The record already exists. The mark carries the code your own system generated, so there is nothing to reconcile and no second database to maintain.
- Step 2
The Control Layer pulls the job
Job, part, batch, serial and order data are taken from the system that already owns them, through the connection pattern your IT team sanctions, and pulled ahead of the parts rather than called per part.
Why it matters: Pull-ahead is what keeps a maintenance window on a business system off a physical line. Cache depth and hold duration are sized against your run length and line rate at the specification stage.
- Step 3
The PLC tag confirms the part at the head
The control system signal identifies the physical part now in position, so the record that was pulled and the part in front of the beam are matched before anything fires. The posture is read only: the agreed tags and nothing else.
Why it matters: A record matched to the wrong part is a false code on a real part, and it scans perfectly for years.
- Step 4
The mark is composed for that part
A fresh mark is built against that part's grade and dimension: fixed logo, standards text, the variable date, time, shift, run and pack fields, and a machine readable code. Data Matrix is generated to ISO/IEC 16022, graded to ISO/IEC 15415, and linear symbologies to ISO/IEC 15416, with the accept threshold set against the scanner class your operation actually carries.
Why it matters: A new product family is a parameter set rather than a rebuild, because the mark is composed at the head rather than rendered in advance.
- Step 5
The mark fires inside the window the part gives you
An encoder tracks the part and the mark geometry is compensated for line velocity, then the scanning mirror pair draws the whole mark in the time the part spends in the field of view.
Why it matters: A shape drawn onto a surface moving under the beam comes out true rather than sheared, and the compensation runs against the encoder the line already has rather than an assumed constant speed.
- Step 6
The completion is written back against the job
A completion record carrying timestamp, operator, machine and station is written back to your system. Write access is scoped to the single field that carries mark confirmation, issued and revocable by you.
Why it matters: The job record closes itself, and nobody re-keys a completion by hand at the end of a shift.
The connection patterns, each with its authentication model and its failure edge
This is the table an IT lead came here for. The pattern is chosen with your team against what your environment already runs and what they will sanction, then written into the interface specification before anything is built, because the pattern sets the authentication model, the latency and the edge the design has to hold.
| Pattern | What it takes from your side | Authentication and transport | The edge it is engineered against |
|---|---|---|---|
| REST or SOAP API against your endpoint | An endpoint reachable from the marking station segment, credentials issued through your own process, the fields carrying the job, batch or serial named by whoever owns the data model, and the request ceiling stated in writing where one applies. | API key or OAuth client credentials, issued by you and revocable by you, TLS in transit. The connection runs outbound from the station to your endpoint, so integrating a marking line requires no inbound path into the plant. | Round trip time against the gap between parts. Where a call takes longer than that gap, the station pulls ahead in blocks rather than calling per part, and the block depth is sized against your run length and line rate at the specification stage. A cloud endpoint puts the pull behind a WAN link, which is why the station caches at all. |
| Read-only database view | A view rather than raw tables, exposing the agreed columns only, and a service account restricted to that view. Your DBA owns both and revokes both. | Least-privilege service account authenticated to your standard, TLS where the database is configured for it. Read only, always: a write back is never made through the database. | A schema change underneath the view. The station fails the pull rather than composing a mark from columns it no longer understands, and schema notice is a named row in the ownership table below. A view carries no event either, so the station polls on an agreed interval and that interval sets how fresh the data is. |
| Watched file drop, CSV, XML or JSON | A folder or share your system already writes to, write access for your system and read access for the station, and an agreed naming and completion convention so a half written file is never read. | A service account on the share with rights to that one folder. The traffic stays inside your network and nothing leaves the plant. | Latency. A file that lands once a shift carries the fields that change once a shift, so per-part fields come from a live path or from the PLC tag read. The station validates every file before it composes from it, and holds the part where validation fails. |
| Message queue | A queue or topic your integration team already runs, a durable subscription for the station, and an agreed answer for a message the station holds. | Whatever the broker enforces, usually a client certificate or a scoped credential, with TLS in transit. The station subscribes rather than polls, so it sees the record as it is published. | Ordering and replay, agreed in the interface specification, because a message that lands after the part has passed the head has nothing to mark. The pattern is specified where a broker is already load bearing in the plant. |
| OPC UA or Modbus TCP tag read from the PLC | The tags or registers that identify the part at the head, confirmed by whoever maintains the PLC program, and a read-only account or a read-only register map. | OPC UA runs certificate-based security where the controller carries it. Modbus TCP carries no authentication of its own, so it is scoped to a network segment agreed with your control engineer. Read only either way: ladder logic and function blocks are left untouched, and any write is separately scoped and signed off before it exists. | It carries what the control system holds, which is the identity of the part at the head rather than what the business system says that part should say. So it is specified alongside one of the paths above rather than instead of one, and it is the pattern that makes composition per part possible at all. |
| Middleware already sanctioned in the plant | A connection your integration team builds or approves on their own platform, and a defined contract for what it hands the station. | Set by the platform and by whoever administers it. The Control Layer integrates on their terms, with the same field map and the same failure clauses written into the interface specification. On SAP this is the usual path: whatever your Basis team sanctions, and approval takes longer than the build. | It adds a hop and a second owner, so the escalation ladder names who holds the hop and at what hour. Specified where the platform is already load bearing for the plant rather than stood up for one line. |
One written interface specification per connection, at a version number
The interface specification is the deliverable
Every connection is written down before it is built: the fields, the direction, the format, the transport, the authentication model, what each side does when the other is unavailable, the test data, the deployment and the rollback. A heavily customised SAP instance and an out-of-the-box Unleashed account are different builds against the same architecture, and the specification is where that difference is stated rather than discovered.
- Field map: every field on the proposed mark traced back to the system that holds it and the moment it is created, so a field that lives on a whiteboard is found in discovery rather than in build
- Direction and ownership: what the station reads, what it writes, and the single field that carries mark confirmation
- Transport and authentication: the pattern, the credential type, the certificate posture, and the network segment the connection runs on
- Behaviour when the other side is unavailable, clause by clause, matching the failure architecture below
- Test data: representative jobs, batches and serials from your sandbox where one exists, run through the interface before it goes near a live part
- Deployment and rollback, executed under your change control, with a named owner on each side
- Identifier standards: Data Matrix to ISO/IEC 16022, symbol quality graded to ISO/IEC 15415 and linear symbologies to ISO/IEC 15416, accepted at the grade your scanner class supports
- A version number and a changelog, so a change to the interface is a change to a document rather than a surprise on a line
Failure architecture: what the Control Layer does when a system underneath it moves
A system that works is the easy half. Whether a plant trusts it is decided on the shift when the network drops, a schema changes or two PLC signals disagree. Every behaviour below is written into the interface specification before the build starts, and the numbers behind them, how many parts the station pulls ahead and how long it holds them, are sized against your run length and your line rate at the same stage and written into the acceptance criteria. A record-keeping problem is never allowed to become a production problem.
| Event on the line | What the Control Layer does | What the line does | What you hold afterwards |
|---|---|---|---|
| The ERP or MES is unreachable at mark time, through a WAN drop or a scheduled maintenance window | Keeps marking from the pull-ahead cache. The cache is filled ahead of the parts rather than on demand, precisely so this shift survives. | Runs. The depth it covers is the pull-ahead figure agreed at the specification, which is why it is a number rather than an assumption. | Completion records queued locally and replayed in order once the link returns, each carrying the original mark timestamp rather than the time of the write, so the replayed record dates the mark and not the reconnection. |
| The cache runs dry while the upstream system is still away | Stops issuing marks rather than composing from stale data. It never invents an identifier, never substitutes a default, never writes a placeholder and never increments a serial itself. | Follows the rule you set at the specification: hold at the station, or pass unmarked and divert to a defined recheck point to be marked later. | The parts that passed unmarked and the time window they passed in, so the recheck pass is a known quantity rather than a hunt through a shift. |
| A part reaches the head and no record for it exists in your system | Holds the part. There is no default identifier, no placeholder and nothing assumed. | Hold or divert, chosen by you at the specification, because you are the party who knows what a wrongly marked part costs downstream. | The part, the PLC signal the station saw and the query it ran, logged, so the gap traces back to the point in your process where the record should have been created. |
| The PLC signal is missing, or two signals disagree about the part at the head | Refuses to match, holds the part per the agreed rule, and logs the exact signal state at that instant. | That one part holds for manual identification or diverts. The parts behind it keep moving. | A record your control engineer debugs from, rather than a description of what somebody thought they saw at 3am. |
| The mark fires and the write back fails | Queues the completion and retries. The part is marked and correct, and only the record is behind. | Unaffected. | A queue that drains in order, and an alarm where it has not drained inside the window agreed at the specification, rather than a queue filling up quietly. |
| A confirmation is written and your system never acknowledges it | Reconciles on the interval agreed at the specification, comparing what the station marked against what your system shows as closed. | Unaffected. | A reconciliation report naming the jobs or serials that are marked on the part and still open in your system. A missed confirmation is found by a report rather than by an auditor. |
| A schema, an API version or a credential moves underneath the interface | Fails the pull rather than composing a mark from fields it no longer understands, and raises it as a fault. | Runs on cache, then holds or diverts on your rule. | An alert naming the field or the call that moved. A silent field-mapping change is how a whole run gets marked with the previous product's data. |
| An upstream identifier can collide across sites or lines | Either the uniqueness rule is fixed in the source system, or the mark carries a composite of site, line, date and run. The choice is agreed in writing before build. | Unaffected once the scheme is fixed, because uniqueness is decided at design time on paper rather than at a scanner in year two. | A documented identifier scheme. Two parts carrying one identity break the record for every part around them, and the damage surfaces months later during a trace. |
Integrating a marking line requires no inbound path into the plant
Every pattern in the table above shares one direction of travel: the marking station opens the connection, your endpoint answers, and your firewall keeps its inbound rules exactly as they are. On an isolated OT network the station runs air gapped, with every licence state transition available offline. The desktop application and the industrial marking layer run on the same controller-aware core, written in Nelson, and the licensing and supply chain primitives below belong to that core.
- Outbound only. The station opens the connection to your endpoint over TLS. Your ERP stays unreachable from the public internet, and no port is opened inbound to the plant for marking.
- Least privilege, issued and revocable by you: read access to the job or batch fields the mark is composed from, write access to the single field carrying mark confirmation, and a PLC signal tap. API key or OAuth client credentials on API paths, a least-privilege service account restricted to one read-only view on database paths, a scoped share account on file drops. No personal staff login is requested or wanted.
- Read-only PLC posture. The agreed tags are read, ladder logic and function blocks are left untouched, and any write is separately scoped and signed off before it exists. OPC UA runs certificate-based security where the environment provides it, and Modbus TCP, which carries no authentication of its own, is scoped to a network segment agreed with your control engineer.
- Credentials and connection details are issued through your existing account and access processes, at the access level the interface specification names and nothing beyond it.
- Air-gapped operation, with every licence state transition available offline. The application mints a Device Setup Code carrying the device identifier, an Ed25519 public key, device name and platform, and verifies the returned RS256 activation and lease signatures, issuer, device identifier and public key hash entirely locally. Offline lease refresh and offline deactivation are both Ed25519-signed requests, and the deactivation code persists across restart so the device slot is provably released.
- Licence integrity controls: state expires if the system clock is set more than an hour before lease issuance, and local activation is cleared the moment the server reports the device unbound.
- Secrets live in the operating system credential store, macOS Keychain, Windows Credential Manager or freedesktop Secret Service, rather than in a file on disk.
- Supply chain integrity: updates are fetched from a signed version manifest and every download is verified against a published SHA-256 checksum before installation.
- The station holds only what it needs to complete the parts in front of it. The record of what was marked lives in your system, where it already belongs.
- Every completion write back is logged with timestamp, operator, machine and station, so the audit trail is a by-product of marking rather than a separate exercise someone runs at the end of a shift.
- The assistant features are the single part of the product that needs a live connection, and they sit outside the marking path, so an isolated network keeps everything that composes and fires a mark.
What your team owns, and what the Control Layer owns
An interface has two sides and a named owner on each. This is the split written into the specification before the build starts, so the boundary is engineering rather than a conversation held after commissioning.
| Task | Your IT and OT team | Light Lane |
|---|---|---|
| Access and credentials | Issues API access, a read-only database account, or a watched folder, whichever pattern is agreed, through your own process | States exactly what access the mark composition requires, field by field, and works inside that scope |
| PLC signal | Confirms which tags identify the part at the head, alongside whoever maintains the PLC program | Reads the agreed tags only, and leaves ladder logic and function blocks untouched |
| Interface build | Reviews and approves the written interface specification | Builds and tests the interface against your representative data, then holds it at a version number |
| Test data | Supplies representative jobs, batches and serials from a test or sandbox environment where one exists | Runs the interface end to end against that data before it goes near a live part |
| Sign-off | Approves the interface for production use under your change control | Documents the data flow, the field map and the failure behaviour clause by clause, and hands it over |
| Change notice | Flags a system upgrade or a schema change on your side ahead of it landing | Maintains the interface, re-tests after a change on either side, and versions the specification with a changelog |
How an interface is specified, tested and signed off
This runs inside the programme rather than after it. The interface closes against criteria fixed before a line of it is built: the round trip proved on real parts at line rate, the pull-ahead depth, the hold rule, and the symbol grade, each stated as a number. The gate structure those criteria sit in is set out in how we deliver.
- Step 1
Map the record and the signal
With whoever owns the ERP or MES, and whoever owns the PLC program, we trace the actual journey: where the job, batch or serial is created, which tag identifies the part at the head, and what the completion record has to carry to close the job.
Why it matters: Every field on the proposed mark is traced back to the system and the moment it is created. A field that fails the trace either comes off the mark, or the process that creates it changes first, and which of the two it is becomes your decision, made with the cost attached.
- Step 2
Select the pattern with your team
REST or SOAP against your endpoint, a read-only database view, a watched file drop, a message queue, an OPC UA or Modbus TCP tag read, or middleware your organisation already sanctions. The pattern is chosen against what your environment runs today and what your IT team will sanction.
Why it matters: The pattern sets the authentication model, the latency and the edge the design has to hold, so it is decided on paper with the people who own the network rather than discovered during a build.
- Step 3
Write the interface specification
Fields, direction, format, transport, authentication model, behaviour on each side when the other is unavailable, test data, deployment and rollback, issued at a version number with a changelog.
Why it matters: The version number is what a later change is re-tested against, so a schema move on your side or a release on ours produces a diff against a document rather than an argument about what the interface used to do.
- Step 4
Build and test against representative data
The interface is built and run against representative jobs from your system, in your sandbox where one exists, with the field map exercised across the product families the line actually carries.
Why it matters: The first live part is the wrong place to discover that a field arrives in a format nobody mapped.
- Step 5
Run the round trip on real parts, then sign it off
Before the interface goes live, the whole loop runs end to end on real parts at real line rate: pull the record, read the PLC tag, compose and fire the mark, confirm it back, and check the record closed against the right job. Your team signs it for production use and the result is captured in the Site Acceptance Record.
Why it matters: The round trip is proved on your parts, on your line, with your own scanners, against criteria written before the build started.
Integration routing: what the architecture runs when the record sits outside a system
Four questions set the shape of an integration, and none of them is about the laser: what does your system expose, who approves a path to it, at what point in your process is the identifier issued, and is that identifier unique. They are asked on the first call, because the pattern follows the answers. Where the automatic round trip has nothing to read, the station runs on a loaded job list or on operator entry and the record is closed on your side, which is a real system and it is specified as the one you are buying.
| Condition in the plant | What sets the path | What the Control Layer runs |
|---|---|---|
| A closed system with no API, no database access and no export | Some older plant systems and some vendor-locked packages expose no supported interface at all. Driving a production system through its own screens is outside what any IT team should sanction from any party. | The station runs on a job list loaded at the start of a run, or on operator entry at the station. The mark is the same permanent mark, formed in the material, and the record is closed on your side by a person. |
| The control network is deliberately isolated and grants no path | A legitimate posture, and a common one where the OT network carries safety functions. It is a decision your control engineer owns. | A standalone air-gapped station. Job data in by file on approved removable media, mark records exported the same way on the same schedule, and every licence state transition available offline, so isolation costs nothing in the marking path. |
| A field on the mark lives in an operator's head, on a whiteboard or in an end-of-shift spreadsheet | The record is created after the part has already passed the head, so there is nothing to read at mark time. The field map surfaces it during discovery rather than during build. | The mark is scoped around the fields that exist today, and where you want the remaining field carried, the process that creates it changes first. Both routes go into the scope with the cost attached. |
| The identifier is issued after the part reaches the head | The pull and the composition each take real time, measured against the gap between parts at your line rate. | Three routes, all yours to choose: issue the identifier earlier in your process, move the marking point later on the line, or mark the pack rather than the part. Each goes into the scope with its timing attached. |
| Your system exports overnight rather than live | The latency of the export becomes the latency of the mark, so the question is whether the nightly file carries everything the next run needs. | Where it does, the watched file drop pattern runs and is specified as sufficient. Where fields change inside the run, a live path or the PLC tag read carries those fields and the file carries the rest. |
| A heavily customised instance, or an in-house MES with no published data model | What the system exposes is established before anything is designed against it, so discovery is a scoped stage with an output rather than an assumption sitting inside a build. | The same pattern set applies. Discovery states what the system exposes, the interface specification is written against that, and the field map is proved on representative data before it goes near a live part. |
Engineering questions, answered with numbers
The questions a systems integrator or an IT manager asks once the architecture is on the table.
How does the Control Layer connect to an ERP we run as a customised instance?
Through one of the patterns above, chosen with your team: REST or SOAP against your endpoint, a read-only database view, a watched file drop, a message queue, an OPC UA or Modbus TCP tag read, or middleware your organisation already sanctions. Each carries its own authentication model and its own documented failure edge. The build runs against your instance, with the field map written down and exercised on representative jobs before it touches a live part. On SAP the path is whatever your Basis team sanctions, usually the middleware already running, and approval takes longer than the build.
What access does the marking station need to our PLC?
A read of the agreed tags, usually a small set that identifies the part at the head. Ladder logic and function blocks stay untouched, and any write is separately scoped and signed off before it exists. OPC UA runs certificate-based security where the controller carries it, and Modbus TCP, which carries no authentication of its own, is scoped to a network segment agreed with your control engineer. Your control engineer keeps full ownership of the program.
Can the station run with no live connection to the ERP?
Yes. The station runs on file-imported or operator-entered job data, and on an isolated OT network it runs air gapped, with every licence state transition available offline through Ed25519-signed requests that the application verifies locally against an RS256-signed lease. What changes is the round trip: the record is closed on your side rather than by the station. The mark itself is identical, and so is the marking process behind it.
What happens on our line during an ERP maintenance window?
The station marks from a pull-ahead cache rather than calling the business system per part, so the physical line runs straight through the window. Cache depth and hold duration are sized against your run length and line rate at the specification stage and written into the acceptance criteria as a number. When the link returns, the queued completions replay through the same single confirmation field, and the reconciliation run on the agreed interval shows every job marked during the window closing against your system.
Who owns the interface once it is live?
You do. The data flow, the field map, the failure behaviour and the configuration are documented and resident on your site, at a version number with a changelog, so your team reads how their own systems talk to the marking line without us in the room. Support continues under the agreed tier, and any competent integrator can pick the interface up from the handover pack.
How is the mark verified, and against what?
Data Matrix is generated to ISO/IEC 16022, symbol quality is graded per ISO/IEC 15415 for 2D and ISO/IEC 15416 for linear, and the accept threshold is set against the scanner class your operation actually carries. The grade is written into the acceptance criteria before the build and verified on your own parts at line rate during commissioning, then signed as part of the Site Acceptance Record.
Read the engineering
The integration architecture is one published layer of the platform. The rest is published at the same resolution.
Start here
Multi-site programme architecture
Reference design and controlled replication, with the interface specification and the identifier standards set once for the group rather than negotiated site by site.
The record architecture
What a permanent code carries, how it is read back on the floor, and the regulatory picture stated accurately with each date attributed to the body that issued it.
Programme assurance
The named document set, the requirements traceability matrix and the acceptance gates the interface specification closes against.
Bring the system that issues your job numbers
Bring the ERP or MES that already owns the job, the batch and the serial, the tag your control system already carries for the part at the head, and the network posture your IT team will sanction. We map the round trip against your stack, name the pattern, and write the interface specification with its failure behaviour clause by clause before anything is built. Send a part ahead of the visit and the numbered Marking Process Capability Study is on the table when we arrive.
Last updated August 21, 2026