Over the last year, many Titan 25T users — including myself — have discussed recurring software frustrations, missing quality-of-life features, inconsistent alarm handling, UI quirks, controller instability, and various reliability-related issues across multiple forum threads. Like many others here, I initially kept hoping these issues would eventually be addressed through official updates.
One of the recurring issues I personally experienced was the controller system itself. The stock Orange Pi 3B setup felt underpowered for the application, and I also experienced repeated SD card corruption issues over time. Because of that, I eventually replaced the entire controller computer with a significantly more powerful Orange Pi 5 system with 16GB RAM, an M.2 SSD for the main operating system/storage, dedicated eMMC boot storage for the bootloader, and additional backup/data redundancy improvements. That process pushed me much deeper into understanding how the Titan software and controller architecture actually works internally.
A few days ago, after running into several software limitations again during actual production work, I decided to spend even more time digging deeper into the system to see whether some of these long-standing issues could realistically be improved from the software side.
That process ended up turning into a much larger project than I originally expected, which also brings me to the main reason for this post: I would like to clarify the legality and permissions around potentially sharing modified firmware and application files for the Titan 25T with the community.
I run a technology company myself and develop/sell industrial equipment to customers in the education, medical, defense, and technology sectors, so I fully understand the importance of protecting proprietary software, intellectual property, and product liability. Because of that, I do not want to release anything publicly without first hearing from Langmuir or someone from the management/development team regarding what is permitted.
Over the last few days, I spent time analyzing the controller firmware and the BendControl software to better understand the system and address several long-standing issues that many users have discussed on this forum. During that process, I was able to reconstruct and test a nearly complete working controller codebase and verify functionality through simulation and live testing, including alarm handling, sensor I/O behavior, UI behavior, and motor control logic. So far, everything appears to be functioning correctly in testing.
Normally, I do not pay much attention to the equipment I use daily as long as it gets the job done. However, this press brake for some reason pushed me to dig much deeper into it because I genuinely see great potential in the machine itself. In my opinion, most of the frustrations users experience come from software limitations and a few minor hardware iterations rather than the core mechanical platform.
Before publishing anything, I think it would be fair to first ask Langmuir and @langmuir-sam whether they would allow a community-supported modified firmware/application project intended to improve stability, usability, and bug fixes for out-of-warranty machines.
Of course, any such project would include clear disclaimers stating that:
-
custom firmware/software is used entirely at the user’s own risk,
-
warranty coverage may be void,
-
neither Langmuir nor community developers would be responsible for damage, injury, or misuse caused by modified software.
For reference, I attached a screenshot from an automated alarm-code testing application I built during development/testing.
I will glady pay to you to make available ANY improvement in this janky UI.
. I had to desolder it from the controller and transplant a new one from a regular Arduino Uno R4 Minima to fix it. It was such a fun thing todo while not managing to damage anything else on controller PCB 
. Luckily it is in working condition now.