Relative newbie here running Mach4 hobby to UC100 to Gecko G540. With Mach in the disabled condition,  machine at xyz=0 and displays zeroed, when I load gcode, often times the extents are off or based on the last program I ran. To correct this I have to close Mach an on restarting and reloading desired gcode, the extents are now correct. Is there something I’m doing wrong here to not be able to zero the machine and get the extents correct with gcode loaded? It’s almost like the last values are cached....

You didn't mention if you have home switches. If you DON'T have home switches, I don't know how extents are determined, someone else will have to chime in. If you DO have home switches, I think extents are defined in Config/Control/Homing and soft limits or some such wording. At least that's how I THINK it works. I don't know that extents are determined by the gcode, but as I say, I have no experience with a machine without limit switches.

My settings attached for ref., and mine might seem weird to some, so no pithy remarks on that:)

Of course, I could be completely wrong:)

Tom

I do have home switches, but my working area is offset to this. BTW I’m using a piece of Newport 1/2” aluminum breadboard with 1/4-20 tapped holes every inch; great for positioning setups. What puzzles me is with this offset, the extents reflecting the correct distances from what I’m setting as 0,0,0 (on the stock corner) is correct like 50% of the time. Again, if I zero the displays relative to the stock and load the code (with the movement disabled), sometimes it is correct. If not, close Mach and reload code...now it’s correct. 

I'm likely not understanding. Extents, in my mind, are the extents of the machine travel. Your X,Y,Z zeros on the stock corner can be anywhere you set it. And once set, hopefully your gcode travels stay inside the extents! With the stock Mach4 screen colors, your extents show on the display in grey dashed lines, I guess, really, IF you have it turned on to display, your gcode travels show in colors for feed and rapid moves. If you close the gcode, load another, the new one shows in colors. If no gcode is loaded, you can still see the extents, defined in Homing and Limits, on the screen, showing the spindle location, and it will always be the same, no gcode, gcode, doesn't matter to the extents.

If you have limit switches, they will stop you from going outside the extents, if no limit switches, soft limits can stop this. You should have both, but for sure, soft limits set to the "extents" of you machines travel. Physical limit switches are a last resort, personally in 10 years with my mill, I've never hit one. I have hand cranked up to the soft limit, however:) I have soft limits set .020" off the hard, physical, last-resort, limit switches.

But I digress.................

Hi,
Tom is right, the machine extents are the soft limits. If you program into the Configure/Control/Homing&SoftLimits
with your machine extents per attached.
Then on the Toolpath Ops tabs click <Display Work Envelope> the machine extents will display in the toolpath window.
In my setup it is the yellow dashed line. Just as a matter of interest I attached a 3D view of the work envelope just
to show that all three axes can be displayed.

The procedure is this: start Mach4 with your profile, Enable the control, hit <Ref-All> to home your machine.
Without referencing your machine soft limits mean absolutely nothing and therefore neither does the Work Envelope
or machine extents as you prefer to put it. Get into the habit of referencing yourmachine EVERY TIME you fire
up Mach4, soft limits protect your machine BUT ONLY IF you reference it. At one stage I had my profile set
so that I could not load Gcode, run MDI or even jog UNTIL the machine has been referenced.

What you are observing is the work envelope as it was from the previous session and that in itself does not
sound like it was related to the machine home position either. Soft Limits are MACHINE COORDINATE POSITIONS
and only have relevance relative to a known machine home position.

Craig

My mistaking the vernacular....when I say extents, I’m really meaning the work envelope the CNC will travel within to execute the code. I do have both soft limits and mechanical limit switches on all three axes. When I fire up Mach, I’m referring to displaying the work envelope. In the hobby version, there are two tabs to click on showing the actual position and the “program” extents which I now gather as being the work envelope the code will move within. The numbers displayed in the (program extents) work envelope, are the ones which seem to carry an offset from one executed gcode to the next in spite of zeroing the displays for each axis before starting. It would seem I need to determine the x,y,z position of the work table from true home, set this up as a G54 offset and then use this before starting ? Thanks for your advice gents, a year ago, I knew zip about CNC....bear with me as I ascend the learning cliff. Looks like I have more reading to do..

