Brown & Sharpe beast retrofit

More
04 Feb 2014 09:41 - 04 Feb 2014 09:45 #43524 by JR1050
Hi,

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.
Last edit: 04 Feb 2014 09:45 by JR1050. Reason: my phone sucks

Please Log in or Create an account to join the conversation.

More
04 Feb 2014 11:10 #43526 by PCW
Replied by PCW on topic new questions and observations
As far as the Z axis bias is concerned. I suspect you would have to set
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.

More
04 Feb 2014 21:25 #43538 by andypugh

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 elaborate on that? The values really should be set and stay set unless something truly wierd is going on.

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?

Can you attach your component, it may be that there is something strangely wierd or wierdly strange in your code.

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 think they should both work, though I haven't tried using them.

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?

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.

Please Log in or Create an account to join the conversation.

More
05 Feb 2014 03:00 - 05 Feb 2014 03:02 #43553 by JR1050
Andy,

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


File Attachment:

File Name: toolchange...-04.comp
File Size:24 KB
Attachments:
Last edit: 05 Feb 2014 03:02 by JR1050. Reason: forgot attachment

Please Log in or Create an account to join the conversation.

More
05 Feb 2014 07:19 - 05 Feb 2014 07:24 #43559 by andypugh

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 think it is cleared when the "tool-prepared" pin is asserted. Do you have a loopback in HAL on that pin?

<EDIT>

I just tried it in a sim, and tool-prep-number goes to zero when tool-prepared is true.
Last edit: 05 Feb 2014 07:24 by andypugh.

Please Log in or Create an account to join the conversation.

More
05 Feb 2014 07:34 #43561 by andypugh
One thing I would try is setting tool_changed to zero in the tc_cond = 0 state, every time, regardless of other inputs.
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)
The following user(s) said Thank You: JR1050

Please Log in or Create an account to join the conversation.

More
05 Feb 2014 07:41 #43563 by JR1050
This is a tricky tool changer. The tool can be called by M6T1 and it will fetch the tool and put the old one back in the chain by the shortest route. I can also stage a tool like so

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.

More
05 Feb 2014 20:55 #43581 by andypugh

it just took what seemed like extra effort because it would clear the new tool numbers or prep signal.

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)

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.

That will be Sam's machine. It actually uses mechanical barcodes rather than anything RF, the machine was built in 1964.

Please Log in or Create an account to join the conversation.

Moderators: cncbasher
Time to create page: 0.118 seconds
Powered by Kunena Forum