The file is already decoded
before you open the job.

The problem, stated honestly

A slave tool is a commercial decision, not a technical failing. Slave hardware is cheaper, it is what most dealers and smaller shops can justify, and it produces perfectly good reads. What it does not produce is a file you can open and edit directly. The read comes out wrapped in the tool's own protected format, and it has to go through the tool vendor's own decoding step before it becomes an editable binary — and back through the matching encoding step afterwards, so the tool will write it to the car.

On one job that is a minor inconvenience. Across a working week it is a tax. Every single file means the same sequence: download the attachment, find it in your downloads folder, open the tool's software, log in, upload, wait, download the decoded file, find that, open it in WinOLS, do the actual work you are paid for, export, go back to the tool, upload the modified file, wait again, download the re-encoded slave, and finally return it to the customer. The tuning took twenty minutes. The handling took another fifteen — and the handling is the part that adds nothing to the invoice.

Worse, it is the part that fails. It is where the wrong file gets uploaded, where the customer's original gets confused with a decoded copy, where a job sits untouched for an hour because you did not realise it had landed, and where a tired operator at 9pm sends back the file that was never re-encoded at all.

How it works: the bot lives on your PC

This is the design decision that makes the whole thing viable, so it is worth being precise about it.

The RemapDash bot is a small application that installs on your own Windows machine — the same PC you already run WinOLS and your tool software on. It pairs once with your portal, and then it sits quietly in the background, connected, waiting for work. When a job lands in your portal, the bot picks it up, does the decode against your tool account, and puts the resulting open file back on the job for you.

Your tool credentials stay on your PC. They are stored encrypted on the machine itself, tied to your Windows user, and the decode happens from your computer using your own account — exactly as it would if you were sitting there clicking the buttons yourself. Your relationship with your tool vendor stays exactly what it was. Nobody is proxying your account through someone else's infrastructure, and nothing about your licensing arrangement changes.

That matters for a practical reason as well as a principled one: because the work happens from your machine and your session, it behaves the way your tool expects. It is your normal workflow, performed automatically, at machine speed, without you.

What actually happens, step by step

• The customer uploads. A dealer submits a job through your branded portal and attaches the slave read from their tool.
• The portal recognises it. The file is identified as a slave file rather than an open binary — and if the customer has ticked the wrong box, the portal corrects it (see below).
• The bot claims the job. Your paired PC picks the work up automatically. Nothing needs opening, clicking or dragging.
• The decode runs against your account. The bot performs the decode step through your own tool credentials, held on your own machine.
• The open file lands back on the job. By the time you sit down and read the customer's request, the editable file is already attached to it.
• You do the part you are actually paid for. The calibration work. In WinOLS, with your library, your definitions, your judgement.
• The re-encode goes back the same way. Drag and drop your modified file onto the job and the bot packs it back into a slave the customer's tool will accept — or, where a suitable donor is found in your library, the whole cycle runs automatically through the LUA bot with no drag and drop at all.

Two speeds: drag-and-drop, or fully automatic

Not every job should be automated, and a system that pretends otherwise is one you will eventually stop trusting. So there are deliberately two modes, and you choose per job.

1. Drag and drop

The decode happens automatically on the way in — that part costs you nothing and risks nothing, because decoding a file changes no calibration values. You do the tuning yourself. When you are finished, you drag the modified binary onto the job and the encode runs automatically on the way out. Every calibration decision was yours; the mechanical wrapper on each end was handled for you.

This is the mode most shops will live in most of the time, and it already removes the overwhelming majority of the handling cost.

2. Fully automated, when a suitable donor exists

If the incoming file matches a job you have already done and verified — the same ECU, the same software, a genuine donor in your own WinOLS library — the LUA bot can carry the whole cycle through: decode, apply your proven work from your own library, re-encode, and return.

