Press Brake CNC Control & G-Code

Are the ABC axes considered rotational by the G-Code interpreter or LinuxCNC itself?

How/where do I define the names of the axes if I wanted to add more/override existing?

Canterp looks pretty interesting, I may just lift/fork that library and build a press specific version. There doesn't seem to be a standard around, non of the manufacturers seem to support anything non-UI driven, and those that might, require their offline software. I can't find sample code, so not sure if it even exists, or is just in the form of tabulated data containing the bend sequence and positions, and it's the CNC controller that figures the rest out...

Thanks
J

You could make an M-code that sends a position command directly to a Stepgen and wait for a move complete signal. Some creative hal code could compare the stepgen's commanded position with it's feed back position, to tell if the move is complete. The tricky part might be figuring out how to home/reference these unofficial "joints".

bymccoy wrote: I can't find sample code, so not sure if it even exists, or is just in the form of tabulated data containing the bend sequence and positions,

Did you look at my sample config that uses tabulated data? Adding more columns for the stops would be easy.

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

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

The actual sample passes the table, line by line, to a G-code routine:
But, it would be a simple enough matter to skip the G-code subroutine altogether and have.
This sends a set of G-code instructions through the MDI interface. This is just an example, and the % formatting is just how you build strings from numerical values in Python.

Neater still would be to send canonical commands directly: but it doesn't seem to be easy to access the emccanon interface from GladeVCP Python code. And MDI does all the same things.

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