Live production data in 8 days

If a machine speaks one of the 20 protocols built into MAJiK IoT Connect, we can connect to it: more coverage than you are likely to ever need, with no per-brand drivers to license or install. Some older controllers need a communications module added, and a segmented network sometimes needs a small NAT device to make a cell reachable. Discovery flags exactly that for your equipment list, before kickoff.

Through the machine’s existing Ethernet port. MAJiK IoT Connect runs on the plant network and reads from each controller over the industrial protocol it already speaks, so a machine with an Ethernet connection and one of the 20 built-in protocols connects as it sits, with no new wiring to the controller. Two cases need a small addition: a serial-only or legacy controller connects through an inexpensive protocol gateway that bridges it to Ethernet, and an older controller may need a communications module to expose its data. Discovery confirms which case each machine falls into before kickoff.

Almost never. MAJiK IoT Connect reads the tags your controllers already expose and never writes to them, so your programs, setpoints, and equipment stay exactly as they are. The one exception is data a controller is not currently exposing: making those tags available is a small configuration change a controls engineer can do, not a rewrite of your control logic. Discovery flags any of that up front.

There are two sides to that. From MAJiK, no: there is no proprietary hardware. MAJiK IoT Connect runs as a native service on Windows, Linux, or macOS, and a small VM on your plant network or a dedicated industrial PC covers it (2 cores and 2 GB of RAM handle roughly 5,000 tags). On the machine side, most equipment connects exactly as it is; occasionally an older controller needs a communications module, or a network needs a small NAT device. Discovery identifies that up front, so the full picture is on the table before kickoff.

Yes. MAJiK reaches your machines over the network, so the controllers and the agent need to be on a network that can route between them. Most plants already have this. Best practice is a wired Ethernet network to the equipment, kept on an OT segment separated from your office IT network, with the agent placed where it can reach the machine cells. The agent only needs outbound access for the cloud connection, so the machines themselves are never exposed to the internet. If a cell is isolated today, discovery flags the small change needed to make it reachable.

About two hours of work in total: provision the VM or industrial PC, give it network access to the machines, and, if the deployment is cloud-connected, allow the agent's outbound connections over MQTT (8883) and HTTPS (443). No inbound ports.

It depends which link drops. If the connection from MAJiK IoT Connect up to the cloud goes down, machine data buffers on disk at the edge (up to 1 GB) and replays in order when the link returns, so nothing already collected is lost to a restart, power loss, or outage. The link between the agent and your PLCs is live: if that drops, readings during the gap are not captured, but the agent detects the disconnect right away, marks the data stale, and alerts your team. That is why the agent is placed as close to your machines as the network allows, keeping that path short so drops stay rare.

By repetition, not a new project. Everything an agent does is declared in one version-controlled configuration file, so the setup that brought your first machine online becomes the template for every machine after it. A mixed fleet of brands and ages connects through the same built-in protocols, and a single agent handles thousands of tags, so a site rarely needs more than a few.

Live production data flows from the machines we scope together by day eight, with your production data taking shape in MAJiK Visual Factory as it arrives. Validation, training, and go-live follow right behind. Bigger rollouts follow that same proven pattern rather than starting a new project.