Standalone machine vision controller selection guide

A machine can inspect parts without a separate PC, but only if something in the system runs the inspection application. A conventional frame grabber normally transfers images to another processor; it does not replace that processor. For positioning, classification and pass/fail inspection, the practical choices are a standalone vision controller, a smart camera or a documented programmable camera module. This guide explains how to distinguish those architectures, check application deployment and specify camera and serial interfaces before ordering hardware.

Start with the processing architecture

Choose the device that owns the complete inspection cycle: acquisition, processing, decision and communication. A camera interface or expansion connector does not establish that capability.

Start with vision controllers when several cameras or centralized processing are required. Consider smart cameras when inspection can remain close to the image sensor. Treat board-level cameras as acquisition components unless their documentation explicitly describes an onboard application environment.

Some acquisition hardware includes preprocessing or programmable logic. That still does not prove that it can boot independently, run your complete application and communicate the final decision. The frame grabber image acquisition guide explains the acquisition role in more detail.

Decide what programming means

“Programmable” can describe very different capabilities. Define which level you need before comparing hardware.

1. Configurable inspection tools: You assemble supplied functions such as pattern location, measurements, thresholds and classification. The deployed application is usually a saved inspection job.
2. Scriptable inspection tools: You add expressions or scripts within a supplied runtime. Access to files, communications and external libraries may be limited.
3. Custom application deployment: You compile or package your own application for a documented operating system and processor architecture.
4. Programmable logic development: You implement processing in supported logic hardware. This requires its own development tools and is not equivalent to loading an ordinary application.

For positioning, ask whether the runtime supplies coordinates, orientation, calibration and validity status. For classification, check how classes are defined and how uncertain decisions are represented. For inspection, verify whether measurements and defect thresholds can be exported alongside pass/fail status.

Request a small deployment demonstration rather than accepting a feature label. The demonstration should save a job, remove the engineering connection, restart the device and produce a valid result through the intended machine interface.

The smart camera software compatibility checklist helps separate supported inspection tools from assumptions about application portability.

Check camera and acquisition compatibility

A matching connector is only the first check. The controller must support the camera's transport, driver or acquisition standard, pixel format and triggering behavior.

For an external camera, obtain written confirmation of:

• The supported interface and acquisition software version.
• Maximum image dimensions and accepted pixel formats.
• Hardware trigger support, including electrical requirements.
• Exposure and acquisition control available to the inspection application.
• Simultaneous camera operation and shared-interface limitations.
• Camera power requirements and whether power is supplied separately.
• Recovery behavior after a camera disconnects or stops responding.

GigE Vision and USB3 Vision describe camera interfaces, but the exact software stack still matters. A device with Ethernet connectivity is not automatically a compatible machine-vision camera or controller.

For a smart camera, external camera compatibility may be irrelevant because acquisition and processing are integrated. Instead, check whether its own sensor, optics, trigger and job tools meet the task.

Use the camera finder to narrow acquisition hardware, then verify the remaining combinations against manufacturer documentation. The camera acquisition software integration guide explains why transport support and usable application integration are separate questions.

Budget latency and image traffic

Size the system from the production cycle, not a processor label. First establish the required part rate and the deadline for each result. These are different constraints when acquisition and processing overlap.

For a simple, non-overlapping inspection cycle, use this initial estimate:

Suppose the machine presents 20 parts/s. The available cycle time is:

An illustrative budget might allocate 5 ms to acquisition, 8 ms to transfer, 24 ms to processing and 4 ms to communication:

These are application assumptions, not specifications for any product below. Replace them with measurements from representative images and the deployed inspection job.

A pipelined system can accept another image before the previous result is complete. In that case, measure both sustained throughput and trigger-to-result latency. A system can meet the average part rate while delivering individual results too late for the machine.

Image traffic also affects the architecture. For uncompressed monochrome images with one byte per pixel:

A hypothetical 2048 × 1536 image contains 3,145,728 bytes. At 20 frames/s, the image payload alone is 62,914,560 bytes/s, approximately 62.9 MB/s. Protocol overhead, padding and other traffic are additional.

This calculation explains why processing inside a camera can reduce network traffic when it transmits only decisions. It does not prove that a particular camera offers the required algorithm. The on-camera processing guide explains that distinction.

Compare catalog starting points

Use catalog specifications to create a shortlist, not to infer undocumented runtime, serial or algorithm support. The following products illustrate different hardware roles rather than interchangeable solutions.

Controllers for external cameras

The MV-SVC2506-16G60-128G catalog entry identifies separate camera, configuration and communication GigE ports. That makes camera and machine-network roles explicit, but does not establish support for your inspection job or serial protocol.

The MV-VC3301H-128G66 catalog entry includes a software license and notes expansion support. Confirm the licensed functions, supported deployment method and any additional runtime requirements before treating it as an application-ready controller.

Compare their published specifications:

