Press Brake CNC Control & G-Code

Hi,

My first post, so please go easy

I've started retrofitting a number of milling and routing machines with LinuxCNC, so I understand it, motion control in general and can turn my hand to software engineering. I'm not experienced with LinuxCNC, hence the questions, but hopefully can get some hints or pointers.

I'm considering a CNC controller replacement/retrofit for a press brake, and really not liking the products on the market. Searches bring up minimal results for press brake control, and the few threads are people wanting to do dumb stuff to dangerous machines (like using the stepper motor/control assembly from an old USB scanner and writing code in VB).

I've read snippets and off-hand comments mentioning G-Code being used by some press-brake controllers, but have found nothing of real use. I can't even see what protocols or programming standards are in place - most companies and controller makers seem to do their own thing; some UI are hideous, most are Windows based, and they're all un-necessarily expensive.

I like the idea of using G-Code for a press brake. Okay, some of the G-Code "standards" will need to be adjusted and modified (as any machine manufacturer would do), mostly for adding the extra back-gauge axis to 'G00' (for moving the back-gauges around between presses).

There'd need to be a couple of different moves for the Y-axis (the press brake's ram), which would be akin to peck/drilling cycles, for example, moving the press down a specific depth (which controls the fold angle) at a specific speed. There's different press cycles that are useful, such as a low-pressure move that holds down a sprung-loaded dutch hemming tool for the operator to lock down or release, or being able to specify a dwell or other action in between release (so a front-mounted support or robot can be actuated or back-gauge moved) etc. Because the press is user operated, it would also mean that it can be interlocked, so that the press can't be actuated unless there's a cycle command being issued/run. Allows for gauges to be positioned, pressure to be correct etc before the press can be operated, but even in a 'manual' mode, it's as simple as entering the G code for the press cycle, and then pressing the operating button (which is normally a foot pedal plus hand button).

I'd also like an M code for setting the tonnage, so either at the start of a program, or between each press, there'd be an M code specifying the tonnage/pressure to be used. Again, this would be akin to the spindle on/off and speed control.

The ability to see the position of each axis and to manually control each axis, plus with widgets for calculating axis offsets, tonnage and Y stroke based on material thicknesses, angles, etc, it seems a really good approach. There's work to do on building a library of tools with dimensions, and making sure the tables/calculations work, but I've not seen anything compelling on the market, and I'm happy to build my own (albeit with baby steps).

I could likely build all of this using a PLC, HMI and whatever programming tool I have to hand (probably CoDeSys), but if I can use LinuxCNC, then it brings parity to all of my machines. I'd probably use a PLC for some of the machine interfacing, so does bring up questions regarding interfacing, but may use a MESA for all of the back-gauge. I'm also considering building my own back-gauges, so can be flexible with the controllers etc for those. Some stuff, mostly the hydraulic control I would want hard programmed in a PLC along with good safety. That goes without saying!

And how cool would it be to have press gauge programmes written and stored in G-code, that can be test run using LinuxCNC simulations??

I can't believe I'm the first person to suggest this, so hoping that either some thought or maybe some progress has gone into this already?

Thanks
Jon

Thanks Andy!

The bender looks a nice UI approach. While I'd work towards having additional views* to step through bend sequences, this is very close to where I'd want to start - a glorified DRO/NC!

*(ie maybe 2D or 3D with collision mapping - where you map each fold to see if any other bend or feature will hit the machine or tooling).

How does LinuxCNC store/map/access sequences in the way you've got in the tube bender? Is that separate code that feeds that into LinuxCNC from something like MySQL/SQLite or even flat text files? Could I run a machine via LinuxCNC without G-Code?

My thought was that any program, macro, sequence etc could be non G-code, but would be mapped to G-code functions at some point. So a bend program could be a series of angles etc, but when you factor how many variables there could be with back gauge positions, then you may as well use G-code to begin with.

That being the case, there's a beauty of using G-Code (albeit remapped), but, if they're all hard baked into LinuxCNC and would require more work to remap them, then maybe another approach...

J

Okay, I'll have a look at the code...

A backguage is pretty much a gantry, with two independent fingers. The punch and die is the tool spindle, which has tonnage (akin to speed), the speed of stroke (akin to feed) and the stroke depth, which governs the angle, is basically the Z axis/tool depth (but called the Y axis in press brake parlance).

