Hello Guest it is March 28, 2024, 05:51:24 PM

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - bsharp

Pages: 1 2 3 »
1
General Mach Discussion / Re: Wrong position
« on: June 06, 2015, 03:11:35 PM »
The computer is getting pretty old and it wouldn't surprise me if it had a few bits of bad memory. I think I will check that out first as its probably getting time to replace the old PC with a newer one.
I know there are issues with the cutter comp so i always just change the code.
It is version 2.0

Thanks for the response at least I know I am still somewhat sane. :)
 

2
General Mach Discussion / Wrong position
« on: June 06, 2015, 02:43:36 PM »
I have had Mach 3 set up on my Tree journeyman for years. Have done all kinds of crazy things with it with very few issues. Today I was thread milling a small shaft with a thread mill. It is a two pass program with two simple helical interpolations. I ran about a half dozen parts with no problem and was adjusting the feed in Gcode of the interpolations to optimize the cut time.
It made the first interpolation fine but instead of retracting to X-0.5 on the second pass it tried going to X-0.26!$% something at rapid and just snapped the thread mill off?
Once i seen it snap the cutter I hit feed hold and then stopped the program and the Mach 3 on screen DRO was at the crazy -0.26!$%.
Why the heck would it do that? I have never had it do anything like that before.
Would it be a computer hardware issue? Has any one else had this happen?
It concerns me because thread mills are not cheap and certain parts I make and work on are very expensive.

Thanks  

G40 G49 G50 G80
G90.1
( 0.375 DIA 20 PITCH THREAD MILL )
T12M6
M3S1400.000

G00Z0.5
G00X-0.5Y0.000
G00Z-0.90
G01X-0.375F7.000
G02X-0.375Y0.000Z-0.950I0.0J0.0F14.000
G00X-0.5      (<---------------------------------------- This is where it went buggy !!!!! )
G00Z-0.900
G01 X-0.365F5.000
G02X-0.365Y0.000Z-0.950I0.0J0.0F12.000
G00X-0.5
G00Z0.5
M30
M5

3
General Mach Discussion / Re: Cutter Compensation
« on: October 28, 2008, 12:48:24 AM »
That's the thing I think it need's a little more than just a few bugs fixed to get it to work right. You shouldn't have to fight with the thing to make it work. Like I said I don't use compensation on the Mach mill so I never realized how bad it actually works. Figured it would be a simple thing for the Mach burning table like with the Mazak Lasers and MG plasma cutter but nope Mach instantly turns into a pain in the but as soon as you call a G4*. But even with the sad excuse for cutter compensation it is well worth the money. I do hope it gets fixed but I am not going to hold my breath.

Thanks for all the post to my topic
I am done with it.   

4
General Mach Discussion / Re: Cutter Compensation
« on: October 27, 2008, 08:35:25 PM »
I think I just was not explaining my self enough.
The cutter comp in EMC is atrocious. Basically non existent. I think it was just never fully developed.
And after looking at the EMC source code I am amazed it works as well as it does.
What it mainly lacks is the curve fitting part of the complete cutter comp package that most industrial controls nowadays have.
I believe that is what ART was trying to do with Advanced Compensation. Advanced compensation sometimes works but is buggy and problematic. I sat and thought about this for a few hours and noticed that in any profile that you would use compensation on would be ether a open ended or closed loop profile. Open ended profiles are not a problem. But it is when you get into complex closed profiles it gets buggy. Now with any closed loop profile you will only have one intersection. If for some reason the tool to be offset is to big for the profile this will cause another intersection in the generated offset profile. If you simply stop at that second intersection witch will be at the radius of the tool and continue on from that point within the current profile. It would be no different than milling an internal square with a 1 inch cutter and expecting the corners to be perfect 90'S. Would you do that of course not so doing this wouldn't be any different.
I have attached some pictures to explain a little about what I am talking about
The first three sets are of common offset geometry and show how Compensation in the software generates the tool path "Offset Geometry". The last is and example of incorrectly compensated geometry "tool to large for profile". My suggestion would be to trim the geometry at the second intersection like I had said. But it could ultimately just call an error and refuse to run the code. Anyway it would be a good idea to implement ether to prevent scrapping a part or parts by simply punching in a wrong tool table entry.






