What software works with a Vorne XL 800?

Where does the XL 800 sit in the Vorne XL line?

The XL 800 is one of Vorne’s second generation XL Productivity Appliances. Vorne’s own software versions page groups the models by generation: XL400, XL600 and XL800 as second generation, XL410, XL610, XL810 and XL HD as third, and XL HD+ and XL Touch as fourth. The models page currently lists XL Touch, XL HD+ and XL810-1 as the appliances you can buy today, and Vorne still publishes an XL800 product page alongside them.

The generation tells you which hardware you own. It does not tell you which software interface the board exposes, and that is the thing that decides what can read it. Firmware decides that, and the firmware version is on the board’s own device information page in a browser. So “what works with an XL 800” resolves into two checkable questions: what the board recorded, and how software gets at it.

What data does an XL 800 actually hold?

Vorne describes the XL data warehouse as two things. Registers hold real time values, including the 100 or more metrics the production monitor generates, plus a large block of uncommitted registers that a PLC or an ERP system can write into. Streams hold archived history: production records for the last 1,000 shifts and 1,000 jobs, a timeline of production state changes with the reason code attached to each one, and the interval records that shift and job reporting is built from.

The board also serves that data itself. It has a 10/100 Ethernet port and an embedded server, so a browser on the plant network can see live values and download shift and job reports as Excel, Word or CSV files with nothing installed on the PC.

The limit worth knowing about is rotation. Streams are capped. When the cap is reached the oldest rows are dropped to make room, so the board is a rolling window rather than an archive. If you want to compare this quarter against the same quarter three years ago, the data has to be collected off the board before it rotates out.

How does software read a V1 board?

On XL firmware before 2.20, which is what we mean by V1, the board exposes two interfaces that integrations use:

• SQL over HTTP. The board accepts a read-only SELECT against its own tables at /sql-request.do and answers with JSON or XML. It is read-only by design: the interface has no way to modify data, so a reporting tool cannot damage what the board recorded.
• The Type II binary protocol over a TCP socket, which is the machine-to-machine path and the only one that can write to a V1 board. Registers, user strings and parameters are writable here and nowhere else, which is why our own OPC server for XL boards wraps this protocol rather than the HTTP interface.

The board also publishes its full data schema, so an integration can discover the tables and column types rather than guessing at them. On firmware 2.20 and later the board exposes a REST API instead, with separate endpoints for tables, event channels, real time values and manufacturing writes. That is the V2 interface.

This is why the firmware version matters more than the model number when you are asking what software will work. Open the board in a browser, read the firmware version off the device information page, and you know which interface you have.

What can OEE IntelliSuite do with a V1 board today?

We support V1, V2 and mixed environments, which is the whole point of the answer above: the software meets the board where it is.

• Collect and keep the history. The XL Bolt-On Data Collector collects and aggregates XL device data for analysis and reporting. Once records are off the board, how long you keep them is your retention decision rather than the board’s row cap.
• Report on it. OEE Explorer reads V2, V1 and virtual stations, so a V1 line appears in the same analysis as everything else.
• Run the floor from it. Work Tracker works against V1 and V2 boards, and against manual stations for equipment with no board at all. It sets jobs and teams, records individual employees and maintenance technicians, and pushes reject categories, states and reason codes back to the board.
• Put V1 and V2 on one timeline. Data Converter maps V1 records into the V2 schema as they arrive, not in an overnight batch, so a converted V1 line shows the same shapes as the V2 line beside it.
• Add what the board never had. Operator comments, and employee punch-ins with Work Tracker, on a converted V1 device. The conversion page covers what that changes.
• Alert on the channels that suit the site. Pulse runs inside your firewall, and an in-app banner or an internal mail relay never leaves the building at all. Converted devices appear on the live timeline and raise the same alerts as V2 devices. What crosses the boundary on each channel is set out channel by channel.

What does not change when you add software?

Two things, and they are worth knowing before you buy anything rather than after.

A V1 board’s stored history is interval-shaped. It writes counts at job and shift interval boundaries and state changes to its timeline, and it does not keep a count history inside an interval. So V1 history answers questions at job and shift level, which is most of OEE, downtime, reasons and quality reporting, and no conversion or import can recover finer detail from it, because the finer detail was never written down. What does give you finer resolution going forward is the other half of the board: registers hold live values, updated continuously, so a collector reading them builds a fine-grained series from the day it starts. Backwards, interval level. Forwards, as fine as you collect. The conversion page goes through what that means for a migration.

And we do not speak for Vorne about hardware or firmware support for your specific units. What we will tell you is what our software can read, write and report against the boards you have, which is a question we can actually check.

Stay on V1, or move?

If you stay, you are not stuck with the reporting the board shipped with. Collection, Explorer reporting and Work Tracker on the floor all work against V1 boards, and the history stops rotating out of existence the day collection starts. Pulse alerting and the operator features the board never had arrive with conversion, which is a software step rather than a hardware one.

If you move, the question changes from “what still works” to “what happens to the years I already recorded”, and that has its own page: what happens to your V1 data when you move to V2. You do not have to swap every board at once either. Mixed fleets are the normal case, and a line at a time is the normal pace.

Sources

Three things on this page come from Vorne’s own published pages, accessed 14 August 2026, and nothing else on the page does: the XL software versions page (opens in a new tab) for the model generations, the XL models page (opens in a new tab) for the appliances currently listed, and the XL800 data sheet (opens in a new tab) for the registers and the 100 or more metrics, the uncommitted registers, production records for the last 1,000 shifts and 1,000 jobs, the embedded server, the Excel, Word and CSV downloads, and the communication ports.

The rest is a different kind of source and is worth separating rather than filing under the same heading. How streams rotate, the timeline of state changes and its reason codes, the SQL-over-HTTP and Type II interfaces, the published data schema, the 2.20 firmware boundary and the V2 REST endpoints all come from Vorne’s XL integration documentation for V1 and 2.20 boards, and from our own work building against those interfaces. None of it is on the three pages linked above, so do not go looking for it there. What you can check yourself, on your own hardware and in a browser, is the firmware version and the data schema the board publishes.

Vorne is a separate company and its marks are its own. We describe what our software does with XL data; we do not speak for Vorne.