Custom control boards for machine manufacturers: from design to production testing

1. Distinguish the roles of the PLC, auxiliary I/O board and custom controller

It is not necessary to develop a special board if the ready-made module meets the need. Frequently changing site logic and existing maintenance ecosystem may support the selection of PLC. An auxiliary board for dedicated sensor measurement, pulse processing or protocol conversion can be used on the same machine. When a repeated, limited control function needs to be collected in a single unit, a more comprehensive custom controller is evaluated.

A custom board is not always cheaper or faster. It brings initial development, testing and ongoing maintenance responsibilities. The expected unit quantity across the machine family, model differences and sourcing plan affect whether that effort pays off. Document the division of responsibilities between the main control system, motion drives and safety functions. The system's response to board failure or communication loss must be part of the architecture decision.

• Clearly describe the function missing from the ready-made solution
• Evaluate the quantity of repeat units, variants and maintenance team
• Define control and safety responsibilities separately

2. Don't limit the I/O list to just the number of channels

For every input, specify the sensor model, supply, electrical type, range and timing requirement. A 24 V PNP/NPN digital input differs from a 0–10 V or 4–20 mA measurement circuit. Current-loop design examines sensor power and the complete connection conditions; voltage measurement examines input range and source characteristics. Encoders require channel structure, output level, frequency and cable information.

Specify the type and current of the load on the outputs, such as relay, valve, lamp or driver input. Switching frequency and initial power-up state are also design inputs. Determine target accuracy and verification points for analog measurement and shortest event time for pulse inputs. If the connector pinout and wiring harness are part of the same document, the mechanical team and integrator can work from the same connection definition.

• Channel name, type, range, unit and cable information
• Output load, current and initial state
• Measurement accuracy, timing and verification method

3. Consider the 24V supply and machine environment in their actual conditions

Nominal supply value does not describe the entire electrical environment. The machine's startup sequence, valve and relay loads, supply drop, effect of motors and earth connections of different units should be examined. The necessary protection, filtering and insulation are designed according to these conditions. The presence of sensor supply and precise measurement on the same board also affects placement and return current decisions.

The board's reset and startup behaviour are validated together with the software. Requirements define how accidental output activation is prevented before the supply is adequate, how outages affect parameter storage and how operation resumes when power returns. Cabinet installation checks cover heat, airflow, service access and connection distances. Laboratory functional testing and the intended environmental and electrical validation are separate activities; the scope and responsibility for external testing are planned separately.

• Supply variations, startup and power loss
• Grounding, insulation and cable effects
• Thermal layout, service and external test plan

4. Document the meaning of the messages for Modbus or CAN

RS485 is the electrical connection layer; Modbus brings the definition of messages and operations. Addressing, register map and data types must be defined, along with the line's topology, termination and isolation needs. The scale at which a temperature is moved, the order of multi-byte fields, and how the invalid value is represented can be critical in integration. Official Modbus sources treat the application protocol and serial line manual as separate documents.

Physical compatibility alone is also insufficient for CAN: the application protocol, message identifiers and cycle behaviour must be defined. Permissions, timeouts and result reporting are specified for each command. If a repeated start command must not create a second operation, the software is designed accordingly. The data dictionary must be a deliverable that lets the PLC or server team understand the interface without the physical device.

• Physical network drawing and separate message dictionary
• Unit, scale, address and read/write permissions
• Timeouts, retries and command results

5. Define machine states, parameters and model variants

Specify which events change states such as startup, ready, running, waiting, fault and service. An operator stop, missing sensor input and communication loss need not produce the same response. Clarify whether recipe or parameter changes apply during the current cycle or at the next start. Range checks for stored values and restoration of defaults are also software requirements.

If the same board will be used across different machine models, the configuration selection method is defined. Loading settings for the wrong model must be detectable. Board revision, software version and machine configuration are kept together in service records. Field updates require programming access, authorisation and version compatibility to be considered from the outset. A clear table manages truly shared and differing functions, avoiding unnecessary proliferation of variants.

• State transitions and post-error restarts
• Parameter ranges, recording and execution time
• Model compatibility with hardware/software version

6. Plan the BOM and production testing from the first board design

The bill of materials (BOM) must include not only the short name of the component but also its defined features and manufacturer's parts information. The supply status and alternatives of critical parts are reviewed. A substitute change may create electrical, mechanical or software effects; It is not considered equivalent without verification of suitability. Board layout is evaluated along with connector access, assembly, programming and test fixture.

Checks required for every manufactured board are distinguished from comprehensive design validation tests. Supply current, I/O channels, communication and version checks are made repeatable. Recording test results against the board identity supports later service diagnostics. VOMRO's prototype PCB fabrication and assembly support is provided only within customer projects it develops. Pilot production findings are incorporated into the final file revision.

• BOM with manufacturer part details and verified alternatives
• Accessible test points for programming and fixtures
• Production control result associated with board ID

7. Do prototype acceptance with machine scenarios

Write a verification method against each core requirement. Analog input can be tested with specific reference points, pulse input can be tested with defined frequencies, and communication can be tested with correct and incorrect messages. The expected outcome for sensor breakage, power failure and command repetition should be clearly stated. The hardware revision tested, software version and equipment used are recorded.

The pilot machine reveals cable-routing, operator-interaction and real-load behaviour that bench tests miss. Findings become a change list identifying the revision in which each correction is included. One successful cycle does not prove every operating condition. Production should not be approved until the scoped acceptance scenarios are complete. Access to the machine, actual sensors and the customer's process information must be included in the pilot schedule.

• Matching requirement, test condition and expected result
• Trial on real sensor, load and pilot machine
• Findings and acceptance records closed with revision

8. Document source file delivery and the project kickoff package

However, getting a production output is not the same as getting an editable design source. EDA schematic/PCB resources, mechanical CAD resources, BOM, production files, embedded software resources and technical documents belonging to the project should be clearly included in the delivery list. The compilation environment, programming steps, interface definition, and testing methods are also required for reuse. License terms for third-party tools and components are stated separately.

At VOMRO, an NDA can be signed at your request before technical details are shared; project source code, design files and technical documentation are delivered at completion. For the first meeting, prepare the machine function, I/O list, power supply, communication, space limits and target quantity. Missing technical details are resolved during requirements work. A clear scope and acceptance list turn the quotation into a comparable project proposal that can be assessed technically.

For new functions requested after the project starts, we review the hardware, software and retesting required. The effects on cost, schedule and the deliverables list are clarified separately before implementation.

• Editable EDA/CAD and software sources
• Production, interface, programming and test documentation
• Project starting with NDA, deliverable list and scope

Separate development and production costs in a control board quote →