Building a Web-First Machine Vision Platform with CODESYS and OPC UA
Engineering Case Study | How Ti2 brought Basler industrial cameras, Python, FastAPI, CODESYS and OPC UA together in a shared machine vision architecture.
Building a Web-First Machine Vision Platform with CODESYS and OPC UA
Engineering Case Study | How Ti2 brought Basler industrial cameras, Python, FastAPI, CODESYS and OPC UA together in a shared machine vision architecture.
Industrial machine vision involves more than connecting cameras and capturing images. When camera operations need to be accessible through browser-based engineering tools and PLC applications, the challenge is coordinating access, commands and system status without creating competing control paths.
For a Sydney-based startup, Mehdi Shayestehfar, Head of Engineering at Ti2, developed a web-first machine vision platform that integrates Basler industrial cameras, Python, FastAPI, CODESYS and OPC UA.
The objective was to create a maintainable architecture in which engineers could manage cameras through a browser while PLC applications could initiate supported camera operations through the same underlying service.
The project highlights an important consideration in industrial automation: how to give different interfaces access to the same equipment while maintaining consistent operation, status reporting and control permissions.
The engineering challenge: Sharing camera access across interfaces
The platform needed to support live camera viewing, image capture, recording, parameter management and PLC-initiated operations.
The browser interface and PLC application both needed to interact with the same physical cameras. Allowing each interface to manage its own independent camera connection could introduce competing access, inconsistent status information and more complicated error handling.
The architecture therefore needed a defined approach to camera ownership, command coordination and shared system state.
It also needed to preserve browser-based engineering access for commissioning and diagnostics while allowing CODESYS to initiate camera operations when authorised.
The architecture: One central camera service
Mehdi designed the platform around a central Python service responsible for managing the physical Basler cameras.
The FastAPI application maintains camera sessions and uses per-camera locks to coordinate access to camera operations. The browser interface and OPC UA integration communicate through this service rather than independently managing the hardware.
This establishes a single application-level path for camera operations and provides a shared basis for reporting camera status and errors.
The developed platform supports:
Logical camera slots and retained camera sessions
Full-resolution image capture
Live camera viewing and recording
Image statistics and histogram information
Saved camera parameter profiles
Browser-based engineering and diagnostic pages
PLC-initiated camera operations through CODESYS and OPC UA
Shared camera status and error reporting
Centralising camera management simplifies the ownership model and provides a foundation for extending the platform as additional machine functions are introduced.
Keeping browser access available during PLC operation
One of the important design decisions concerned how browser-based engineering tools and PLC control would coexist.
An initial approach restricted browser control while PLC operation was enabled. During development, this limited access to engineering functions needed for commissioning and recovery.
The revised approach retained access to the authenticated browser interface while allowing the operator to enable or disable PLC command authority through the web dashboard.
This separates two distinct requirements.
Monitoring and telemetry
The PLC can continue to receive camera status information when PLC command authority is disabled, provided the communication connection and telemetry path remain operational.
Control authority
The operator determines whether PLC-initiated camera operations are permitted.
The permission check is implemented in the Python backend rather than relying solely on the visible state of browser controls. This is important because interface restrictions alone do not prevent another client from attempting to issue commands.
In the described implementation, PLC requests received while command authority is disabled are acknowledged and completed as controlled failures, rather than being silently ignored.
This approach preserves engineering access while making the distinction between equipment visibility and command authority explicit.
Coordinating PLC commands through OPC UA
Communication between CODESYS and the Python camera service uses an application-level request, acknowledgement and completion sequence over OPC UA.
The sequence described for Project X is:
CODESYS writes the parameters required for the operation.
The PLC increments the Request ID once the command details are ready.
Python detects the new request and updates the acknowledgement state.
The camera service attempts the requested operation.
The result and status fields are updated.
The Completed ID is updated after the result information has been written.
The ordering matters. It gives the PLC application a defined way to distinguish a new request from an operation that has already been acknowledged or completed.
Request and completion identifiers can also help correlate commands and results. Duplicate-request handling, timeout detection and recovery from interrupted communication depend on the additional application logic implemented around these identifiers; they are not guaranteed by the identifiers alone.
By defining the command exchange explicitly, the integration provides a clearer basis for coordinating PLC sequences with camera operations than an arrangement relying on loosely coordinated status signals.
Commissioning the platform in stages
Development followed a staged approach, allowing individual functions to be verified before introducing additional integration requirements.
1. Camera verification
Camera discovery and image acquisition were checked using Basler pylon Viewer.
2. Browser-based control
Independent web control was established for each camera, with retained sessions and synchronised status information.
3. OPC UA communication
The communication handshake was introduced and tested using simulated operations, including heartbeat exchange.
4. Camera service integration
The verified OPC UA exchange was connected to the physical camera service.
5. CODESYS integration
CODESYS visualisation controls were added for PLC-initiated camera operations.
6. Access management
Browser authentication and web-controlled PLC command permissions were implemented.
7. Interface testing
Responsive behaviour was checked across industrial monitors, laptops, tablets and mobile phones.
This staged development approach allowed camera functionality, communication and control behaviour to be assessed progressively, rather than introducing every integration dependency at once.
Engineering lessons from Project X
The project illustrates several considerations for industrial applications combining physical equipment, PLC control and software-based interfaces.
Define hardware ownership early
When multiple interfaces need access to the same equipment, a central service can establish a clear ownership model and help prevent competing hardware connections.
Separate monitoring from control authority
A PLC may need continuous access to equipment status even when it is not authorised to initiate operations. Treating telemetry and command permissions separately supports more flexible commissioning and operation.
Enforce permissions where operations are executed
Disabling an HMI control is not equivalent to enforcing an access restriction. Permission checks belong in the backend responsible for processing the operation, alongside appropriate authentication and access controls.
Define command states and error handling
PLC applications need a clear way to determine whether an operation has been received, acknowledged, completed or rejected. Application-level sequencing and explicit result states make this interaction easier to interpret and troubleshoot.
Treat engineering access as part of the architecture
Browser-based diagnostics can be valuable during commissioning and recovery. Access arrangements should be designed deliberately so that monitoring, troubleshooting and authorised machine control can coexist appropriately.
Consider interface responsiveness an operational requirement
Engineering tools may be accessed from different devices during commissioning and troubleshooting. Essential controls and diagnostic information should remain usable across the supported screen sizes and operating environments.
What this architecture means for industrial integration
Project X demonstrates an approach to integrating industrial cameras with PLC applications through a shared software service.
Rather than treating camera management, browser access and PLC communication as separate applications, the architecture brings them together around a common camera service and a defined command exchange.
For industrial automation teams, the practical considerations extend beyond machine vision. Similar architectural questions arise whenever physical equipment must be accessed by multiple interfaces or coordinated across software and control-system boundaries.
A clearly defined ownership model, consistent status reporting and explicit control permissions can help make these integrations easier to understand, maintain and extend.
The project also illustrates the importance of validating integration in stages, from individual hardware functions through to the complete PLC and software interaction.
At the time of the original case study, the next phase of Project X included deployment on the target Windows PC, regression testing with the installed Basler cameras, and further integration of production inspection results, recipes and traceability.
For engineers developing machine vision and industrial automation applications, the central lesson is straightforward: the way interfaces share equipment, coordinate commands and manage state is as important as the individual technologies used to build the system.
Developed by Mehdi Shayestehfar | Head of Engineering, Ti2
Based on Mehdi's original engineering article, Building a Web-First Machine Vision Platform for Project X, published 4 August 2026.
Frequently asked engineering questions
How can a browser interface and a PLC share access to industrial cameras?
One approach is to centralise camera ownership in a service that exposes camera operations to both interfaces. In Project X, the Python and FastAPI service manages the Basler cameras, while the browser and CODESYS integration communicate through that service.
What role does OPC UA play in machine vision integration?
OPC UA provides the communication mechanism between the PLC application and the camera service. The application defines the command parameters, request identifiers, acknowledgement states and result handling used to coordinate camera operations.
Why separate monitoring from control permissions?
Monitoring allows a PLC to receive equipment status, while control permissions determine whether it can initiate operations. Keeping these functions distinct can preserve diagnostic visibility when command authority is disabled.
Discuss your application with Ti2
Working on a machine vision or PLC integration application? Contact Patrick van Eybergen at Ti2 to discuss your requirements.
Phone: 1300 842 111
Email: [email protected]