Messages

31

General Mach Discussion / Re: ref all home setup

« on: September 04, 2010, 11:40:35 AM »

Sent you an e-mail with my phone number if you want to give me a call.

32

General Mach Discussion / Re: ref all home setup

« on: September 04, 2010, 11:00:46 AM »

You say they work fine and stop the machine.  That implies that they are properly enabled as "Limit" switches.  However, I believe, if they are not enabled as "Home" switches, you will see no motion when you press "Ref All".

On the Ports and Pins -> Input Signals page I mentioned before.  Are the "X Home", "Y Home" and "Z Home" enabled with valid Port and Pin numbers?

33

General Mach Discussion / Re: ref all home setup

« on: September 04, 2010, 10:15:48 AM »

Do you have the home switches enabled under Port & Pins -> Input Signals?

34

General Mach Discussion / Re: Cutter compensation - Found a bug and have questions

« on: September 02, 2010, 04:16:28 PM »

Thanks for your reply Gerry!

I did some more investigating/playing and I think I might have found why it worked for you.  For Tool Zero (no compensation), or any tool that has a positive value in the diameter field in the Tool Table, the display is correct. The only time that the display output is reversed is when I have a negative value for the Tool Diameter.  My programs are written for a Tool Path Contour based on a nominal tool diameter.  If the tool I'm using is undersize, I need to use a negative value for Tool Diameter Compensation.  In this case, the G41/42 value in the display is reversed.  If you could verify this with your version of MACH, it still may need to be reported as a bug.  Just set the Tool Diameter value for Tool 1 to a negative value and make it the active tool.  Then MDI a G41/42 and see if your display is also reversed.

Thank you again for your answers to my questions, but, again, the information was still too vague for me to make an informed decision.

You said that you thought that reducing the Lookahead would "reduce the performance in CV mode"??  I've read the CV Settings documentation and know that they recommend a value of 200 (the default appears to be 20). I have no idea what sort of calculations are being done (besides how to transition from the current move to the next), but I guess I could see a need to "lookahead" on complex 3D contouring that is accomplished with sequences of thousands of short moves. Since my profiles are not very complex (not large sequences of very short moves), I have a hard time understanding how much benefit there would be to using a large value for Lookahead.  In addition, the CV Settings documentation even states that too large a value could cause problems depending on the speed of the computer. As it is, I have no feel for how few is "too few" and how many is "too many".

In reference to Advanced Compensation Analysis, you stated that you didn't think there was a reason not to use it and that the original mode was simply left in place when the Advanced mode was added.  If there's no reason not to use it, why is it a choice?  Any time there is something to be gained....there is always an associated cost. There must be pros and cons....I just don't know what they are.

35

General Mach Discussion / Cutter compensation - Found a bug and have questions

« on: September 01, 2010, 01:59:09 PM »

I've just recently started playing with cutter radius compensation in MACH3 Mill.  (R3.042.020)

The first thing I found was a bug, but I forget where to file a bug report.

At the top of each screen (to the right of the page tabs) is a display of the currently active modal G codes.  The display of cutter compensation codes (G41/42) appears to be reversed.  When my program calls for G42, the display shows G41.  Conversely, when my program calls for G41, the display shows G42.  Can someone tell me if this has been fixed in a more recent version or if I should file a bug report for this?

One other thing I noticed is more of an annoyance than a bug.  In the active G code display, the state of the various modal G codes that are being displayed does not reflect the current line of code being executed.  Instead, it displays the upcoming state based on the General Config value for Lookahead Lines.  For example, if line 50 in my program contains a G42 and my Lookahead Lines value is 20, the display will change to show G42 (actually G41 because of the bug) when line 30 in the program is executed.  I verified this by changing the Lookahead Lines value. I did find through testing that the Cutter diameter compensation is not actually activated until the code is executed, but it's somewhat misleading when the display is updated early.

Now for the questions.

I can take care of the annoying display problem by changing the Lookahead Lines value to 1 or 2, but should I?  The only things I've been able to find about the Lookahead Lines setting are rather vague.  Can someone give me a better explanation of this setting?

One other setting that I'd like more information on is the Advanced Compensation Analysis setting under the Mill Options tab on the Ports and Pins screen.  What exactly does it do?  What would the reason be to NOT have it set?

