Language: English

What should you look for in software to run alongside Vorne XL?

Your boards already count parts, time states and hold reason codes, so a software layer is worth buying for what they do not record: jobs, people, history across a firmware generation, and reporting you can change yourself. Check board compatibility down to the firmware version, where the database sits, and how it is licensed.

What do the boards already do, so you do not buy it twice?

Start here, because a lot of what gets sold as an OEE layer is a second copy of what is already running on your wall. A Vorne XL board counts parts, times the states a machine is in, holds its own user-modifiable reason codes, and stores its own production history. It shows the line its numbers without anything else installed.

So the honest first conclusion of this evaluation is sometimes that you need nothing. If board-level performance visibility answers the questions your plant actually asks, buying a layer to display the same numbers on a different screen is a cost with no return.

A layer earns its place by recording what the board does not: which job was running, which people were on it, what the ERP said, what an operator typed at three in the morning, and a history that survives a hardware generation change. Those are the things to buy for.

Ask them: which of the things you have just shown me does the board already do on its own?

A weak answer sounds like: a demo that spends its first ten minutes on OEE dashboards without ever mentioning what the board contributes. If a vendor cannot draw the line between their product and your existing hardware, they have not thought about the plant you actually have.

Which boards does it read, down to the firmware version?

This is the compatibility question, and asking it by model number gets you the wrong answer. As of 14 August 2026, Vorne’s own software versions page groups the hardware by generation - XL400, XL600 and XL800 as second generation, XL410, XL610, XL810 and XL HD as third, XL HD+ and XL Touch as fourth - and that table tells you what you own, not what interface it exposes.

The firmware version decides that. Below 2.20 a board exposes the older interfaces, which is what people mean by V1. On 2.20 and above it exposes a REST API, which is V2. Two identical XL800s can therefore need two different answers, and the full mechanics are on the page about software for the XL 800.

Ask them: here is the model and firmware version of every board I own. Which of them do you read today, and do the ones on older firmware appear in the same reports as the rest?

A weak answer sounds like: "we support Vorne XL". Anything about your specific board’s support status is Vorne’s to answer rather than a software vendor’s, but whether the vendor’s own product reads it is squarely their question, and it has a yes or no answer.

Does it read the boards, or ask you to re-instrument the line?

Some products arrive with their own gateway, sensors or edge device, because that is how they read a floor with nothing on it. If you already have boards counting parts, paying to install a second measurement path means running two sources of truth on one line, and the day they disagree is the day the system stops being believed.

Ask them: what hardware do you install, and if the answer is none, what are you reading and over what interface?

A weak answer sounds like: a quote where hardware appears as a line item you did not expect. It is not automatically wrong - a line with no board needs something - but it should be a deliberate decision rather than a discovery.

What happens to the history from before the changeover?

Plants upgrade in stages, so a realistic deployment has old boards and new boards running at the same time and needs both in one report. That is a data problem, not a display problem.

Be precise about the shape of what comes back. Older-firmware history is recorded at job and shift interval boundaries, so converting it gives you interval-level history going backwards however good the conversion is. Going forwards, a collector polling the board’s live values builds a series as fine as it collects. Backwards coarse, forwards fine, and any vendor promising otherwise about years already past is selling you something that is not there.

Ask them: after conversion, do old and new lines appear in one device list and report the same metrics? What resolution do I get for the years before, and what for the years after?

A weak answer sounds like: "all your history comes across", with no distinction between what was recorded then and what will be recorded from now on. Our own account of what converts and what does not is on the V1 data conversion page.

Can it write back to the board, or only read from it?

A read-only layer produces a second place where the truth lives. An operator picks a reason in the software, the board still shows the stop uncoded, and now the wall and the report disagree in front of everyone.

Writing back matters for states, reason codes, reject categories and notes. It is also the capability most often quietly absent, because reading is easy and writing means implementing the board’s own interfaces properly.

Ask them: when an operator codes a stop in your software, what does the board show a second later? Which of states, reason codes, reject categories and notes can you push, and on which firmware?