Values as printed in each product's data sheet; open a part for its drawing and full specifications.

Neither entry alone establishes the serial electrical interface, connector pinout or permission to deploy arbitrary custom code. Those remain documentation checks.

A smart camera for integrated acquisition

The LS-SMC-0063 is cataloged as a smart camera with GigE connectivity. Its integrated approach is worth investigating when one inspection viewpoint can perform the task.

Before selecting it, verify the available positioning, classification or inspection tools, autonomous job startup and supported result interfaces. Do not infer a scripting environment or serial connection from the smart-camera category.

A board camera for an embedded design

The MV-CB016-10GM-M-W is cataloged as a GigE board-level camera with a global shutter and an M12 lens mount. That establishes an acquisition role, not an onboard custom-application runtime.

If a proposed module is supposed to replace the processor as well as the camera, require explicit documentation of that capability. The board-level camera selection guide covers the broader integration decision.

Specify serial communication as a protocol

A requirement for a “serial port” is incomplete. State the electrical interface, wiring, framing and application protocol separately.

RS-232 and RS-485 are not interchangeable electrical interfaces. Connector shape also does not prove signal assignment. Confirm the documented pinout, voltage levels, grounding or isolation requirements, cable arrangement and supported operating mode.

Next, define the message. A compact inspection response might contain a sequence identifier, job identifier, status, coordinates or class, and an error-checking field. Specify coordinate units, decimal formatting, byte order where applicable, and how invalid measurements are represented.

For asynchronous serial transmission using 8 data bits, no parity and 1 stop bit, each byte occupies 10 transmitted bits, including the start bit. An illustrative 32-byte message at 115200 bit/s takes:

That is transmission time only. It excludes processing, application queues, response delays and retries. Check both request and response traffic if the protocol requires polling or acknowledgments.

Define at least these states: ready, busy, result valid, inspection failed and communication fault. Pair every result with the correct trigger or part identifier. Never let a receiver interpret a stale pass result as belonging to the next part.

If the machine instead uses a networked register interface, the vision controller Modbus integration guide addresses that separate communication path.

Verify standalone startup and recovery

Standalone operation means more than running successfully after an engineer presses a software button. The device must restore its application and reach a known state without the development connection.

Build an acceptance test around the actual machine sequence:

1. Save the application and record its version, calibration and required licenses.
2. Disconnect the configuration session and restart the device using its documented procedure.
3. Confirm that the correct job loads and that the machine receives an explicit readiness indication.
4. Send representative triggers, including closely spaced triggers and periods with no parts.
5. Verify result identifiers, timing, invalid-result handling and communication timeouts.
6. Test documented recovery from camera or communication interruptions in a controlled test environment.
7. Restore power and confirm that no previous result is reported as a new inspection.

Record timing distributions rather than just an average. For example, a 10,000-cycle run can expose recurring delays and queue growth, although it cannot establish every possible failure condition.

Retain representative images for good parts, defects and ambiguous cases. Repeat the acceptance test after application, runtime or firmware changes. The software upgrade validation checklist provides a useful structure for that regression work.

When standalone processing is the wrong choice

An integrated architecture is attractive when the inspection is stable, interfaces are supported and the deployed application fits the device. It becomes less attractive when the task depends on unsupported libraries, frequent algorithm changes or extensive image retention.

Choose a configurable smart camera when supplied tools solve the inspection and the device can report the required decision. Do not buy it assuming that arbitrary source code can be added later.

Choose a standalone controller when supported external cameras, centralized processing and machine interfaces match the task. Do not treat spare ports or expansion slots as proof that every driver or application will work.

Choose a programmable module only when its documented development environment supports your application and its integration work is acceptable. A small bare camera board is not automatically the simpler solution.

A conventional frame grabber remains appropriate when a separate processing host is already part of the design. It is not the answer when the requirement is specifically to eliminate that host, unless the selected hardware explicitly provides independent application execution.

Checks before ordering

Prepare a short requirement sheet that separates confirmed capabilities from open questions:

• Inspection output: Position, orientation, class or pass/fail, including units and invalid states.
• Image acquisition: Camera interface, image format, trigger method and simultaneous-camera requirements.
• Deployment: Saved inspection job, supported script or compiled application, with the exact runtime identified.
• Timing: Part interval, result deadline, measured processing time and acceptable queue depth.
• Communication: Electrical interface, documented pinout, message format, identifiers and timeout behavior.
• Licensing: Included functions, deployment rights and the documented replacement or recovery process.
• Autonomous operation: Startup job, readiness indication and behavior after power or communication loss.
• Maintenance: Application backup, calibration backup and a repeatable acceptance test.

Begin with the system configurator once the architecture is clear. If onboard execution, camera support or serial behavior remains uncertain, send the requirement sheet through application support before selecting hardware. The decisive evidence is a documented, repeatable inspection cycle—not the presence of a camera connector or a programmable label.