Programs, Communication Prototypes and Machine Integration – How to Connect Equipment from Different Manufacturers in Silesia

Why manufacturers increasingly look for machine integration and custom software

A typical plant in Silesia has a machine park built up over years: a press from the nineties, a new packing line, a robot bought with a subsidised project, a scale with a label printer and several controllers from different brands. Each of these devices works on its own and is often the only source of information about its own operation. Production data reaches the shift supervisor on paper, in Excel or not at all.

When order volumes grow, customers expect batch traceability and accounting wants to know the real cost of a product, manual re-typing is no longer enough. This is when a program is needed that connects machines with each other and with IT systems. An off-the-shelf package rarely fits equipment from different decades and manufacturers, which is why software is tailored to a specific machine park.

Our core is hardware: repairs of controllers, drives, HMI panels, power supplies and communication cards. That is why the programs we write are designed for real shop-floor conditions: interference, long cables, old serial interfaces and missing documentation. We know these devices down to the circuit board, which speeds up diagnosis when communication simply will not start.

What problems companies struggle with – the most common integration barriers

Conversations with maintenance departments and production managers, together with industry publications, show that the barriers have been the same for years. The table below lists those we meet most often, together with the way we solve them.

What we write and build – the scope of programs and communication prototypes

The term "machine integration" hides several layers of work. In practice we combine them into one project, but it is worth distinguishing them, because each requires different skills and tools.

• PLC programs: data exchange logic, buffers, acknowledgements, error handling and communication recovery after power loss,
• protocol drivers for devices with a serial interface: scales, label printers, code readers, meters, older controllers,
• middleware on an industrial PC or edge gateway that reads data from machines and publishes it further,
• connections to SQL databases, ERP, MES and WMS systems: orders, counters, statuses, quality results,
• machine-to-machine signals: readiness acknowledgements, passing products between stations, robot cooperation with a conveyor and a vision system,
• dashboards and reports: simple panels for the shift supervisor, e-mail or SMS alarms, export to CSV and XML,
• test benches and machine simulators that let you check a program without stopping production.

For larger projects that need full process visualisation, we connect our solutions to the supervisory systems described in a separate article on machine integration with SCADA. This text focuses on the earlier layer: how the communication itself is created and how to verify it safely.

Why start with a prototype (proof of concept)

A communication prototype is a small, quickly built setup that proves that data from a specific machine can be read, processed and passed on. It is not a show version but the first stage of the real project, which removes its biggest risks.

A prototype answers questions that cannot be settled on paper: does the machine really send data the way the documentation says, how often does it refresh values, is the link immune to interference from drives, do latencies meet process requirements, and does machine safety remain untouched.

1. Conversation and initial analysis: list of machines, controller brands, data scope, business goal and places where information is lost today.
2. Interface survey: checking ports, protocols, addresses and documentation or, when missing, analysing traffic on the link.
3. Building a test bench: recreating the communication on a table, with a machine simulation or a removed device.
4. Software prototype: reading, writing, error handling, event logging and first results in a simple view.
5. Trial on the machine during an agreed service window, without interfering with safety circuits.
6. Review of results with the customer and a decision: develop, change approach or stop at this stage.

Thanks to this we know how much the rollout really costs and how long it will take before the customer commits a larger budget. The quotation for the full project is then based on verified facts instead of assumptions.

Tools and technologies – what we use

We do not impose a single technology. We choose tools to match what already works at the customer, so that after the project the maintenance department can understand and operate the solution on its own.

Old interfaces and closed protocols – how we approach machines without documentation

The largest group of orders are machines that communicate over a serial link or a proprietary, undocumented protocol, whose manufacturer no longer exists or no longer supports the device. Such a machine is not lost for integration.

• we record traffic on the link during normal machine operation (passive listening, no influence on the process),
• we compare frames with operator actions and display changes to infer the meaning of fields, checksums and markers,
• we recreate the communication on the bench with our own program and check the device's responses,
• only after confirming correctness do we connect the solution permanently and document the frames,
• if the interface itself is damaged, we repair the communication card or transceiver at component level.

From machine to ERP and MES – how data travels across the plant

Communication with a machine alone gives no value until the data reaches those who need it. The most common scenarios are automatic reporting of piece counts from the machine to the production order, downloading process parameters from the system to the machine, and logging downtime with its cause.

