Press Brake CNC Control & G-Code

I read through the info and screenshots etc but completely forgot to look at the code! I will in morning...

What does that use as an interpreter, or does that do away with an interpreter and does the UI issue the axis commands?

I was thinking about the machine I have and actually think it'll be mechanically easier to have indepdent R axis (so each finger can raise/lower independently), as converting the existing X mechanism to lift/raise is dumb. So this actually adds an extra axis now.

Is the use of ABC axes going to cause an issue long-term? Is there anyway to add/replace these axis and have specifically labelled axis? Depending on how much heavy coding I need to do will also define whether R2, X2 and Z2 are delta values or actual position co-ordinates.

I'm happy with the UI doing the majority of math for calculating bend radius, angle, finger positions etc, as much of this is assisitance in creating/calculating/guessing a set of axes co-ordinates. A few test bends and tweaking needs to be performed and such offsets recorded as well.

J

I'm guessing the sequence wouldn't complete line by line that way, but would require some sort of UI control to perform each line?

The reason I like the idea of using G-code as the programme in the UI, is that the sequence would proceed line by line as each G-code is completed (so when stepped position/servo feedback achieved) and for the actual press stroke, it would reach the line and stay there until the feedback from the Y position (the ram) had completed. The ram interlock requires the operator to use a foot switch and hand switches or uses a laser safety system plus foot switch. Only that can move the ram, never the UI. likewise, the PLC that controls the ram will operate the ram like a big servo. The G-code from the MDI would only issue an allow signal (I'm thinking a Modbus register with the Y stroke and an interlock register or a wired interlock) to the PLC to move the ram if its currently waiting for the Y position to change (so at any other line in the program the foot/hand switches for the ram don't do anything) - the PLC can clear the interlock register or LinuxCNC would open the wired interlock signal.

In short, what I'd need/like is the UI saying "I'm moving the axes for the next bend." Then when the axes are ready, or rather, when the next command is to actually bend, the UI says "now your turn; insert the part and activate the ram."

Would that step through of a programme still happen if individual commands are being sent to the MDI?

Ultimately each bend step probably needs either a 2D render, an SVG preview or textual description of what is being done next. Tying that with G-code could be hard. So on one hand having a programme manager send commands to the MDI or run canonically makes sense, but only if the UI knows what's happening (so it doesn't just dump a hundred commands into the MDI, it only sends each command/block of commands when the last has completed).

Thanks
J

The machine I'm planning to upgrade has only just been moved into place today, so I've not had chance to date to look at the control system or the electrical drawings...

I've been scanning all of the paperwork in, so I can read in bed over the weekend at leisure

From my initial inspection of the machine and following pipework and cables, it appears to be an electro-hydraulic machine. It also appears that all of the press control is electro-mechanical, ie, there isn't a PLC that controls the stroke, instead there are adjustable stops that limit switches are triggered by, which in turn actuates contactors. The machine is a 2009 model, so I'm guessing this approach is the tried, tested and safest approach.

The NC controller interfaces two servo encoders and in turn has a number of IO interfaced via relays/contactors. This makes it very very very very super easy to replace the NC. All at 24V control voltage it appears too.

It would seem that my replacement controller doesn't need to take over the stroke control - all I need to do is add an extra interlock (so LinuxCNC only allows the operator to operate the brake when it's happy that moves are made and everything is ready) in addition to the safety interlocks.

The hydraulics appear totally self contained - the pressure is set by a manual control (very common I understand for all but the most modern/expensive on the market), so nothing needs to be changed or interfaced with. The pressure (tonnage) is going to be pretty much the same for the work we do, so it's an infrequent change. I'm not that comfortable at this stage screwing with the hydraulics (even getting a pro in to do the hydraulics work, there's just a lot of work to calibrate a different proportional valve).

It appears that the stroke is governed by a secondary stage on the hydraulic cylinder. The cylinder only ever moves from A to B. The upper and lower positions are governed by two limit switches that hit two adjustable slides, that stop the two-way solenoid valves. Nice and simple. This is a set and forget position that tends to be governed by the brand of tooling, the standard heights of tooling etc. Not something to be changed ever by an operator.

So the important stage is the electrically driven one. This basically moves the head of the press brake up and down the cylinder to control the actual position the punch and die will meet when the cylinder moves from A to B. The electrical part of the head is never engaged in bending the metal - that's the hydraulic stage.

So, the LinuxCNC controller will need to read the encoder and control the motor accordingly. It's not an integrated closed-loop servo; so I should be able to use a MESA 7i77 to read position and control the motor forward/backward accordingly.

Going nicely so far.

The backgauge (single axis at the moment) is similar, and has a simple motor control and a separate encoder.

There are two motor contactors/DOL and one VFD. I need to figure out what is controlled by what. I suspect the pump is VFD controlled. I'll know by the end of the weekend!

The NC is dog ugly and unnecessarily complex. I'm very inclined to swap it - even if I do it in a "soft" way to a very simple LinuxCNC UI.

This is looking a fun project!

Started going through the electrical drawings and it's making for an interesting read...

So, the X and Y axis motors both share the same VFD. Their contactors are interlocked, so when one is being positioned, it uses the VFD with fwd/rev switches and a fast switch. The motors position within a certain range at full line frequency (50Hz) with the fast switch and then drops to 5-10Hz for accurate final positioning. No idea if the NC has a seek for overshoots etc. A basic replacement for the NC should be really simple!

The hydraulic speeds are controlled by use of two hydraulic solenoid valves being actuated - the first solenoid valve for lowering the beam and the second solenoid for "working" pressure/speed is simply controlled by the position of the corresponding limit switch and adjustable limit.

I thought from inspection it was electro-hydraulic, but reviewing the electrical, it actually appears the electric motor controls the position of the low limit (which the lower limit switch is triggered by). The calibration docs shows pretty good accuracy for the machine, so not sure if it could be improved with optical/magnetic scales.

So, still looks straight forward. Only issue now is how the safety curtains have been wired in, as that's not documented
All I know is that they should be muted on the upstroke, so they've tapped into a few contactor auxiliaries.

Anyway, guessing a MESA 7i77 is still the way to go. Should give me enough extra servo interfaces for the extra axis. Plus a tonne of IO that I can tap into for extra info onscreen (like a machine PID showing which E-stop or limit switch or safety switch is triggered).

Okay...

I re-inspected the machine after reading the electrical docs... So, was pretty much right first time I looked at the machine.

There's a pair home/limit switches on both of the axes with encoders. I think these are purely for the NC controller and motor control, and don't interlock with anything.

There's then a pair of interlocked limit switches that govern the max and min travel of the beam/head.

Then there's a limit switches to set the "safe working distance" which is the first position the beam moves (at reduced speed/pressure), and one that sets the tool distance (to avoid coining aka crashing the tool).

Now, looking at the cylinder arrangement, I was right that this is electro-hydraulic, and that the servo motor sets both cylinders to the stroke length for the Y axis. The drawings and the explanation is badly translated and implies it's mechanical (via limit switch stops moving), but the action is very much to affect the cylinder stroke...

Hi bymccoy,
i have been reading your article regarding Press Brake CNC Control & G-code
and want to know if you managed to finish the set up and if you are prepared to share.
Tony Ramos