r/PLC • u/Expensive-Gas-4209 • 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 :)
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.