Brown & Sharpe beast retrofit
I hope 2014 is treating everyone well so far. Ive been banging away at this green beast for the last month and have most of it worked out. Ive noticed some strange behaviors with some userspace prgrams and have a couple questions.
When accessing both the tool change , prep tool pins and both current and next tool numbers from io control, Ive had to assign variables in my comps to the bit or number as the signals seem.to come and go. In addition if the comp has any kind of eventhandling at the beginning and the io control signals are not at the top of the program, they get skipped. Is this because of the latentcy of userspace? What would be involved in making both Halui and IO control realtime programs?
I am using the Halui home pin for each axis with a physical button on a control panel. When I press the button to referance the machine, halui.whateveraxis pin goes high, but I get no machine movement. I noticed there are two options in halui for homing, home with .joint number and home with select axis and axis is slected. Which one works?
I have a very heavy z axis, about 3k lbs. The head runs smooth in the minus direction, but often faults the following error up and will fault the FE moving up slowly. I suspect setting some bias on the axis will help. Is the bias signed for a particular direction? How much does one use?
I strongly suspect i need to increase the capacitence of the servo system as it often seems like it runs out of power. The z axis motor uses alot of current.
What would be involved in adding a few more parameters to M61, so I could assign a tool to.the spindle, pocket and tool chain pocket? Thanks as always.
Please Log in or Create an account to join the conversation.
your drive into torque mode and then set a fixed output bias from the PID
component which will generate a fixed output torque to compensate for gravity.
(pid.N.bias)
This will require re-tuning as torque mode tuning is quite different
than velocity mode tuning
Please Log in or Create an account to join the conversation.
Can you elaborate on that? The values really should be set and stay set unless something truly wierd is going on.When accessing both the tool change , prep tool pins and both current and next tool numbers from io control, Ive had to assign variables in my comps to the bit or number as the signals seem.to come and go.
Can you attach your component, it may be that there is something strangely wierd or wierdly strange in your code.In addition if the comp has any kind of eventhandling at the beginning and the io control signals are not at the top of the program, they get skipped. Is this because of the latentcy of userspace? What would be involved in making both Halui and IO control realtime programs?
I think they should both work, though I haven't tried using them.I am using the Halui home pin for each axis with a physical button on a control panel. When I press the button to referance the machine, halui.whateveraxis pin goes high, but I get no machine movement. I noticed there are two options in halui for homing, home with .joint number and home with select axis and axis is slected. Which one works?
My approach in a similar situation was to see what the PID output was with the head stationary, and set the bias to the same number.I have a very heavy z axis, about 3k lbs. The head runs smooth in the minus direction, but often faults the following error up and will fault the FE moving up slowly. I suspect setting some bias on the axis will help. Is the bias signed for a particular direction? How much does one use?
Please Log in or Create an account to join the conversation.
With the pins in io control, When the tool called by T is commanded( as in M6t21) , which is assigned next_tool, simply clears or, doesnt actually get read. I was trying to use next tool, through out the program, but at the very beginning of a tool change, it disappears and comes up to zero,Ive had to assign another variable like so
call tool = next tool
The program sometime down the line will recognize next tool again. It changes tools well, but it seems rigged.
this is im trying to do with home from a button. It seems like if the home joint 0 pin is set high, the axixs should home, it does see the pin goo high, but no movement.
pin out bit home_x; // connected to halui.joint.0.home
case 5:
if(((jog_plus_btn)==1&&(modesel_pos)==7)&&(axis_sel_val)==1) // home x
{
set_manual_mode=1;
set_mdi_mode=0;
set_auto_mode=0;
home_x=1;
}
Attached is the comp for the toolchanger, It has a lot to do and I really couldnt find a better way to do it. Thanks
Please Log in or Create an account to join the conversation.
I think it is cleared when the "tool-prepared" pin is asserted. Do you have a loopback in HAL on that pin?With the pins in io control, When the tool called by T is commanded( as in M6t21) , which is assigned next_tool, simply clears or, doesnt actually get read.
<EDIT>
I just tried it in a sim, and tool-prep-number goes to zero when tool-prepared is true.
Please Log in or Create an account to join the conversation.
There is some chance of iocontrol missing it if you do this, but less chance of iocontrol thinking that the tool change is already over.
You need to make sure that iocontrol has seen "tool-changed", so maybe a wait-state for current-tool == tool-number before returning to tc_cond = 0.
(You may already have this, it's a bit late to read and digest all of that component)
Please Log in or Create an account to join the conversation.
M6(CHANGE TO TOOL IN THE POCKET, put previous tool back in chain)
T2(get next tool ready)
do gcode stuff
M6( change to tool to staged tool(T2), put previous tool away)
T3(get next tool ready)
ect ect
When the program (the comp) see's the prep_tool bit go high, it jumps to case that decides which is the shortest direction and stages the tool. when the tool is at the ready station at the spindle, it hits a limit switch to signal it is staged and sets the tool prepared bit high. The next time it sees M6, the program simply swaps the tool in the spindle for the tool in the ready pocket and puts the empty pocket back in the tool that was in the spindle's empty tool chain spot.It is working, it just took what seemed like extra effort because it would clear the new tool numbers or prep signal.
It seemed like there was a delay in the transfer of the signals from userspace , the comp is assigned to the servo thread. I dont know if anyone has ever had a go at a toolchanger this busy.The one I saw that was similar was on an old K&T horizontal and the guy put radio tags on the tools and or pockets. I was gonna do a new video of it changing tools, Ive been having some trouble with the z axis, which is being compounded by a bad tach and or motor winding. Some days there just are not enuff rocks....Thanks.
Please Log in or Create an account to join the conversation.
It's not all that hard to keep a variable with the expected tool in it. You can create it as a static variable in the C-code, but it is probably just as easy to create it as a hal parameter, and then you can watch it. (a read-only HAL parameter will act like a static variable)it just took what seemed like extra effort because it would clear the new tool numbers or prep signal.
That will be Sam's machine. It actually uses mechanical barcodes rather than anything RF, the machine was built in 1964.The one I saw that was similar was on an old K&T horizontal and the guy put radio tags on the tools and or pockets. I was gonna do a new video of it changing tools, Ive been having some trouble with the z axis, which is being compounded by a bad tach and or motor winding. Some days there just are not enuff rocks....Thanks.
Please Log in or Create an account to join the conversation.