Machsupport Forum
Mach Discussion => General Mach Discussion => Topic started by: sshneider on April 06, 2008, 01:30:56 PM
-
Hey All,
I am trying to cut 2 different shapes/paths on the same piece of stock using one program and work offsets written into the program.
G55 = X10 Y10 Z0
G56 = X10 Y5 Z0
First cut referenced to G55 offset. Cut and toolpath display are fine. When machine cuts the cutting path is followed/displayed correctly.
Second cut referenced to G56. Toolpath displays OK, cut is exactly where it should be (starting @ Y5) However, the cutting path shows it is cutting in the area of the first (G55) offset. It's weird. Is this Operator error? Am I missing some setting/checkbox somewhere? Or maybe a bug?
Thanks in advance for any replies!
Sid
-
In answer to the question in the heading - yes it is!!!
I don't know how you set up your machine at the beginning of a job, but offsets are calculated from the homing positions of the machine. When you put in G55, Mach3 adds this to 0.0.0. in machine co-ordinates and then calculates everything from there.
Your display - if it is not in machine co-ordinates - displays your program co-ordinates. So if you have written your program starting at X0 Y0 that is shown on the screen as the bottom left hand corner of your program area ( the area of space the program takes up) BUT you are not actually at X0 Y0 you are at X10 Y10.
On the second half of your program you put in a second offset (G56). Mach3 takes off the old offset and adds the new offset, and runs from X10 Y5 BUT if your program again starts at say X0 Y0, on the toolpath display it will overwrite the first one.
Although the displays overwrite, the machine working on machine co-ordinates actually cuts at the right place.
As far as I can see, do not regen the toolpath between the halves of the program. It might however do this automatically when it encounters a new offset. You can use the machine co-ordinates display - but then the co-ordinates will not be the same as those your program is running.
See the Video Tutorial on Co-ordinate systems.
-
Hi, Sid
( Second cut referenced to G56. Toolpath displays OK, cut is exactly where it should be (starting @ Y5) However, the cutting path shows it is cutting in the area of the first (G55) offset. It's weird. Is this Operator error? Am I missing some setting/checkbox somewhere? Or maybe a bug? )
It's a Mach3 View Screen Issue, Been there a long time.
Thanks, Chip
-
Thanks fellas! Any workarounds? I was thinking maybe about using the M98/M99 commands to call subroutines? Any thoughts, ideas, Brainstorms?
THANK YOU!
Sid
-
Hi, Sid
It dose the same thing with G52, G92, Offset's. with M98/M99 subroutines.
I think if you write your G-code "parts" in G91 moves you may be able to work around it.
Brian has it on a list for display screen issues.
Thanks, Chip
-
Cool! thanks chip! I'll give it a go (and wait patiently for Mr. Barker to work it out)!
Regards,
Sid
-
The only way to do it, I think, is having set it going revert to a machine co-ordinates view and regen the toolpath. This should then regen everything from machine co-ords 0.0.0. and then put it on the screen with the offsets.
It should then show the difference between the two different offsets.
-
Jim,
Thanks but, I don't really follow what you are saying. What do you mean by 'revert to machine coordinates'.
The idea behind this was to have the machine do 3 cuts on the same peice of stock at 3 different offset starting positions without any user input. If I have to reset or reprogram or edit G-code to re-orient the cut on the stock, it kind of defeats the original purpose.
The machine actually is cutting correctly, it just doesn't display correctly which is mystifying to me.
Maybe it would help if you loaded the sample G-code and have a look at it on your machine.
Thanks,
Sid
-
No - I understand exactly what you are saying - look at the tutorial video on Co-ordinate systems.
You machine runs ALL THE TIME in machine co-ordinates.
Machine Co-ordinates X0 Y0 and Z0 might be at odd places - usually at the bottom left hand corner of table movement - with the Z at rest at 0. This might be a **** position from which to start any work. Your table might be 10" by 10"
When you write a program, it is normal to start the tool at X0 Y0 (with Z0 touching the top of the workpiece). This is easy to imagine, and you write the program. The whole program area might be 5" by 5". AND TO MAKE IT EASY YOU MOUNT THE WORKPIECE IN THE MIDDLE OF THE TABLE.
To reconcile the position of the mill, with the position of the workpiece, you the EITHER jog the mill to the bottom left hand corner of the workpiece, or you use an offset say G54 which takes your mill to the point at which your program starts and you zero the axis. The axis will not zero on machine co-ordinates because they are tied to the home switches, but if you press the machine co-ordinates button and the light goes out you are then on program co-ordinates - and you zero the axis.
If you then look at the toolpath display it will show the crosshairs at X0Y0 at the bottom left hand corner of the workpiece (the centre area round which you wrote your program). The DRO's conveniently show you at 0,0,0 because it knows that we humans are less intelligent, and we like to see what we expect to see. You start the program and the display conveniently follows the toolpath you have written.
THE COMPUTER HOWEVER knows this is a sham !! it knows it's actual position, according to the MACHINE CO-ORDINATES, is 0.0.0. plus the offsets. It displays the toolpath you want to see, but carries on itself on its own (the true) toolpath.
When you come along and put in another offset, it cancels the first and puts in the second, zeros the display and shows you at position 0.0.0. THE COMPUTER KNOWS THIS IS A SHAM AS WELL - it has just moved to a different location, but for you poor humans, so not to get you upset, it shows that you are at position 0.0.0. because thats what your program says - and it gaily starts to cut, showing you the display it thinks you want to see.
To your eyes, of course, you are seeing two tool displays, one on top of the other - because they both were written starting at the same place - but the COMPUTER IS NOT BOTHERED - it started at the right place according to it's MACHINE CO-ORDINATES and cuts the right path.
I don't know whether that explains it - but if you watch the Co-ordinates video tutorial, I'm sure the two will explain it.
-
To carry on from that, therefore - if you want to see the correct tool path display, then press the Machine Co-ordinates button. If this is lit the display you are seeing is machine co-ordinates - the actual path the machine is cutting. It shows you all the table - that may or may not be a disadvantage - it depends how big your table is.
The DRO's however also change to machine co-ordinates - which will bear little resemblance to what you have written, because they also include all the offsets - and make it difficult to check where you are.
The system works fine if you only have one offset, but if you have multiple offsets in the program this will happen.
-
Jim,
I appreciate your efforts but perhaps I'm not really mnaking myself clear. I watched the coordinate system video thinking that maybe I missed something the first time I saw it ( a couple of years ago). Nope- coordinate systems are as clear as a bell to me.
I think Chip is correct there is a bug in the toolpath display. Let me try and explain with some screen shots.
The 1st image shows the 2 parts I want to cut on the same piece of stock. As you can see the offsets are written into the code and they are being displayed correctly on the table (offset from each other as well as being offset from my Mach Coord/Home Zero).
2nd Image shows the 1st cut in progress. Notice the crosshairs. Machine is cutting AND displaying where it should be.
3rd Image (this is where things get weird) - See the call for the G59 offset? Mach obviously sees it because the 2nd part is 5" above the 1st by 5" (5" = the dif between the G58 & the G59 offsets). The Rapid is also displayed on the toolpath seemingly showing that the spindle will track that path to the new offset start point. HOWEVER, notice the crosshairs on this image. Eventhough the toolpath is displayed correctly, the crosshairs are in the wrong place.
As I said before, the machine cuts the parts where it is supposed and displays toolpath where it is supposed to, it does not display the crosshairs while cutting correctly.
I have tried working around this with G92's but have not had much success yet. Like most bugs, this is not a 'show stopper' but it makes it confusing for operators who expect to see the machine crosshairs cut on the toolpath which is displayed.
Hope all of that makes sense.
Thanks again,
Sid
-
Can you post your code with the two offsets. I.ve run Bubba etc that was on the bottom of the screens display - but tat doesn't seem to be the right on.
I'd like to have a look and a ponder.
-
Jim,
Already posted the G-Code in my previous post. I used G58 & G59 for work offsets. It really doesn't matter what you set them at, as long as they are not the same. (i.e. G58 = X5 Y5, G59 = X5 Y10).
What doesn't look right in the file I posted? Are you talking about the DRO's not matching up with the Gcode as written? If so, notice the G41 cutter compensation command- that's why. But, I assure this program cuts correctly, it's just the issue of crosshair display during the cut.
Thanks,
Sid
-
I think I am missing something - the BubbaG.txt file doesn't have G58 or G59 in - do I have to put them in myself
-
Sorry about that. I was messing around with the G92's and accidentaly posted that file instead. Here it is again- this one should be OK.
Sid
-
Hi, Sid
If you create your 2 Part's G-code's in INC mode, It will display the way you want.
As stated before the offset's G52, G92 and G55 - G59's ...., Don't display correct, But cut fine.
Thanks, Chip
-
I've had a lazy day and put my mind to this, It is much as I said. The toolpath display does not follow the offsets, but displays what it sees taking place in the program co-ordinates.
I wrote a lttle program which is a 4"square (put in to define the limits of the display), then in each quarter of the square is a 1 inch circle, the starting position is determined by g54 (0,0) g55(2,0)g56(0,2) and g57(2,2).
I gradually added bits in to try and make it give a full display, but without success.
It draws the square (g53 co-ords), it draws the first circle(g54 - 0,0) (essentially no offset) - but, then, for the other offsets, instead of moving to a new start point - IT MOVES THE START POINT - then comes back to the first 0,0 position and carries on from there, drawing a circle on top of the first one. It does exactly the same with the other start points.
I even put a g53 move in before the offset to see if that would do anything - but NO, :-\ :'(
I have had it show all four circles on the schematic before it is run ( and then sometimes it only shows 3) - all it does then, when it starts running, is follow the program co-ordinates.
The only thing I haven't done with it is actually try it on the mill - becasue I am set up in lathe mode at the moment. If anyone would like to try it it is posted below.
-
Hi Guys
It seems this view screen bug is still there? At least in simulation mode.
The first pic shows the expected tool path when I load a simple test program: two squares centred on 0,0 with a G52 x20 y20 in between them. This is definitely what should be cut.
The second pic is taken part way thru the second square. The first square is right, but the second square SEEMS to be overlaid on the first one. The display code is ignoring the G52. But when the program cancels the G52 after cutting the second square the locus jumps to the previously offset origin (in the middle of the second square) before tracking back to the first origin. That's a real bug!
Do we have a time frame for fixing this? It shouldn't be that hard to fix: the display gets the tool path right in the (blue line) preview, so the maths is all there.
Cheers
-
Dateline 12/30/12
This is a bug that should have a higher priority than it seems to have!
I haven't worked with Mach3 for about 5 years (a renewby). And this
bug has wasted quite a few hours. Last time I was using a 2D mill with
wheels and quills (SW Track). Now on my new Tormach trusting the tool path
is real important. While I know the value of trial runs etc, creating offline code
kinda depends on trusting Mach3 interpretation of code.
Is the displayed tool path always correct and the cross-hair follower only
sometimes correct?
I'm not sure what should be in the Current Position DRO with G52/G92 active,
but the cross-hair should follow the toolpath no matter what.
While it is true that one could watch the mach-coord DRO to see what is happening,
that's why the graphics are there.
Can we get a plan for fixing this?
-
Yes, this is a display bug.
The display routine does not handle the offset command, but the command interpreter does correctly handle it. There are many other bugs along the same lines in Mach3.
No, I think it is unlikely to be ever fixed in Mach3. The code there is ... a shade convoluted. Bug fixes have tended to break other parts of the code.
The resolution will almost certainly be to switch to Mach4 when it is released. Mach4 is a total rewrite with far better structure.
Hopefully, Mach4 will also eliminate a number of other deep-seated and very annoying bugs in Mach3 by total replacement.
Translation, or explanation: the earlier Mach versions started life as a very amateur software package with limited functionality. It turned out to be hugely popular, and it grew over the years to handle a far bigger fraction of the g-code language, but the core foundation was a bit like the incredible and ghastly mess that is underneath Windows. (With all due respect to ArtSoft.)
So Artsoft has bitten the bullet and started again from scratch. Roll on the Mach4 day!
Cheers