Messages

31

General Mach Discussion / Re: tool force compensation

« on: December 03, 2010, 10:49:36 PM »

By Golly that just might work. Simple and elegant. I will read up on implementing that.

Can I define the multiplier as a user variable and set it from the G-code at the start of a project?

Thanks,
Bill

32

General Mach Discussion / Re: tool force compensation

« on: December 03, 2010, 05:37:58 PM »

John,
I was aware of about half of the items you mentioned and understand how the others have an impact on the tool path. And you are right, a finish pass and sharp tools do make a big difference.

I was wondering if there is a setting or a macro that I can use to generate a compensation that will get me closer to the optimal path. If I could normalize out the larger errors, I would be in great shape. I suspect that only one or two of the variables are causing most of the error, and I would like to minimize them.

For instance, if I could offset the tool path in the y direction when traveling in the x direction, the amount based on speed, I could make the flexing in the y direction appear to be stiffer that it is. A parameter in the g-code could enable and scale the effect depending on the material I use.

I am in the process of improving the structural integrity of the machine, but there are a few original design flaws that will be difficult to overcome without a total reinvestment.  

Unfortunately compensating for applied forces would entail an algorithm that runs real-time.

33

General Mach Discussion / tool force compensation

« on: December 01, 2010, 03:43:05 PM »

I get a different sized hole depending on the direction I cut it. Most of the problem lies in a machine designed for wood, which is being used to cut aluminum stock.

In every machine there is some slop, the machine will bend as the tool is forced through the material being cut.

Is there a way to compensate the path for the forces on the tool?

These forces will be 90 deg from the direction of the tool path. I am aware that that the actual force cannot easily be measured, but a nominal value could be assumed for a given material, rotary speed, tool feed rate, and depth of cut. In my case, these items are relatively constant, and one number, for each axis, may do the trick.  It may even be possible to pick up some of these values from the g-code settings.

I haven't ruled out backlash, but I have done a lot to minimize it.

Thanks, Bill

34

Finished Plugins for Download / Re: USB JoyPad and game device plugin - new version!

« on: October 12, 2010, 10:12:37 AM »

Area51;

The POV functionality is not configurable on this low budget unit.

It seems a waste that the POV is not usable for something without buttons 5/6 being pressed. However, the POV is a sloppy interface and trying to utilize it may not be worth the effort.

Thanks for all of your help.
Bill

35

Finished Plugins for Download / Re: USB JoyPad and game device plugin - new version!

« on: October 10, 2010, 08:55:19 PM »

Joakim,
The POV will, according to the diagnostics, output 8 directions. The pad does move the X & Y axes in 8 different directions. I presume that the POV is really only 4 physical buttons where at most two adjacent buttons can be selected at the same time.

Selecting "not mapped" for X & Y does kill the axis movement, but does not activate the POV macro mode. When I open the configuration window, the POV 1 message always appears, but never at any other time. The joypad does appear to be active while in setup mode  but changes do not take effect until the setup window is closed.

Thanks,
Bill

36

Finished Plugins for Download / Re: USB JoyPad and game device plugin - new version!

« on: October 09, 2010, 10:43:10 PM »

Area51,
I have a 2-axis joypad with 10 buttons and a POV. I installed the new driver and updated MS DirectX as you have suggested. All 10 of the buttons work as expected, and there is carriage movement with the POV+(5/6). The POV buttons, however, do not seem to activate macros M821-M828 or M871-M878. I tried this on two different systems (XP-Pro and Win2K) and the results are the same.  I had one set up with a custom configuration and the other with the default. The only thing these macros do at this time is try to post a message. I must be doing something consistently wrong. Is it possible that the POV buttons are looking for the macros in a different place? Currently all of the joypad macros are in the same configuration directory as the other common macros.

BTW. The manual is terrific!

Once I get the POV button macros working, would it be possible/reasonable to activate a macro (say M829 and M879) when the POV returns to center?

Thanks, Bill

37

Feature Requests / Re: Formula for variable feedrate

« on: September 29, 2010, 05:46:00 PM »

Depending on how smooth running it has to be you can use a macro that does this for you in fast steps.
output:
===================
y_step            = starting_point
y_limit             = ending_point
y_step_change = delta_y_movement

y_increment = 0

while (y_increment < y_limit)
    x_step = (y_related_formula)

    code "GO Y" & y_step       ' desired Y step
    code "GO Z" & x_step       ' desired X step
    While IsMoving()            ' Wait for stop
    Wend
   code "G4 P" &(pause_that makes_Y_go_at_your_desired_speed)  ' "G4P0.25" pauses a 1/4 sec
y_increment = y_increment  + y_step_change
wend
===================

make sure the Y_step is plenty small to accommodate the increasing speed of the X axis and the material you are working
This will move y linearly and x according to your formula.
Both the step size and the delay will affect the apparent feed rate

Thanks,
Bill

38

General Mach Discussion / Re: Wanted: Position X & Y at the Center of a Hole Macro

« on: September 23, 2010, 01:28:43 PM »

Hood,
OEMLed(16) did the trick. I Found this solution works well. I used an ElseIf and posted the message in the status window. That way the process is automatically terminated on this error condition. Added it as follows:

===============================
If GetOemLed (825) <> 0 Then 'Check to see if the probe is already grounded or faulty
    Code "(Probe is grounded, check clearance and try again)"

ElseIf GetOemLed (16) <> 0 Then 'Warning Wrong Coordinate system
    Code "(Center Finder Error: Exit Machine Coordinate Mode)"

Else
 (Body of the code)
===============================

I added a second pass at finding the center of the X axis, because I didn't trust the probe to give me good results if it starts out next to the Y edge of a hole. Once the near X axis center is found, the probability of a clean touch goes way up. The process now searches for X, then Y, then X again, done. On several practice runs, I noticed that the X center moved a few thousandths on the second pass, but never by more than 0.001 on a search starting from the near center of the circle. This is well within the slop of the CNC machine.

Thanks,
Bill

39

General Mach Discussion / Re: Wanted: Position X & Y at the Center of a Hole Macro

« on: September 22, 2010, 09:42:52 AM »

Thanks,
The files are very useful.

I noticed that if the 'Machine Coordinates' button happens to be pressed, strange things happen. I need to find how to determine that button is ON so I can force a warning message.
Thanks again,
Bill

40

General Mach Discussion / Wanted: Position X & Y at the Center of a Hole Macro

« on: September 21, 2010, 12:45:10 AM »

I have seen a lot of talk about center finding and it all seems to boil down to finding the Z height and bug fixing... Is there a direct  posting of a working  macro, for Mach3, that will find the center of a drilled hole? I need to reliably find the center of a hole that has been drilled in a metal material for rework. The electric touch sensor can be positioned to fit in the hole without touching the sides as a starting point. Trying to read hundreds of pages of commentary with hundreds if external thread references is a bit much.

Thanks,
Bill