Pressbrake CNC Control Setup Questions
Ok, I gave this a little more thought.I am starting to think that the HAL component was a mistake. As the number of axes goes up, and the requirements appear for homing and jogging it starts to look more and more like a conventional CNC machine.
Though there is still the issue of pedal-controlled up/stop/down in realtime, that really doesn't want to be handled in the GUI.
Some ideas:
- Set up the homing as a conventional CNC, keep it separate from the component.
- Use a HAL component only for the ram y axis control. The component you made works good! Maybe have a second component for jogging, like the one you set up only it does not return to start position when I leave off the peddle. Or use my machine's 2 button hand control for jogging mode and the foot peddle for auto mode. The ram control settings would not need to be saved in a file.
- Keep the backstop separate from the ram, It does not need to be controlled in realtime, gcode control would be good enough.
A few questions:
- For homing the ram y axis, is my best option to add a homing switch, or is there a way I can home to the index?
- Would it be possible to add the pressure(preset tonnage limit) to the component, or should it be kept separate, maybe in the e-stop / enable chain?
E.W.
Please Log in or Create an account to join the conversation.
Some ideas:
- Set up the homing as a conventional CNC, keep it separate from the component.
- Use a HAL component only for the ram y axis control.
That might work. I need to think whether it is easier or harder than adding generic homing and jogging to the component.
If we decide that _all_ jogging is by jogwheel, and all homing is to index it is not too bad. If we want to support keyboard jogging, mouse jogging, network jogging, mdi jogging... and homing to switches, probes and absolute encoders, then it gets too hard.
So, for your machine, if you want to jog the axes by jogwheel, and all axes have a glass scale with a midpoint index, then it's not so hard to expand the component.
I think that you need a switch to know which way to move to find the index. But perhaps that is built-in.For homing the ram y axis, is my best option to add a homing switch, or is there a way I can home to the index?
As far as I know you have a single 5µm pulse in the middle of the scale. So from a cold start the system has no way to know if it needs to move up or move down to find it. But this seems like a daft way to make a scale. It would make more sense for half the scale to be Z=0 and half to be Z=1. I can work with what you have, but I do need to know what you have.
Would it be possible to add the pressure(preset tonnage limit) to the component, or should it be kept separate
It belongs in the component.
Please Log in or Create an account to join the conversation.
If we decide that _all_ jogging is by jogwheel, and all homing is to index it is not too bad. If we want to support keyboard jogging, mouse jogging, network jogging, mdi jogging... and homing to switches, probes and absolute encoders, then it gets too hard.
So, for your machine, if you want to jog the axes by jogwheel, and all axes have a glass scale with a midpoint index, then it's not so hard to expand the component.
For jogging the ram, all I need is the ability to stop the ram in the down position.
To center the bottom die I need to lower the top v punch, either down close or against the bottom v die, and hold it there while I fasten the bottom v die. A jogwheel would work. I do not need any keyboard or etc. jogging.
As far as I know you have a single 5µm pulse in the middle of the scale. So from a cold start the system has no way to know if it needs to move up or move down to find it. But this seems like a daft way to make a scale. It would make more sense for half the scale to be Z=0 and half to be Z=1. I can work with what you have, but I do need to know what you have.
The ram index pulse is z=1 both before and after is z=0
I can add a proximity switch and steel bar to give an input signal for which side of the index it is on before homing, if I need to.
Both of the backstop axis are controlled by Moog servo drives. (Attached pdf.)
I have them jogging with the conventional config. I have a few questions on setting them up. It looks to me like they have there own pid control, with resolver feedback from the motors. They output simulated encoder feedback. Do I also use a pid for the +-10v analog input?
They both have proximity homing switches at the back end of there travel.
Please Log in or Create an account to join the conversation.
It looks like I should have some time tomorrow, and will try to get back to this.
Would it make sense to have a "pressure mode" where the brake moves down to a pre-set pressure?
Please Log in or Create an account to join the conversation.
Yes, that's ok! I only have a limited amount of time available myself to spend on this project. So I don't get to stick on it like I'd like to.Sorry, I am aware that I got you going and then seem to have stopped.
It looks like I should have some time tomorrow, and will try to get back to this.
It's alright with me if you take your time and don't feel pushed. Thanks!
Yes I think that would work.Would it make sense to have a "pressure mode" where the brake moves down to a pre-set pressure?
Earl W
Please Log in or Create an account to join the conversation.
I think that we need to have a think about safety.
At the moment the pump and enable buttons don't work as they should. This is largely a problem with the HAL layer of the config.
Please Log in or Create an account to join the conversation.
attached halcmd error
Attachments:
Please Log in or Create an account to join the conversation.
Is it otherwise functional, or are the errors enough to stop it loading?
Please Log in or Create an account to join the conversation.
Please Log in or Create an account to join the conversation.
But I can't see why there would be a mismatch.
Please Log in or Create an account to join the conversation.