Die kurze Antwort
A gateway reads your machines, a mapping turns a status into a downtime reason, and Business Central pauses the operation. No custom integration code is written.
The usual way, and its cost
Connecting a machine to an ERP usually means a project. Someone writes a script that polls a controller, a second script that cleans the values, an integration that pushes them to a staging table, and a job that turns the table into something the ERP understands. Each piece is small. Together they are a system nobody owns, and when the person who wrote it leaves, a stopped line stays a mystery.
The MESFlow Machine Gateway takes a different approach. It is a Windows service that reads status, counters and alarms from your equipment and posts them to Business Central. The machines, their settings and the meaning of their states live in Business Central, where a consultant can see them, rather than in a script on a server.
Which protocols
The gateway supports OPC UA, Modbus TCP and RTU, MQTT, Sparkplug B, EtherNet/IP, Siemens S7, MTConnect, HTTP, serial lines and file drops. It works with these protocols, and new drivers can be added as plug-ins. File drops matter more than they sound: an older machine that can only write a file to a folder can still take part. Serial lines do the same for equipment that has never heard of Ethernet.
Be precise about what has been proven. Sparkplug B, Modbus RTU, EtherNet/IP, Siemens S7 and MTConnect are commissioned per site. They have not yet run on a real device. Test them on the customer's equipment first, and agree what that test must show before you sign off the scope.
What the gateway does
A gateway has three jobs. It reads the machine. It translates what it reads into a small set of things Business Central understands: a status, a counter, an alarm. And it carries them to Business Central reliably.
That last job is where homemade integrations fail. The gateway buffers what it reads, so if the connection to Business Central is down, nothing is lost. When the link returns, the buffered readings are posted. A short outage becomes a delay, not a hole in the data.
Machine settings are kept in Business Central and applied without restarting the gateway. That means adding a machine or changing a mapping is an edit in Business Central, not a visit to the server with a remote desktop session at two in the morning.
How a stopped machine becomes a downtime reason
A machine does not know the word "changeover". It knows that its state changed from running to stopped, or that a bit went high. The step that gives that signal meaning is the mapping: you map a machine status to a downtime reason.
Once the mapping exists, the sequence is short.
- Status changesThe gateway reads that the machine has stopped, with the machine's own timestamp
- MappingThe status is matched to the downtime reason you chose for it
- PauseThe running operation is paused with that reason, or a supervisor is offered the pause to accept
- ResumeWhen the machine runs again, the operation resumes
The offer to a supervisor is useful where a stop can mean several things. A machine that reports only "stopped" cannot tell a jam from a break. Letting a supervisor accept the pause, rather than having it happen on its own, keeps the downtime report honest.
The counter and the good quantity
Machines also count. The counter can pre-fill the good quantity at completion, so an operator confirms a number instead of typing one. A counter counts what passed the sensor, not what passed inspection, so scrap still has to be reported at completion. The saving is in the typing, and in the typos that a hurried operator makes at the end of a long run.
What the run looked like
In our machine automation run, a stopped machine paused the operation and, when the machine ran again, resumed it. Nobody touched a screen in between, and the downtime appeared with the machine's own times. This was run in a sandbox with demo data, which is why we say "our run" and nothing more.
A sensible project order
Do not connect everything at once. Pick one line and one machine, and take it through the whole chain before adding a second.
- ChooseOne machine on one line, with a protocol from the list
- KarteIts stop statuses to a short set of downtime reasons
- Beweise esStop it on purpose and watch the operation pause and resume
- GrafCheck the counter against the good quantity on a real run
- ExtendAdd the next machine only when the first one is boring
If the machine uses one of the five protocols that are commissioned per site, add time for commissioning, because the first real device is where surprises show up.
In Business Central
The features involved are the machine register, the machine settings kept in Business Central, the downtime reasons and the mapping from machine status to reason, the operation log, and the role center cues for machines in alarm and gateways offline. The machine activity report and the downtime report give the printable view, and the machine register report lists the equipment itself.
Limits
Say these out loud in your project plan. Five drivers are commissioned per site and have not run on a real device. The desktop app that operators use is unpackaged and unsigned, with no installer yet. The apps are in English only and are built for Business Central online, version 29. The gateway runs as a Windows service, so it needs a Windows machine that can reach both the equipment and Business Central.
Keep reading
Once a stop becomes a reason, the list of reasons matters: see downtime reasons people will actually use. If the link to Business Central is the part you worry about, see when the plant network drops.
See it on your plant
Tell us which controllers you have. Book the machine connectivity demo scenario and we will say which protocols are ready to show, which need commissioning on your site, and what a first test on your equipment should prove.