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