That being the case, it seems to map well to G-code, there's extra axis to be mapped, such as X (the whole gantry), X1 and X2 (if the two fingers move back and forth independently on the gantry), Z or Z1/Z2 (the two fingers either move together or left/right independently along the gantry) and R (the height of the fingers from the gantry).

Take those with a pinch of salt, gantries work differently across makes, some label axis differently, and some are engineered either as shared (so X1/X2 deviate a small amount independently from X), or that they pivot etc etc. Basically, it's a gantry with smaller moving bits mounted. I'm looking to start with the X and later will replace the manual R and will fit Z1/Z2. These are currently manually adjustable brackets but I can make some small servo/stepper driven fingers.

If I use a modern PLC, what protocols can LinuxCNC communicate to it with? The norm is Modbus or CANBus, but not sure what LinuxCNC can deal with. This would likely be for the interlocks, safety, pressure, stroke etc and X axis gantry (big servo). The other axis I'll use steppers or small servos that could be driven using a MESA card.

J

I'll use the inbuilt PLC for a number of things including the sequence/step interlocking, but for the hydraulic and safety systems I'll use an industrial PLC with safety modules. If anything, the ability to use the press with its inbuilt PLC and maintenance HMI is handy, if the CNC control software isn't working etc.

I'll go the Modbus way then, as used to that from control work.

As there are two carriages on the same linear rail that form the Z-axis (Z1 and Z2), I'm trying to figure out the best way the logic could be programmed. Can LinuxCNC handle multiple things on the same axis?

The logic could be handled elsewhere, but would like it configurable in LinuxCNC. Pictures of the axis attached..

The Z axis is straight forward (LinuxCNC doesn't even need to know they're on the same axis), but there's got to be some kind of dynamic collision detection. So, Z2's min limit is always Z1's position, and Z1's max limit is Z2's position etc. I'm not sure if I should do this separately, so that Z = Z1's position, Zd = the distance between Z1 and Z2 or Z = the centre and Zd is the deviation between Z1 and Z2... Or if both should start from the origin, but there's some kind of relationship where their limits are dynamic...

In reality, theres something physical or in code that stops the axis from hitting each other when they're moving to the next position, plus there's some logic in the routine programming that stops an operator from moving Z1 and Z2 into each other's space fora position. It's not like I'm running a 3D printer with two separate heads on gantries, and that I have to sequence their operation dynamically without collision!

Basically, I see in hardware, that one end of Z has Z1's min limit, the other end has Z2's max limit and a switch on either carriage is assigned as both Z1's max limit and Z2's min limit. If both carriages touch during operation, they both stop as they've reached their limits! That deals with programmes with errors in them, or me entering crazy values in the UI. Next, the software UI says "NO" if you enter a position for Z1 or Z2 that overlap their space. In terms of homing them, I would look at using the Z1 min limit, and then getting Z2 to touch against Z1... or maybe that's super dumb, and I should send them to either end of Z...

The X axis is apparently complex, but actually straight forward, in that there's an average position (the main gantry maintains) and then the two sub-axis X1 and X2 deviate either positively or negatively. When both X1/X2 deviate the same, the they should be in their neutral position and the whole X axis moves to that point. If X1/X2 are say 100mm apart starting from origin, then X should be +50mm and X1/X2 should be +50mm and -50mm from X respectively. This scaling between X1/X2 and X is quite straight forward - X is a byproduct of X1 and X2 positions, even if I entered X in the user interface, it would just be a lazy way of entering X1 and X2 to be the same position. The real complexity comes from creating angles, by offsetting X1 or X2 so the material in the press brake can be angled, but that's just math, and that's what computers are for

I also need to figure out if the X1 and X2 origin is the X origin or they have their own. At this stage I don't think I need or can achieve the deviation between X1 and X2 to be the max length of X. It should only allow a certain deviation to be entered (so, I can enter X1 = 100mm from origin and X2 = 500mm from origin, giving a deviation of 400mm, placing X at 300mm, X1 at -200mm from X and X2 at +200mm from X) - X1 and X2 can be a maximum of their deviation apart, but the scaling can be between say 0 and 800mm (or however long X is).

Before I plow money into extra MESA cards etc, I might mock this up using an Arduino Mega with a RepRap board and a couple of NEMA 17 steppers and 3D printed bits.

Is LinuxCNC a proper motion control platform (ie can be used against anything), or is it really geared towards CNC machines? Am I using the right or wrong tool here for the motion control?

J