Some internet jerk made a snide comment today about someone else’s light-hearted Linux install project. It shouldn’t have stuck with me, but it did. It woke me up hours later with a thought I couldn’t shake:
They’re all the same.
For the past few years I’ve been building my own PLC communication libraries — serial, USB, TCP — in Python, C/C++, JavaScript, PHP. In the last 24 hours I’ve been writing Kotlin because I want a field tech to be able to debug a PLC from their phone, even if the PLC doesn’t have Bluetooth. No PhD. No formal CS background. Just me, a hex editor, and the habit of staring at binaries until the patterns start to move.
I’ve got a small collection of PLCs to experiment with — mostly IDEC, plus a few Siemens, Keyence, Mitsubishi. When I want to understand something, I don’t wait for permission. I open the firmware, trace frames, XOR checksums by hand, and squint until the Matrix resolves. That’s how I dug into IDEC’s Maintenance Protocol. I’ve mapped most of it. I still haven’t fully cracked firmware writing or compiled bytecode translation, but I’m close.
Then something weird happened.
I was experimenting with a Keyence KV series PLC my employer provided. By accident, I ran some IDEC code against it.
The LEDs toggled.
That shouldn’t be possible.
So I ran it again.
There it was: IDEC’s Maintenance Protocol responding on a Keyence KV-1000.
That sent me digging. I looked for documentation. Nothing useful.
Every OEM wants you locked into their bloated, feature-starved software.
So I asked ChatGPT what PLC communication protocols are linguistically similar to “Maintenance Protocol.”
The answer?
All of them.
Mitsubishi MELSEC. IDEC Maintenance. Keyence KV. Siemens S7. Schneider Electric. And probably the rest. I haven’t tested the GE units yet — the ones I have are temperamental — but I’m not expecting surprises anymore.
The structures match. The framing matches. The checksums match. Even the command semantics echo each other.
And here’s the funniest part: there’s a typo. A small framing typo that has survived for roughly forty years. It appears in every document from every vendor. Same sentence. Same mistake. Never corrected. It’s like a fossil record of copying.
Near as I can tell, someone named Petr John, defined a protocol that was likely meant to be open.
Over time, industrial OEMs cloned it, rebranded it, redistributed it, and quietly erased source attribution.
Every one of them claimed it as thier own uniqe protocol. The memory mappings might differ, but the language is the same.
What’s fascinating is that nobody fixed the typos.
Four decades. Dozens of manufacturers. Identical typologcal error.
They’re all the same.
I started this because I wanted to build tools that help techs in the field.
I don’t want to drive out for service calls just to flip a bit.
I want clean, simple, useful software anyone can use.
I didn’t set out to reverse engineer the entire industrial controls ecosystem.
But once you see it, you can’t unsee it.
n
The protocols are the same.
The framing is the same.
The semantics are the same.
Even the typos are the same.
When I finally finish mapping byte-code to instructions and build an open instruction compiler,
It’ll just be the same thing running everywhere else.
Find the TYPO!
https://dl.mitsubishielectric.com/dl/fa/document/manual/plc/sh080008/sh080008ab.pdf
https://docs.galco.com/techdoc/idec/fc4a_protocol_im.pdf
### Good docs are hard to come by, but when i find the other again Ill post them.
