Is it possible for Mach3's version of G-code to know the current XYZ position of the machine?  I'm finding this surprisingly difficult.

I see that parameters from #5161 to #10306 can access offsets, though AFAIK that's offsets of the coordinate system from machine zero but not the coordinates themselves.

For example, I'm needing to write an O-routine to grow a rectangular pocket.  The routine will not know which coordinate system is currently selected, but there are 2 parameters it uses for X0 and Y0 of the rectangle center.  So, if current position is Xcurrent,Ycurrent=-5,3 and X0,Y0=1,1, it needs to run a rectangle centered around X0,Y0 using -5,3 as a starting corner.  The first move should be G1 X[2*#X0-#Xcurrent].  But to do that, we need the Xcurrent but it's strangely absent from the parameter list, or am I misreading the list?

I could assign X,Y manually to yet another #parameter, but those are already incredibly messy.  It's pretty undesirable as a solution.

NO you cannot directly read the DRO values into Gcode .

BUT it can be done(;-)


THe only way it can be done is to use your Macro pump to copy the Positional DRO values over to a Gcode VAR.

In the macropump  you would make something like

SetVar(100,Getdro(80))   That would feed the(DRO) position value to a gcode var that can be read directly in Gcode as

  G1 X [#100 * 2]

YOu would setup a line to copy over each axis DRO value needed. That way they are always available as a Gcode VAR.

Just remember the macro pump only updates 10 times per second  but this process does seem to work ok

Hope that helps, (;-) TP

So when you say it updates every 0.1sec, it could give an incorrect value?

The "official" correct XYZ coordinates are always fixed at the start of a line.  I mean by:
G0 X1 Y2
G1 X1 Y10
#20="Y-value"
G1 X2 Y30

#20 should of course get 10 by a logical interpretation.  That would be the useful number.  But if it samples the DRO, the axis is in motion and going through acceleration/dec smoothing so the value it gets would vary depending on the moment it samples.  Are you saying that's what would happen with this macropump thing?

Depending on your look ahead setting that is possible. One way to assure it not happening is to use a G04 P0 just ahead of where you need to see the values. This forces Mach to empty the buffere THEN it can read the positional values and  be accurate as MACH will NOT be moving


G0 X1 Y2
G1 X1 Y10
G04 P0       ' this causes mach to empty the buffer before starting the next move. the p0 setting insures that mach does not really pause
G1 X2 Y#20

We have had no problems doing it this way, (;-) TP

Does the G04 P0 require the machine to bring the axes to a stop, just without pausing?
I mean:
G00 X0 Y0
G01 X1 Y0
G01 X2 Y0

would normally be executed without deceleration to zero at X1.

G00 X0 Y0
G01 X1 Y0
G04 P0
G01 X2 Y0
Would it decelerate to a stop at X1 and accelerate up to move over to X2?

there may be a micro pause as the buffer has emptied and mach has just begun to refill it. But it is barely noticable.

Remember Mach runs a buffered system it is NOT real time. BUT it does an extremely good job at creating smooth movement.

(;-) TP

I don't understand what a "micro pause" would be.  If the pulsing engine is running at 40ipm, it is impossible to "pause" by simply ceasing stepping for 50milliseconds and then resume 40ipm since this would violate acceleration rules and would cause the motor to stall and lose steps.

Say we turn the motor acceleration down real slow.  On the above example- would it slow to a stop at X=1 or keep going past it without slowing down?

ALL code is preprocessed and the pulses are stacked up in the buffer( that is why there is a slight runon after you press feedhold mach has to get to a stopping point where it knows where it is at).

When the buffer is emptied by the G04p0 then there "could" be a slight pause as MACH  refills and restarts  the buffer running.

This trick was passed on to me by ART.

I can't really say HOW it all works, only that it does(;-)

(;-) TP