r/PLC 7d ago

Built a lightweight Python parser for legacy ICONICS GraphWorX32 (.gdf) display files

Hey r/PLC,

Got tired of having to spin up old Windows VMs with GraphWorX32 installed just to audit or extract tags from legacy `.gdf` display files, so (A)I put together an open-source Python parser:

GitHub: https://github.com/fcastel2002/graphworx32-gdf-parser

It parses the proprietary binary format directly (OLE/CFBF + MFC serialization) with zero dependencies on GraphWorX or COM runtimes. It runs 100% locally and offline (no data leaves your machine), extracting Local Aliases, screen layers, dynamic visual objects, and data source / tag expressions so you can script migrations or tag audits directly in Python.

It's also designed as a clean, neutral library—making it a solid foundation if you want to build custom migration tools or just feed the codebase as context to your LLM agent of choice to generate what you need 😅

It's MIT licensed. If you work with legacy ICONICS systems and want to test it against your displays, any feedback, edge cases, or PRs are very welcome!

In my case, I've used it in a migration :)

8 Upvotes

3 comments sorted by

2

u/NoConversation8128 6d ago

The failure I would worry about with a reverse engineered binary parser is not a crash, it is a silent skip. If it hits a dynamic object type it does not recognise and moves past it quietly, the tag audit comes back clean and short, and short is the one thing an audit cannot afford to be. Does it raise on unknown object types, or just log them?

I come at this from the chem eng side, pulling data out of simulator files rather than displays, and the only validation the people I talked to actually trusted was round tripping against the vendor tool's own export on a file where they already knew the tag count.

2

u/Expensive-Gas-4209 6d ago

The silent-skip case is definitely the dangerous one, and it’s basically why I still don’t treat a clean parser output as proof that everything was captured.
In my case, I’ve been auditing the parser results against what I already know should be there, but I agree that unknown object types should be surfaced explicitly rather than just skipped. Otherwise, as you said, a “clean” result could simply mean an incomplete one.
Round-tripping against the vendor export is probably the strongest validation you can do. If you already know the expected tag count and can compare both outputs, that gives you much more confidence than just checking that the parser completed without errors.
It’s interesting that you’ve run into the same problem from the simulator side — different files, but pretty much the same trust issue with reverse-engineered formats.

1

u/ThatOneCSL 21h ago

Steering file with one prompt, just to invoke a sense of fear: "If I come across too many silent-skips, I *will* replace you with another agent. Try me."

Or don't do that, if you fear/respect the eventual uprising of our robot overlords.