• an order from ERP goes to the machine: product index, quantity, recipe or machining program,
• the machine returns to ERP: good and bad pieces, run time, downtime, batch number,
• quality events from readers and cameras are linked to the order number and stored in the database,
• alarms and parameter excursions are sent by e-mail or SMS to the right person,
• energy and material consumption is recorded per order, allowing the real product cost to be calculated.

We integrate with the customer's existing systems through their official interfaces: databases, APIs, exchange files or dedicated modules. We do not assume replacing the ERP or MES: we work with what the company already has and uses daily.

Example integration scenarios for plants in the region

The scenarios below are typical tasks for companies in our region. They show the scale and nature of the work and do not describe a specific customer.

PLC programming for communication – what we pay attention to

A data exchange program in a controller is a different task from controlling the machine itself. It must be resilient to loss of connection, repeated frames, delayed responses and a restart of the device on the other side. Below are the basic rules we apply in every project.

• communication is separated from process logic: a link failure must not stop the machine or change its safe state,
• every exchange has an acknowledgement and a timeout; no response is a handled event, not an undefined state,
• external data is validated (ranges, types, checksums) before it affects machine operation,
• variables have readable names and descriptions, and the signal map is documented as a separate file,
• the program has diagnostics: error counters, last valid read, timestamp and an easy view of communication state,
• before any change we make a project backup, and afterwards we hand over a complete version with a change description.

Cybersecurity and code ownership – what to expect from a contractor

Connecting machines to the plant network increases risk if done without a plan. That is why every project includes basic industrial network protection principles in the spirit of IEC 62443.

• network segmentation: machines on a separate subnet, access only through a controlled gateway,
• no direct exposure of controllers to the internet; remote access only over an authenticated, encrypted channel,
• individual accounts and least privilege, changing default device passwords,
• backups of PLC projects, gateway configurations and middleware programs,
• documentation of IP addresses, ports and data flows so the IT department can review and approve them.

After the project the customer receives the full set of materials: program source code, controller projects, device configuration, signal documentation and communication diagrams. Code rights are agreed in the contract before work begins, so the company is not dependent on a single contractor.

How cooperation works step by step

1. Contact by phone or e-mail: you describe the machines, the problem and the goal. Controller brands and a few photos of nameplates and cabinets are enough.
2. Initial analysis and prototype quotation: free, individual, with a clear scope and success criteria.
3. Prototype on a test bench and a trial on the machine on an agreed date.
4. Review of results and a staged rollout plan with agreed service windows.
5. Implementation, commissioning and acceptance together with the customer's maintenance team.
6. Training, documentation and ongoing support: if hardware fails, we repair controllers, panels and power supplies in our workshop in Knurów.

We work on business days, Monday to Friday, 8:00 am–4:00 pm (Central European Time). Enquiries sent outside these hours are handled on the next business day.

Industries and plants we integrate for

Silesia and the area within 50 km of Gliwice (Gleiwitz) and Rybnik – where we operate

The ACORE workshop is in Knurów, in the heart of the Upper Silesian conurbation. We travel to customers within about 50 km of Gliwice and Rybnik, i.e. the area where most of the region's largest production plants are located. Orders from the rest of the country are handled remotely and by shipping hardware to our workshop.

The region is one of the best prepared for the digital transformation of industry in Poland. The Silesian University of Technology runs an Industry 4.0 centre in Gliwice with infrastructure for testing IIoT solutions, and local companies, supported among others by a special economic zone, are gradually introducing robotisation and machine data integration. Demand for practically connecting the existing machine park with modern systems is therefore growing in both large plants and small manufacturers.

Not only software – repairing the hardware the integration runs on

An integration works only as long as the devices it relies on are healthy. That is why we combine writing programs with electronics repair in one place: PLC controllers, HMI panels, inverters, servo drives, DIN-rail power supplies, I/O modules and communication cards.

• when communication stops, we check whether the cause is software, wiring or a damaged interface circuit,
• damaged communication cards and ports are repaired at component level without replacing the whole device,
• for hardware that can no longer be bought we recreate its function or build a gateway replacing the failed module,
• after repair we test the device on a bench under conditions close to operation in the machine.

You can bring hardware to us in Knurów or ship it by courier from anywhere in Poland or Europe.

Frequently asked questions about machine integration and custom software