eb4d067f12
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.
32 lines
1.4 KiB
Markdown
32 lines
1.4 KiB
Markdown
# 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.
|