5
General Mach Discussion / Re: Cutter Compensation
« on: October 26, 2008, 02:04:30 PM »
If I have to code the exact tool path and not the outline of the part then what is the point of advanced cutter compensation?
It sounds like a simple problem "you just need to offset it" but it is not.

Please read.
http://www.linuxcnc.org/handbook/gcode/diacomp.html

From the source:
"The cutter radius compensation capabilities of the interpreter enable the programmer to specify that a cutter should travel to the right or left of an open or closed contour in the XY-plane composed of arcs of circles and straight line segments. The contour may be the outline of material not to be machined away, or it may be a tool path to be followed by an exactly sized tool"

"Open ended and Closed" Sound familiar?

Thinking that it is simple is probably why it still does not work. And it probably will not work correctly until someone realizes this. 
Fire up an old GE550 control it will do the same crazy stuff. It took even the likes of GE quite a few years to figure it out.
 
All the new controls do pretty much what I said. I program machines every day that have no problems cutting a simple circle at any orientation or throw an err if the projected offset geometry intersects itself or trim the geometry to fit the tool. The simple fact that this trivial aspect of the control is not refined shows the immaturity of it. To make the cutter comp work correctly it will  take a little wider eye view to see than with what has been looking at it. Mach is to promising to be held back by such a primitive gaping wound.

I gave my opinion on how to make "Advanced cutter compensation" work. And I am sure you know what they say about Opinions!
"Everybody has one" And I showed you mine.  ;D

6
General Mach Discussion / Re: Cutter Compensation
« on: October 26, 2008, 12:25:17 AM »


It's cutter comp, not comp / pocketing / magic bad code correction.

It's hard enough to just get it to offset correctly. Comp shouldn't try to decide what I'm trying to do, it should just offset the coded path. That's it.
Quote

Yea but look at the picture in my last post. It did it wrong. I gave my Opinion on how to make it work correctly. What is yours?

7
General Mach Discussion / Re: Cutter Compensation
« on: October 25, 2008, 12:32:16 PM »
This is an old program I ran on my mill. I don't use cutter comp on the mill as the cam calculates for the tool offset.
But to try and better understand where and how cutter comp was goofing up I started trying as many programs as I could.
The picture below is an interesting example of how the arc in the profile should have been trimmed to stay within the starting area.
The profile should never cross its self. Although there is times when you may want to cross a profile like in a figure eight it should not be possible to do so using left or right cutter comp.
It should only recreate offset periphery geometries for the first area that can be painted "Flooded" with a brush "Tool" the size of the current active tool.
The specification of the G4* offset word would determine in witch bounds of the area to fill.
A determination of open ended and area type geometries would need to be determined.
Geometry specifying a G4* word and which does not intersect itself would be considered open ended.
Geometry intersecting itself without the G4* word would be a center line tool path no offset needed.
Geometry intersecting itself with the G4* word would need to be "Flooded" like stated above.

If we can get that working in the X Y plane then maybe we can move on two all three.  ???


 
       
     

8
General Mach Discussion / Re: Cutter Compensation
« on: October 23, 2008, 08:45:29 PM »

9
General Mach Discussion / Re: Cutter Compensation
« on: October 22, 2008, 11:16:44 AM »
That's good news! I will be eagerly awaiting the update.  ;D

10
General Mach Discussion / Re: Cutter Compensation
« on: October 21, 2008, 09:38:31 PM »
Ok after trying just about everything possible. I think it all boils down to two problems.
1:
I think there is a problem with the Stop function if you are using cutter comp.
If you start Mach load a program and hit Cycle Start it will run fine all the way through.
If you press Pause Stop then Rewind and then Cycle Start
Or if you press Pause Stop then edit the code and Cycle Start it will do some very strange things!
But if you type G40 in MDI and run that prior to running the program in any of the above situations it runs fine.

So after contemplating this for a while I figured I would change the rewind button to run a G40 and then an M30.
I also made sure that an M30 and a G40 was in the initialization string and I set to all resets.
So now if I press Pause Reset Rewind and then start it works fine no crazy stuff.

2:
The cutter comp still doesn't work correctly. If I use a linear and an arc lead to cut a circle and also use an arc lead out it will merge the lead in with the lead out and never cut the part  ;D.
I have a bad feeling that this problem is a little bigger than just a little bug. For starters it messes up at strange orientations of the same geometry. This would make me think that the logic for the offset geometric creation is not vectorized.     


Pages: 1 2 3 »