Hi,
I've been experimenting on my laptop, my machine is at work

I fired up Mach, referenced and loaded a PCB etching job. As you can see the machine zero (the corner of the dashed
yellow lines) and is coincident with the work zero (the corner of the two black lines). The program extents correctly
indentify the rectangle containing the Gcode job.

The next pic is where I deliberately jogged the machine to approx. 15X and 12Y and re-zeroed the X and Y DROs,
ie shifted the work coordinate zero. Note however the program extents have not changed despite the intersection
of the black lines, being work zero, has displayed correctly.

The last pic is the same situation but where I clicked <Regen Toolpath>. Note that now the program extents have been updated,
but note also that they are in MACHINE COORDINATES, not WORK COORDINATES.

Does any of this make sense? It would appear that Program extents are in machine coordinates. I suggest you conduct some
experiments along these lines and I think it will come clear.

Craig

Thanks Craig. Makes sense now. I’ll give your example a try.

I have the issue where I do not see any envelope of my machine extents as craig shows. I have limit switches on x and y and with soft limits set and on, after referencing all I still have no lines indicating my actual work extents. Any ideas???......mach4---4.2.0.4300

Hi,
the <Display Work Envelope> displays the machine boundaries as defined by the soft limits.

There is no feature or function, to my knowledge, that displays the rectangle containing the current Gcode job.
The Gcode toolpath will be displayed within the machine boundaries.

I daresay that it would be possible to have the work extents (distinct from machine extents) displayed.
The method I would adopt is to read the work extent DROs. The DRO's are the registers:
core/inst/PathXmax,
core/inst/PathXmin,
core/inst/PathYmax,  etc

I am unfamiliar with how the tooplath is drawn, other than it is an OpenGL window. What I would do, or at least try, is write a macro
that made some fictitious G0 moves which would be prepended to your Gcode job.

Lets say for example your Gcode job has work extents (in machine coordinates units) of
X: 10-120
Y: 12.5-45
then your macro would generate these lines:
g53 g0x10y12.5 --rapid to the lower extent of each axis
g53 g0 x120 ----rapid along the lower X axis extent
g53 g0 y45----rapid along the right hand most Y axis extent
g53 g0 x10-----rapid along the max Y axis extent to X min extent
g53 g0 x10 y12.5-----complete the rectangle

We only wish the last four lines to be visible thus we would use the API:
rc = mc.mcToolPathSetAxisColor(
number mInst,
number axiscolor,
number limitcolor)
What I would do is 'obscure' initial rapid by setting the axis color the same as the back color.
Then set the color for the next four lines as green/black/blue as you desire. The set the axis color back to whatever
it was prior to this sequence so the normal machine extents etc display normally.

I have not tried this so I have absolutely no idea if it would work.

There are a number of issues or questions that have to be addressed.

Given that the macro contains API calls it MUST be contained within a macro as the Gcode interpreter would baulk
if it encountered an API call in a Gcode file.
Second issue is: 'will the tooplath of a macro be displayed along with the Gcode toolpath OR is the macro ignored while
loading and drawing'....some experimentation is in order.
Third issue: 'if, as I have proposed the toolpath be the combined view of the Gcode job AND the extents macro how would
the display work if it were subject to user rotation or zoom?
Fourth issue: 'can we write a macro that includes g0 rapids and thus be displayed in the tooplath but WHEN the Gcode
runs actually skip over them? We don't want the machine to actually move at rapid speeds around the work extents,
it would almost certainly collide with the vice. So what we want is for the machine to display a path that will never actually
be executed. I have no idea whether that is possible.

Just thinking about it is giving me a headache!

Craig