A weak answer sounds like: "it all syncs". Ask for the list, per direction, and watch it happen on a live board in the demo.

Where does the production database live, and can you query it?

Your boards are inside your network today. A layer on top can change that without anybody deciding to, because the natural shape of a cloud product is a permanent outbound path carrying your production history to somebody else’s server.

There is no universally right answer, and there is a right answer for your plant that somebody other than the vendor should give you. The related question is whether you can reach the database directly, which decides whether your own analysts can ever do anything with it.

Ask them: where does the database physically sit, what leaves the plant network and on which channel, and can my BI tool connect to it directly?

A weak answer sounds like: "hosted for you" offered as though it were the same as on-premises. It may be the better choice; it is a different one. What crosses the boundary on each alerting channel, in our case, is set out on the alerting page.

What about the lines with no board on them?

Every plant has them: the manual cell, the packing line, the machine nobody instrumented. If the software only understands boards, those lines stay invisible and every plant-level number is quietly wrong.

Ask them: how does a line with no board get into these reports, and does its data land in the same tables as board data or somewhere separate?

A weak answer sounds like: "you would add a board there". Sometimes correct, and still a capital request rather than an answer.

How is it licensed, and what is the minimum?

Licensing units differ more than prices do, and the unit decides who the product is cheap for. Per installation with unlimited boards suits a plant with a handful of boards. Per board suits a plant that wants its cost to track its footprint. A per-board price with a floor underneath it means a small plant pays for boards it does not have.

Ask them: what is the unit, what is the minimum purchase, and what does this cost at my exact board count in year one and year two?

A weak answer sounds like: a per-board price quoted without its minimum. Ask for the floor explicitly.

Who do you call when the board and the software disagree?

Adding a layer adds a boundary, and boundaries are where support tickets go to die. The board vendor says it is the software; the software vendor says it is the board.

Ask them: a count on the board does not match the count in your report. Walk me through what you do, what you can see, and at what point you tell me to call somebody else.

A weak answer sounds like: a support process that begins with a ticket number. What you want to hear is a diagnostic sequence, because it means they have done this before.

Where do we fit against these criteria?

One of them we do not win, so that first.

Our licensing minimum will not suit a small board count. We license per Vorne XL, starting at 10. A plant with three boards pays for ten, and a product licensed per installation with unlimited boards is straightforwardly cheaper for that plant. Our own comparison with XBHMI publishes both licensing models side by side, and that row is theirs.

And the rest, plainly:

  • Board compatibility. V1 and V2 boards are read side by side, and a mixed floor is the normal case rather than an edge case. No board is replaced to make reporting work.
  • Writing back. Work Tracker pushes states, reason codes and reject categories to V1 and V2 boards alike, so the wall and the report say the same thing. Notes are the exception, and it is a board limitation rather than a software one: a V1 board has nowhere to store an operator comment, so on those lines the notes live in the software.
  • History across the changeover. Data Converter rewrites older-firmware records into the V2 schema as they arrive, so a converted line and a new line sit in one device list. What that does and does not include is on the conversion page, including the parts that are configured again rather than migrated.
  • Lines with no board. A manual station records the same production data with no physical device behind it, and it lands in the same tables, so plant-level numbers include the uninstrumented lines.
  • How the data gets there. Through the XL Bolt-On Data Collector from Sulzer Consulting, a Microsoft Windows service that periodically harvests the data buffered inside each device into your own database, at a capture frequency you configure, against Microsoft SQL Server. It is what takes production data off the boards on a normal install, and it is licensed separately, so a quote for a Vorne XL plant covers it alongside the suite. OEE IntelliSuite reads the database it fills.
  • Where the data sits. Your choice of the two: a server on your own plant network, with the database there too, or the same stack hosted for you. The server and network requirements for either are published on the technical specifications page rather than sent on request.
  • What we are to Vorne. Not Vorne. The site’s position, on our FAQ, is that OEE IntelliSuite complements Vorne XL rather than replacing it: the boards stay strong at machine and line performance, and we add the workforce, workflow, reporting and integration layers around that data.