Thanks to anyone who can help!

36

General Mach Discussion / Re: Curious problem with arc error

« on: August 22, 2010, 01:18:35 PM »

Eureka!!!!   I finally found the cause of the arc errors

On the first positional move in any of my programs, my CAM software (BOBCAD) was not outputting the X or Y axis position if it was zero.  For example, if the first move was to X1.0 and Y0.0, it only output the X1.0, but there was no Y axis output in the gcode.  When the next positioning command was a G02 or G03, MACH3 would attempt to interpolate the arc motion based on the current position of the axes in the workpiece coordinate system.  Since the initial motion command did not always specify both the X and Y position, the value that MACH3 would use for the unspecified axis was whatever the current position happened to be.  Normally, I position the machine to the location where I wanted to cut my inlay pocket, zero the axes and then load the program.  When I did this, things worked fine.  However, if I tried to load the program before I zeroed the axes, the unspecified axis position was always wrong (not zero).  So, the arc error would be signalled.  I think I just confused the issue by trying to load the program at different times.  Sometimes I had zeroed the axes and sometimes I hadn't.  In doing that, I never saw any consistancy in when the error would be flagged.

So, I've edited all my existing programs to set the missing X or Y axis output in my first move.  In addition, I've changed the CAM configuration to force the positional output of both axes on initial moves.  Under Setup->Coordinate format->Initial position, I changed the X and Y "Initial position" values from 0 to 9999.

37

General Mach Discussion / Re: Curious problem with arc error

« on: August 21, 2010, 05:00:17 PM »

Thanks for the tip, but that's not what I'm looking for.  It's working now (re-read the my post).  Besides, I tried all those things when I was having the problem and they had no effect. What I'd like to know is why it stopped working and then started working again when I didn't actually change anything.  

38

General Mach Discussion / Curious problem with arc error

« on: August 21, 2010, 02:19:50 PM »

I'm using BOBCAD V19 to created my geometry and gcode.  I'm using MACH3 V3.042.020 to drive a Gecko 540 controller connected to my Taig CNC mill.

I've run into a curious situation that I just can't figure out.  I recently started programming various patterns for my pool cue inlays. On the pocket program for one design (basically a diamond shape with curved sides), I got the error "Radius to end of arc differs from radius to start" when I tried to load the gcode in MACH3.  I searched the forum for this error and found two likely causes.  Wrong mode for arcs (abs. vs. inc) or rounding problems between my CAD program and MACH.  Since I knew that my arc mode was correct, I assumed that it was a rounding problem, so I tried all sorts of modifications to the design in an attempt to counter this presumed problem. 

After driving myself nuts and always getting the same error when the program was loaded into MACH, I realized that I had programmed a similar design previously and did not have a problem.  To my surprise, when I loaded that program (that had worked fine in the past), I got the same error.  Since I had run out of ideas, I tried something that I thought was stupid.  I went into the General Config and changed my arc mode from incremental to absolute (even though I knew that incremental was correct).  Surprised again.  Both programs would now load without the error (although the Tool Path display showed the arcs incorrectly).  Then I changed the arc mode back to incremental (the correct mode).  Surprised again.  Both programs now loaded without the error and the arcs look correct.  I haven't run the programs yet, but I'm assuming that they will work correctly.

I didn't really change anything (I'm back to the same arc mode I started with and the programs were not changed), but now I can load the programs without the error.  Maybe I should just be happy that everything seems to be working correctly now, but it's driving me crazy trying to figure out why I started getting the error and why flip-flopping the arc mode corrected the problem!?!?!?!??!?

Anybody got any ideas?

39

General Mach Discussion / Re: High speed spindle recommendations

« on: August 12, 2010, 09:40:19 AM »

I don't know how much he would charge, but I'm pretty sure he could/would make a custom collet for you.

At least it wouldn't cost you anything to ask

40

General Mach Discussion / Re: High speed spindle recommendations

« on: August 12, 2010, 09:03:48 AM »

Hi Hood,

You might want to take a look at Wolfgang Engineering on eBay.

http://shop.ebay.com/wolfgang314/m.html?_nkw=tb&_sacat=0&_odkw=&_osacat=0&_trksid=p3911.c0.m270.l1313

Sounds like just what you're looking for.