Read that carefully, because the distinction is the entire point: this is your own previously tested work being reapplied to a file it genuinely matches. It is not a model generating a calibration. Nothing is invented. If no suitable donor is found, the job does not get a guess — it stays on your bench as a normal manual job. We wrote a full page on why library-based automation is not "AI tuning", because the difference is the difference between a fast shop and a damaged engine.

Smart detection: catching the misnamed upload

Anyone who takes files from dealers knows this failure mode. The customer uploads a slave file and marks it as a master. Or renames it something helpful like golf.bin. Or attaches it under the wrong job type entirely. You do not find out at upload time — you find out ten minutes into the job, when something does not open the way it should.

The portal checks what the file actually is rather than trusting what it was labelled. A slave file is recognised as a slave file regardless of the box the customer ticked or the name they gave it, and the job is corrected on the way in. The customer is not punished for a mistake they did not know they were making, and you do not lose ten minutes discovering it.

AutoTuner metadata: the customer's job fills itself in

AutoTuner slave files carry useful information about the read inside them — the vehicle, the ECU, how the read was taken. The portal pulls that out at upload time and uses it to populate the job.

The effect on the customer's side is the one that actually wins you dealers: submitting a file becomes faster and less error-prone, because the details they would otherwise have to type — and get wrong — are already filled in from the file itself. Combined with reg-plate lookup on the vehicle side, a dealer can go from "I have a read" to "the job is submitted" in seconds, with clean data attached.

And clean data at intake is not just a nicety. It is what keeps your WinOLS project library searchable in two years' time, which is the asset that makes donor matching work at all. Sloppy intake today is a manual job in eighteen months.

What this actually saves you

Be sceptical of round numbers in marketing, so here is the honest shape of it rather than a headline figure.

• The handling time per job goes to roughly zero. The download-open-login-upload-wait-download dance on both ends of the job is the specific thing being removed.
• The waiting stops being your problem. Decode time still exists, but it happens while you are asleep, driving, or working on a different car — not while you watch a progress bar.
• Turnaround improves without you working faster. The file is ready the moment you look at it, so the clock the customer experiences starts at your first useful action rather than fifteen minutes of admin later.
• An entire class of mistake disappears. Un-encoded returns, wrong-file uploads, and mixed-up originals are handling errors. Remove the handling and you remove them.
• Evenings get shorter. The jobs that land at 5pm are decoded and waiting at 5:01pm rather than starting a fresh round of admin at the end of a long day.

The compounding version of that: a shop doing ten slave jobs a day, spending fifteen minutes per job on pure handling, is spending over two hours a day on work that no customer has ever been charged for and no tuner has ever enjoyed. Whatever your real numbers are, run them — the arithmetic tends to be uncomfortable.

Which tools are supported

Straight answer, because vague answers here waste everybody's time:

• AutoTuner — supported. Automatic decode on the way in, encode on the way out, plus metadata extraction from the slave file at upload.
• Alientech KESS3 — supported. Automatic decode and encode through your own Alientech account, covering OBD and bench/boot reads.
• Magic Motorsport — coming soon. Recognised by the portal today, but not yet automated. We would rather say "not yet" than ship something half-working into the middle of your workflow.
• Other tools — files are recognised and handled as slave files, but automated decoding is not claimed. More tools are on the roadmap.

You will need your own account with the tool vendor. RemapDash does not resell, sublicense or replace any tool vendor's software or credits — the bot uses the account you already have, on the machine you already use.

Frequently asked questions

Go deeper

• WinOLS LUA scripting explained — what the automation actually is, what it costs from EVC, and why it is not "AI tuning".
• What is WinOLS? — the editor at the centre of the workflow.
• What tuning file portal software does — the whole picture around the bench.
• Software terms & automation disclaimer — the plain-English rules our automation ships with.

AutoTuner, Alientech, KESS and Magic Motorsport are trademarks of their respective owners. RemapDash is an independent portal-software provider and is not affiliated with or endorsed by any tool vendor. Automation runs using your own tool account and licence; you remain responsible for compliance with your tool vendor's terms, and for checking every file before it is flashed to a vehicle.