Ursviken Pullmax Optima 130 press brake retrofit with 4 axis backgage

PCW wrote:

If the encoder counts, its unlikely the index would be missed as the hardware
index processing uses the same digital filter as the A and B signals.
 

Thanks for the nudge in the right direction. I took another look at things and discovered my mistake: I was incorrectly watching for index-enable to go high on index. I went and manually set it high and sure enough, on index, it cleared. Problem solved.

Thinking aloud trying to wrap my brains around the ram motion pedal interlocks.

1. The ram must never go down unless the operator steps on the pedal.

2. After an e-stop reset it must 'ignore' the first time he steps on the pedal.

3. There are 6 electro-hydraulic spool valves and two servo valves, plus a tonnage regulator.

4. Homing requires use of the foot-pedal. It is ok for the ram to go up while the foot-pedal is depressed.

All valves must coordinate in the correct sequence or we dead-head the pump and stall the 18kw electric motor like right now. It is already doing that when I power the creep-up motion. Maybe I am opening the servo valves too far in creep up. Probably also the tonnage proportional valve. It appears the creep up hydraulic circuit is flow-limited by an orifice.

Up/down motion is primarily selected by reversing the power on the servo valves, secondarily by routing the flow with the correct combination of spool valves.

Valves 6.1, 7.1, 9.1, 10.1 plus servo valves 4.0, 5.0 drop the ram fast using gravity.
Valves 8.5, 8.1, proportional valve 8.4, and servo valves 4.0, 5.0 provide slow down with tonnage for bending the plate.
This constitutes every single hydraulic valve solenoid coil on the machine. Up occurs using most the same coils in a slightly different combination.

I begin to think this has to happen in hal. I wanted to hardwire that one, but I see it will be really hard to accomplish. On the part of the Ursviken schematic I had sort of figured out does that, upon closer study, I see it strictly only locks out all motion when the foot-pedal malfunctions and commands up and down motion simultaneously. The old computer directly powered the servo valves with an analog h-bridge card; that circuit was interrupted only by e-stop... and NOTE! I see the up-order button for the ram bypasses the e-stop circuit. I think it would be a really good idea to hardwire that feature back in.

Currently, I have e-stop cutting power to all drive systems, including the 18kw pump motor. Now I need to decide whether A: the motors stays running after e-stop so up-order still works; or B: up-order momentarily powers the pump motor to power the ram UP.

I think B makes more sense. Anyone have better ideas, or comments, etc?

I think a custom hal component will be the ticket for this ram control. I envision a glade user interface, separate reusable custom components for each backstop axis, and a custom component for the Y axis (upper beam height control.)

Different brands of press brakes would get their own  Y axis component, due to complicated variations in hydraulic configurations among the different makes and models.

Bend programs will be loaded in the python userspace gui app as a list of dictionaries containing positions for every single axis for the machine.

Stage two of my dream will be to write a python based app allowing the user to enter dimensions and angles, then create the bends file that the press gui can load.

Attached preliminary work, don't try running this one, it is incomplete yet.

Been poking at this a bit, finally got new ideas on this servo valve height control setup:

The servo valve pwm signal is basically a 'power' level command.
 The user interface commands position orders at more or less adjustable velocity.
 My PID controls position... I thought I might use pid.max-limit to control the velocity, but I do not expect that to work well for controlling non-linear hydraulics.

Aha! I think a second PID will serve the speed control. I have to try that.

Almost got my pullmax component ready to test...
Wait... something is wrong. I have my pullmax component reading outputs from the GUI, then it is activating spool solenoids to enable operation in the correct direction, and commanding joint.nn.posthome-cmd a position. We can't home the ram in this configuration. Attached a drawing of what the config looks like. The pullmax component does not know if/when to activate the spool valves when homing is in progress. I have that part of it too high in the control loop.

I considered just giving it a pin to also monitor the homing state and joint.nn.motor-pos-cmd but pretty soon I will have a bunch of spaggetti code.

I think I will split my pullmax component into two components:

component press-state will be the press-brake state machine

component pullmax-optima will go between joint.nn.motor-pos-cmd and the position-pid.command, allowing it to monitor the polarity of the command (and probably also the footpedal) to set the direction command at the spool valves, while the PIDs will continue to command the proportional valves.

I think this is the goal.

Face-palm moment! 

No need for homing the ram... I think. All I need is set hm2_7i80.0.encoder.04.index-enable then have the operator manually jog the ram past the lone index pulse. This will zero the encoder counter. Good enough? Forget setting up a complete homing package for the hydraulic joints.

Life just got easier. If I need a home offset I can easily add that in pullmax_optima.comp

posting for good luck:

The main motion control signals between the press brake state machine and the hardware interface should be a unified standard within this family of LinuxCNC press brake components.

The idea is to have a standard GUI and press-brake state-machine component, then separate customized hardware interface components for specific machine makes/models. There will also be a simulation "hardware interface component".

The redundant analog velocity and discrete velocity/direction commands are necessary due to some presses use both spool valves and servo valves to set velocity and direction. A press using only a servo valve might not need this component and could likely be connected to a PID just like a servo driven axis. A press using only discrete spool valves (no variable speed control) would allow leaving the velocity command disconnected.

This allows a straightforward command from the state machine to the hardware.

The main control command between the press brake state machine and the hardware interface will be like:
(additional feedback and home-offset pins not listed here)

Type: float    y_cmd_pos "Y Position command";
Direction:    press_state_comp    =>    hardware_interface

Type: float    y_cmd_vel "Y Velocity command";
Direction:    press_state_comp    =>    hardware_interface

Type: float    y_cmd_tonnage     "Y Tonnage command";
Direction:    press_state_comp    =>    hardware_interface

Type: bit    pedal_is_dn "decoded foot-pedal status from state machine";
Direction:    press_state_comp    =>    hardware_interface

Type: s32    motion_type_cmd
Values:        -99 = homing slow up
        -31 = up fast 1
        -21 = up med 1
        -11 = up slow 1
        -1 = pressure dump
        0 = halt
        1 = dwell
        11 = down slow 1
        21 = down med 1
        31 = down fast 1
        99 = homing slow down

This allows easily adding speed states for presses with additional speed selection spools. For example, a press with an additional med-fast down speed would also support motion_type_cmd = 22 “down med 2” On the pullmax_optima hardware interface component I delete the med velocities entirely, as the spool valves on this press do only “fast” and “slow”.

We will need to pass a “list of valid values” for the selected hardware_decoder, to the press brake state machine, ideally via the ini file.

file.ini:
[AXIS_Y]
valid_states = -99 -31 -11 -1 0 1 11 31 99

Something like that. I’ll see what I can do.

No problem, I talk to myself a lot when I'm programming.