How to Convert Zuken E3.series VBScript to Python

If you automate Zuken E3.series, your scripts are almost certainly VBScript, and sooner or later you'll need to convert them to Python. Microsoft is retiring VBScript from Windows, and Zuken now names Python as its preferred replacement. This guide covers the dates, what really changes in the code, and a way to plan the move that does not put your drawings at risk.

The dates, and how firm they are

Microsoft deprecated VBScript in October 2023 and set out three phases in May 2024.

Phase 1, now From Windows 11 version 24H2, VBScript is a Feature on Demand that is installed and enabled by default. Your scripts still run.
Phase 2, around 2027 The feature stops being enabled by default. Microsoft has also written “approximately 2026 or 2027” elsewhere, so treat the year as a guide rather than a promise.
Phase 3, no date VBScript is removed from Windows. Microsoft's wording is that its DLLs will be removed and “projects that rely on VBScript will stop functioning”.

Phase 2 is the one to plan around. On the day a new laptop or a Windows feature update arrives with VBScript off, the add-on menu stops working for that user. IT can switch the feature back on, which buys time. It does not change where this ends.

What Zuken has said

Zuken's position moved over 2026. In January its US blog said it “does not promote a specific scripting language for the E3.series API” while advising users to plan a conversion “before it is too late”. By September, writing about E3.series 2027, it said “Python is the preferred scripting language for E3.series”.

The practical support is already there:

An official package, e3series, published on PyPI by Zuken E3 GmbH. It is a typed wrapper around the same COM interface VBScript uses.
A matching package for each product release since E3.series 26.10, according to Zuken.
Python examples alongside VBScript in the E3.series help from the 2026 release.
A public repository of examples covering setup, add-ons, printing to the message window and common problems.

Zuken also runs a Python scripting course and offers conversion help of its own, which is worth knowing if you would rather train your team than hand the work out.

What changes in the code

The object model does not change. You still create a job object, ask it for IDs and point device, sheet and pin objects at them. Here is the same loop in both languages.

VBScript

Set e3 = CreateObject("CT.Application")
Set job = e3.CreateJobObject
Set sheet = job.CreateSheetObject

count = job.GetSheetIds(ids)
For i = 1 To count
    sheet.SetId ids(i)
    e3.PutInfo 0, "Sheet: " & sheet.GetName
Next

Python

import e3series

e3 = e3series.Application()
job = e3.CreateJobObject()
sheet = job.CreateSheetObject()

count, ids = job.GetSheetIds()
for sheet_id in ids:
    sheet.SetId(sheet_id)
    e3.PutInfo(0, f"Sheet: {sheet.GetName()}")

It looks like a tidy one-to-one translation. Four differences hide in it, and they are where converted scripts go wrong.

1. Output parameters come back as a tuple

VBScript passes ids by reference and the call fills it in. Python has no call by reference, so the package returns every output alongside the return value: count, ids = job.GetSheetIds(). Any call with an out parameter needs its line rewritten, not just its brackets added.

2. Arrays are 0-based, and the dummy first element is gone

E3.series hands VBScript arrays whose first element is empty, which is why every loop you have starts at 1. The Python package removes that element and gives you an ordinary 0-based tuple. A loop ported as for i in range(1, count) skips an item and raises no error. Iterate over the tuple directly and the problem disappears.

3. On Error Resume Next has nowhere to go

Plenty of E3.series VBScript leans on On Error Resume Next to carry on past a failure. Python has no such switch. The interface still reports most failures through return values, so the honest translation is to check those values, and to use try and except for the things that now raise, such as connecting when no E3.series is running.

4. There is no “internal” script any more

The usual VBScript helper checks whether it is running inside E3.series and either uses the host or creates CT.Application. Python always runs as its own process. e3series.Application() looks at the processes that started it and connects to that E3.series window, so a script launched from the add-on menu lands in the right project even with several copies open.

One more to watch The enums in e3series.types are helpers. Zuken's notes say you pass Enum.value to the call, not the enum itself.

Messages and print

PutMessage and PutInfo work as before. The package also lets you redirect Python's own output to the E3.series message window, which makes scripts easier to write and to debug:

import sys
import e3series
import e3series.tools

e3 = e3series.Application()
sys.stdout = e3series.tools.E3seriesOutput(e3, sys.stdout)

print("This appears in the E3.series message window")

Getting Python onto users' machines

This is the part VBScript never asked of you, because the interpreter came with Windows. Zuken's guidance comes down to a few points.

Set the add-on up with pythonw.exe as the command and the script path as the argument. pythonw runs without a console window. From E3.series 2027 an administrator can define a default interpreter instead.
Use a virtual environment and point the add-on at its interpreter, so every user has the same package versions.
Do not install Python from the Microsoft Store. Zuken's advice on that is three words long: “Don't do it.”
Pin the e3series version. Its changelog shows array handling being corrected function by function across several releases, so an unplanned upgrade can change what a call returns.

A plan that does not break production

Take an inventory List every script behind the add-on menu and every trigger. Note who uses it, how often, and which shared files it includes. Scripts nobody has run in two years can be retired instead of converted.
Rank by risk, not size A script that writes to the project or produces a manufacturing document is higher risk than one that only reports. Start with something small and read-only.
Capture what the VBScript does today Run each script on a fixed test project and keep its output: the cut list, the BOM, the log. That output is the specification.
Convert the shared helpers first Connection, logging, attribute lookups and settings files usually sit in a few common files. Port those once into a module and every later script gets shorter.
Compare old against new Run the Python version on the same test project and compare the output with what you captured. A difference is either a porting mistake or an old bug you have just found. Decide which before moving on.
Run both for a while Keep the VBScript entry on the menu next to the Python one until users have been through a full release cycle on the new version.

When to start

Nothing stops working this month. The reason to begin now is that the date you lose VBScript is not one you control. It arrives with a Windows update or a new PC, and the conversion is far easier to do well while the old scripts still run and can be used as the reference.

Rather not do this yourself?

I write and maintain E3.series scripts for wire harness manufacturing, and I convert E3.series VBScript to Python as a service, tested against the originals.

See the conversion service Get in touch

Sources

James Bowen is an independent developer and is not affiliated with Zuken. E3.series is a trademark of Zuken. Dates were checked against the sources above on 5 October 2026 and may change. Code samples show the pattern; check them against your own E3.series version before relying on them.