Ursviken Pullmax Optima 130 press brake retrofit with 4 axis backgage

I am working on an Ursviken press brake retrofit to LinuxCNC and decided to document my progress etc here, and probably ask questions along the way. If you have any hints or advice for me, feel free to say so.

This press brake came with a Compaq pc booting some form of MSDOS and a Mitsubishi FX-64M PLC. The press brake had been forgotten in a warehouse for who knows how long until the current owner ended up buying it. After installation in the shop, upon first power-up, it complained of a depleted PLC battery. Sadly, the new battery didn't recover the lost memory. After multiple unsuccessful attempts to get Ursviken to get the thing working again, they showed me this project. I said I think I can make it run on LinuxCNC.

I pulled the PC and the PLC and installed a "Fanless industrial mini-pc" with 4 ethernet ports. For i/o I am using Mesa 7i80HDT + 7i36 + 7i54 and Beckhoff ethercat EL1409 16-inputs and EL2409 16-outputs.

Original 10 axis configuration was:
Y1 and Y2 = left and right ram (top die height)
X = backgage forward/backward motion
R = backgage up/down motion
Z1 and Z2 = independent left/right motion of the two backgage fingers.
Crowning: This feature currently has a mechanical malfunction so the customer asked me if I could leave crowning as an option for later if he decides he wants it. I said yes.
VDT = variable width bottom die, appears to have been present on the machine at some point but was apparently deleted.
PSB and PSA = automatic sheet lifter with a height axis and an angular axis. My customer requested to remove that because it will be in his way more than he uses it.

Target configuration:
Y1, Y2, X, R, Z1, Z2, and optional crowning. Y2 is slave of Y1. Z1 and Z2 are independent, except they run on the same rail and must not collide.

I see this machine has tonnage control, but I do not find any electronic pressure feedback sensor on the hydraulic system. It does have two servo valves, one for each side, plus an electronic proportional valve for the entire hydraulics. The servo valves appear to pertain to motion speed for each side. I wonder if the proportional valve sets the tonnage? It might get interesting driving that proportional valve with a DC servo motor output. I plan to limit it to one polarity only and try to modulate it to about 50hz PWM. I think it might work to use a software pwmgen running at 50HZ in hal to set the hardware pwmgen to either 0% or whatever pwm % is the max mA rating of the valve coil.

X and R axis each have a Baldor 90VDC servo with tachometer feedback to the Cybelec servo amps and encoder feedback to the PC controller. The Cybelecs' drive power is set with +/-10VDC from the 7i36 card.

I will try to power the servo valves and the proportional valve using the DC servo outputs from the 7i54 card.

Z1 and Z2 axis are DC worm drive motors powered by fwd/rev contactors and basic encoder feedback to the PC.

Crowning is a common AC 3 phase induction motor on a worm gear box driving an ACME lead screw protruding from the left side of the bottom bed. It is powered by a fwd/rev contactor.

I'm trying to figure out my options for homing everything. Originally my plan was to launch it with:
cd /home/titus/linuxcnc/configs/pullmax
halrun -I -f config.hal

within that hal I load everything else including:
loadusr gladevcp -Wn pullmax -H ui.hal pullmax.ui
also hostmot2, mesa, ethercat, etc.

This leaves me without motmod (motion), homing, etc. It is just a simple Glade + hal app.

I would like to use the full linuxcnc system instead of writing my homing and slave axis (ram control) from scratch. Maybe avoid reinventing the wheel.

I am currently studying how to load everything with like:
cd /home/titus/linuxcnc/configs/pullmax
linuxcnc pullmax.ini

Progress is coming in small increments. Currently struggling to get past this:
USRMOT: ERROR: command timeout
emcMotionInit: emcTrajInit failed
Waiting for component 'inihal' to become ready............USRMOT: ERROR: command timeout
emcMotionInit: emcTrajInit failed