If you are earlier than this and still deciding what OEE software is for, start with the general buyer guide. If the real subject is capturing stops and reasons on the floor, choosing a downtime tracking system covers the operational half. Sourced comparisons against specific products are on the comparison hub, and if a cloud product is already on your shortlist, the alternatives pages for MachineMetrics, Evocon and Shoplogix name the rest of the field rather than only us.

What to do next

Where to take this next.

FAQ

Questions people ask next.

Do we need to replace our boards to add software?
Not to add reporting. An XL board serves its production data over your network, so software can read what it already records. Replacing hardware is a separate decision about what the board itself does on the wall. Be suspicious of any layer whose first requirement is new hardware, and ask why.
How do we tell which board generation and firmware we have?
The model is on the unit. The firmware version is on the board’s own device information page in a browser, and it is the one that decides how software reads it: below 2.20 the board exposes the older interfaces we call V1, and 2.20 and above exposes the REST API we call V2. Collect both for every board before any vendor call.
Will a software layer slow the boards down or change what they display?
It should not, and that is a fair question to ask directly. Reading a board over the network is a read against an interface it already publishes. Writing to it - pushing a state, a reason code or a note - is a deliberate action a product either supports or does not, and you should know which one you are buying.
What does Vorne’s own software already give us?
Machine and line performance visibility at the board, and reporting over it. That is genuinely a lot, and the honest starting point for this evaluation is that if board-level reporting answers your questions, you do not need another layer. What a layer adds is the context the board was never going to record: jobs, individual people, other systems, and history that survives a hardware generation change.
Can operators still work at the board if we add software?
Yes, and it is worth confirming a product does not force a choice. A board keeps counting whatever else is running. What varies between products is whether the software can push states, reason codes, reject categories and notes back to the board, so the two agree rather than telling two stories.
What happens to the data from our older boards?
Ask whether it comes into the same reports as the new boards or stays in a separate system. Older-firmware history is stored at interval boundaries, so the shape of what you get back is coarser than a board collected live from day one. A vendor who tells you conversion produces second-by-second history for years already past is describing something that does not exist.
Is this vendor affiliated with Vorne?
Ask, and expect a plain answer. OEE IntelliSuite is not Vorne, and OEE IntelliSuite is designed to complement Vorne XL rather than replace it. Vorne, XL, and the model names are Vorne’s marks and we use them to describe what our software works with. Anything a vendor tells you about Vorne’s support, roadmap or firmware should be confirmed with Vorne.
What should we bring to the first call?
The model and firmware version of every board, how many lines have no board at all, where you want the database to live, and the one report you build by hand today. That is enough for any competent vendor to tell you what works, what needs conversion, and what they cannot do.

Related answers

Questions next to this one.

Each answer page covers one question. These are the ones people read alongside it.

  • What should you look for when choosing OEE software?

    Test six things: what it can read from your machines, where the data lives, what an operator has to do, what you get out if you leave, who maintains it, and what year two costs. Ask each as a question with a specific answer, and treat a vague answer as the answer.

  • What should you look for in a downtime tracking system?

    The number that decides whether a downtime system works is how much of your stopped time ends up with no reason on it. Ask how a stop is detected, who codes it and when, what happens when nobody does, and how a wrong reason gets corrected later. Everything else follows from those.

  • What software works with a Vorne XL 800?

    An XL 800 keeps its own production data on the board and serves it over your network, so software can read it without replacing anything. OEE IntelliSuite collects from V1 and V2 boards side by side, which is what lets an XL 800 report next to newer hardware instead of on its own.

  • All answers

    Every answer page on this site, grouped by the situation it belongs to.

Send the board list before the demo.

Model and firmware version for every XL board, plus the lines with no board on them. We will tell you what works today, what needs conversion, and which parts of your list we would not be the right answer for.

Get a demo See the products