Groundwork for replacing a Telesis pinstamp with a SIC Marking e10 while
keeping the existing eDNC/MarkTelesis operator workflow. MarkTelesis has a
hardcoded marker-type enum and eDNC is serial-only, so the plan is a
translator that impersonates a Telesis controller on a COM port. These are
the pieces that translator will be built from, all verified against a real
e10 (a P63, firmware "E10 P63 (20140924)").
scripts/e10-client.py
e10-V6 protocol client. Marking path and file transfer both use the BINARY
protocol: the text protocol uses space as its delimiter, so it cannot carry
a field cleared to a single space nor the space runs in real marked text,
and it has no checksum. Includes fault decoding against the manual's fig 1,
and a guard that refuses to overflow a variable's declared buffer.
scripts/make-e10-pattern.py
Builds marking files with DECLARED variables. The controller's own protocol
cannot create one: NEWFILE/INSERTTEXTLINE/SAVEFILE writes the reference but
leaves the variable count at zero, and SETVAR then fails. Template-based,
copying through byte-for-byte everything the format notes do not explain.
scripts/simulate-ednc.py
Parses a part program, substitutes tokens and emits the byte-exact frames
MarkTelesis would send, then translates them for the e10 and can drive one.
The wire format came from disassembling MarkTelesis.exe rather than from a
capture: frame builder at 0x401cf0, and the type letters at their call
sites. Note there is no station ID, unlike the Backup470 dialect.
scripts/fake-telesis.py
Answers as a Telesis controller so MarkTelesis will hold a conversation
long enough to be recorded, with switches to force NAK and timeout paths.
reference/e10/
52-file snapshot off the bench controller, used as the corpus for reversing
the MARK_V5.0 format and for testing without hardware. ConfigCtrl is
excluded and gitignored - it stores the supervisor password in cleartext.
GE part programs are excluded for the same reason.
Three hardware findings worth knowing:
- The controller TRUNCATES SILENTLY to a variable's declared buffer size
while SETVAR still answers ok, and GETVAR echoes the full value back so
it cannot detect this. Guarded client-side against the size in the file.
- It refuses to mark when a referenced variable is unset, which makes an
unset field fail loudly rather than marking the previous part's data.
- Setting variables does not modify the stored file, so backups will not
churn on every marked part.
1.4 KiB
SIC e10 reference snapshot
Pulled off the bench controller (a P63, firmware E10 P63 (20140924)) on
2026-08-27 with scripts/e10-client.py backup. 52 files: marking files,
scribble logos, and the controller's own config files.
Used as the reference corpus for reversing the MARK_V5.0 marking file format
and for testing the e10 client without hardware attached.
Deliberately missing: ConfigCtrl
ConfigCtrl is the controller configuration file. It stores the programmer
and supervisor password in cleartext, so it is not in this repo and must
never be committed. It is kept outside git at
~/pxe-images/e10-ConfigCtrl-2026-08-27.kind1, mode 0600, following the same
convention as the other site-sensitive artefacts (ADR-015).
.gitignore blocks ConfigCtrl* and *.kind1 under this directory so a
future snapshot cannot reintroduce it by accident.
This has a direct consequence for the backup design: any e10 snapshot that includes the controller config contains a live credential. Whatever ACL protects the partmarker backup tree on the share has to account for that, and the ShopDB asset panel must never render the file's contents.
Part programs
GE part programs are NOT in this repo - they carry part numbers and marking
content. They live outside git at ~/pxe-images/e10-testing/partprograms/,
alongside the testing README. .gitignore blocks the path here so one cannot
be added by accident.