full error attached
the ui comes up and works (I only got the position readouts hooked up at this point and encoder scales all at 1.0, servos all disabled yet, bumped each axis with my hands and got counts.

I'll keep poking at it. I'm learning as I go.

That helps. I had seen the extra joints feature but didn't know enough about it to realize that is what I need.

Progress at this point:
I used Pncconf to create a common 3 axis mill config with the default mesa cards selected, as my mesa setup does not seem listed. I edited the generated mesa configs to:
1. Match my mesa hardware.
2. Converted the XYZ axis to simulated by zeroing their [JOINT]HOME_ ini parameters and connecting their pos_cmd to pos_fb.
3. Created 6 'extra joints' that I will actually be using.

I still have not figured out how to delete the axis gui without breaking a boatload of stuff. I begin to think I will be fine with allowing axis to load minimized, and have my gladevcp ui load maximized, and maybe also modal so it stays on top. It will be most convenient for the machine operator if my gladevcp never disappears from his touchscreen. I think he knows more about bending steel than I do about computers.

I think I begin to see into how this 'extra joints' command flow works.

1. My ui will trigger homing via a "Home all" button. NOTE: Y1 and Y2 will need footpedal operation to complete the ram homing and they home simultaneously.

2. When homing is complete, the joint.5.homed pin enables the j5.limit3.enable to enable program control of that servo.

3. My ui sends a position to j5.limit3.in then j5.limit3.out feeds joint.5.posthome-cmd. This seems to be a position value (not velocity). If I am correct, that is what I need here.

4. The position from #3. feeds straight through to joint.5.motor-pos-cmd into j5.pid.input

5. j5.pid.output is a velocity command driving hm2_7i80.0.pwmgen.00.value

6. Feedback is in the form of hm2_7i80.0.encoder.00.position to joint.5.motor-pos-fb and to j5.pid.feedback

I attached a flowchart of this for reference.

You made my day. I had tried everything, including this, but that was in the broken config I was trying to produce from scratch by hand. (And no, I didn't ask ChatGPT. Maybe I should have. For now ChatGPT is fired as long as I don't know what I'm asking for.) I tried this on the new config I started with Pncconf and it just worked:

in my pullmax.ini I have under [DISPLAY]:
DISPLAY = halui

and under [APPLICATIONS]
#APP = halcmd loadusr -Wn pullmax gladevcp -c gladevcp -H ui.hal -x {XID} pullmax.ui
#APP = halcmd loadusr -Wn pullmax gladevcp -H ui.hal pullmax.ui

Wow! how did that work? I forgot to uncomment the second line. Tested it a bit, it also works fine if I change it to what I originally intended, and my ui does not come up if I delete the two commented lines. Each time, I am starting it from the terminal and am seeing the normal chatter, but no warnings or errors. My ini file now has:

[APPLICATIONS]
APP = halcmd loadusr -Wn pullmax gladevcp -H ui.hal pullmax.ui

Now I think I am prepared to wire up closed loop operation for each axis...
 

For a bit I made poor progress tuning the R axis. No wonder, it has a brake in the servo and I overlooked that. Yesterday I had a bad day with that little brake. I was manually driving that axis closed loop by setting j6.pid.command and j6-unlock via halcmd in a terminal. I parked it with the brake locked, jiggled pid.command around till pid.output went to 0.0000 then looked at my brake hal logic....

About 2 hours later I was submerged in hal logic. 30 feet away a guy was welding. Somewhere in the back of my mind I'm blaming him for welding through paint. 5 minutes later the boss comes worrying. "I smell hot wires!" He stuck his nose in the big cabinet... nothing there. He walks around the back of the press. Phew! I hit e-stop, cutting power to the servos, but that nice old Baldor DC servomotor is now junk. Good thing I earlier forbade the boss from promptly scrapping the PSA and PSB axis. It had an identical motor.
It appears the brake had at some point allowed the axis to drift down about 7 encoder counts. At that point the pid slowly wound up but the motor was unable to fight the brake back to 0.000 position and gradually overheated and then smoked.

I now have hal logic automatically operating the brake for me. But it is interfering with the homing. I just now saw into it: my servo enable after brake release delay must be slightly too long. Homing starts then after my 0.1s delay the pid has some catch-up to do and overshoots just enough to fault the homing sequence.

I'm attaching my complete config. Most of the working part of it at this point is joint 6 (almost working). More to come...

Does not seem to be my brake logic. Now I have it searching for home slowly for several inches. It touches home then my pid.output slams in reverse, pulling back off the home switch then I get this error:
Home switch inactive before start of backoff move j=6

Ah-ha! This must be something with pid tuning. I suspect my I-gain is too low. And maybe I need to give it some D-gain.

My brake logic is (if I'm correct) straight passthrough during joint motion. The only exception is the enabling period at start of motion (currently 0.05s) and the parking after 10s of no axis motion.

edit: More than anything else, looks like MAX_ACCELERATION was way too high.
Another problem was the homing is not finding the encoder index, disabled the home-to-index for now.

Now I got joint 6 homing. Needed to make some polarity corrections to HOME_SEARCH_VELOCITY and HOME_LATCH_VELOCITY. Next problem: I command it to go to R 0.000 and it goes to R -0.7683 instead, showing -0.7683 on the gui and that is also where it seems to be at when I measure the physical joint position. This is the motor offset value that is being set during homing. Looks like I need to sort out in my config which value is "raw axis position" and which is the "user friendly value"

This did it: I adjusted HOME_OFFSET so I could command 0.000 and have it go to 0.000
To correct the joint position readout in the gui I moved its hal pin from hm2_7i80.0.encoder.00.position to joint.6.pos-fb

I think I should update my axis control logic to fault after a timeout of n.nn seconds of greater than n.nn minimum servo amplifier power and less than n.nn minimum joint velocity.

I ran into a situation where the encoder reading was incorrect, joint 6 was cranked against + hard stop, and the motor was holding stalled at max power.

This sounds like a bad way to fry a DC Servo, and we no longer have a spare. This axis has limit switches wired to the servo amp but not to LinuxCNC; I'm surprised the servo amp did not disable. I would spend more time diagnosing that; however, Cybelec couldn't provide manuals to me for these amplifiers because I am outside of their service region. Also, this is the ONLY axis on this machine with limit switches and the reason why I chose to move this one first. Plus, I think I will need to look into hard stop homing for Z1 and Z2, those have no homing or limit switches; only encoder feedback.

I see I need to fix my brake logic: I've been noticing glitches in joint motion and have discovered that when I am moving the joint slowly for longer than my servo-to-brake delay, it will lock the brake momentarily then release it again. I will just need to have it monitor several values besides j6-pwm-cmd. I'm thinking velocity feedback and distance-to-go. This will be directly related to the timeout logic above.

Once I get it right I want to rewrite it in a custom hal component which I plan to reuse on additional joints. The other joints with no brake probably need a parameter to switch off the unlock feature so it does not use the servo enable delays and cut servo amp output during no motion.

The R axis motor gets hot if it has to hold the axis against gravity for extended periods.