Vertical Press Brake interface and comp

Greets - with some chatter on the mailing list, I have uploaded the pre-final project for a pressbrake conversion I did a couple (4-5!) years ago. The unit was an Accurpress 25Ton (40") that originally had a Win98 custom interface and used a Yaskawa motion controller on the back end. After about 4 years of backups, rebuilds, chewing gum and prayers of getting the Win98 SBC to keep going, it finally gave up. Repair was quoted as more than the new cost of the press brake (!) Thus a conversion project was started.
The ram is run as a servo axis with full PID along with the 2 axes of back-gauge. I retained the 2 yaskawa servos and drives (running in velocity mode) and the ram had a Vickers proportional valve on it so everything ran as /-10v with the new Mesa hardware. The ram had glass scales and the servo drives returned encoder feedback. 3 modes were designed to replicate the prior control (without duplicating it verbatim) - jog/manual, semi-auto-repeat and fully auto. The jog/manual is the most often used mode by the operators as they really like to air-bend "hands-on" - press, clear, measure, repeat. All the technology is a little overkill for such a practice, but they are quite comfortable with it. The "semi-auto" mode allows an operator to do a similar workflow as manual, but "grab" the setpoints (or adjust via clicks or typing) then run the pedal to that point (includes safeties, dwell, overbend and daylight clearing to whatever they prefer). The fully automatic mode was simply to load and run g-code, which we expected to be hand-written. If I were designing this for commercial sale, I would like a wizard here - however of the multiple press brakes this client has, the operators all despised any type of knowledge-base / load cad data / use wizards - etc. And they did not like the idea of sequencing - one bend, one side, all the parts. Thus, the fully-auto or sequence capability was never finished. Also due to a work interruption, we didn't complete the pressure and temp alarm scaling, so those numbers don't match their charts - which they also don't care about, since they typically air-bend and not bottom-bend, so running to force limit is irrelevant, it's just a safety consideration.
Note that this is the "pre-release" version- it is functional in the field on this actual machine, on older (pre 2018 hardware) so it won't work for you as a download (no sim-mode here) without a lot of editing - but as a reference, you're welcome to evaluate. Most of the effort would be attaching physical hardware of your scenario.
As a side note, I went through about a dozen iterations of glade and comp concepts in the course of the 6 month initial development - some aesthetic, most changes functional. Originally I wrote a big "do it all" component to handle the ram and state-machine its way through a process. As it turns out, this was a very rough way to do it - the output was rough in its response (jerky). This release uses motion on all 3 axis, and treats them as 3 axes. If I had a suggestion to give myself at the beginning it would definitely have been: stick with the existing MOTION component - it is so well written and stable that there is little value in wasting your time trying to replicate but avoid it. I originally thought that it would not be viable to feed simple sequences with interrupts into motion using g-code files however it works and works well. From that, it automatically gave me the ability to run any gcode, so if they want fully auto mode, they just edit some gcode.

Regards,
Ted.

hey! i tried installing this, as i have 2 old pwm based press brake (1m and 3m)

i also have a tonnage gauge, which should be output by the pwm generator. i have A/, B/ , A and B 5v encoders used on a 7i92tm + 7i77 config.  Are you comfortable discussing this further privately? I understand and respect that your counsel is worth its due. Thanks.