Pressbrake CNC Control Setup Questions

flamecutter wrote: Now my next step is to get it to work with my machine. I've been trying to get the press.comp to work in axis gui, but just can't get it going.

Basically the output of the simple_tps in my config would need to go to the input of the pids in your config.

You can do away with the INI, or pass it to the HAL file in the bash script with a -i option.
linuxcnc.org/docs/2.8/html/man/man1/halcmd.1.html

If you prefer to not use the INI then you can put the PID gains in the HAL: instead of
You should remove the loadrt MOTMOD and loadrt KINS lines, and remove anything with "motion" in the name from the HAL.

Do you need homing? There isn't any homing in my config, it rather depends on an absolute encoder as things stand.
There is also nothing controlling machine on/off state or e-stop etc at the moment.

andypugh wrote: Do you need homing? There isn't any homing in my config, it rather depends on an absolute encoder as things stand.There is also nothing controlling machine on/off state or e-stop etc at the moment.

Yes, I will need machine on/offAs far as homing goes, now yet I was manuel homing with ram cylinder at top of stroke. Should I be adding a homing switch or is it possible to home off of encoder index?My encoder is an incremental linear encoder.

flamecutter wrote: Yes, I will need machine on/off

How would you like it to work? You get to decide

As far as homing goes, now yet I was manuel homing with ram cylinder at top of stroke. Should I be adding a homing switch or is it possible to home off of encoder index?

All things are possible, though if the machine automatically runs to top of travel when off, or always gets parked there, then there might be no need.

Which encoder do you have? One with distance coding or single index in mid-travel?
Is it an index pulse, or high for half the scale and low for the other half?

Basically homing would need to be added to the press component, as an extra few states in the state machine.

Do you actually have a backstop? Does that also need homing?

Also, thanks for adding the backstop!
I was not working on that part of the connection yet.

As an extra twist, the backstop is two axis. One axis for bend length and one axis for raising the stop up and down.
Both axis have homing switches.

Is it an industry standard to have Y axis for the ram, X axis for the bend length, and R axis for raising and lowering the backstop?

flamecutter wrote: Is it an industry standard to have Y axis for the ram, X axis for the bend length, and R axis for raising and lowering the backstop?

It doesn't really matter, as this config makes no use of G-code. But we can change the pin names if you want.

Would it be usual to lower "R" then adjust X1, X2, Z1 and Z2? I can see we need more table columns.