I have my MAX-Z-LIMIT set at 20mm & MIN-Z-LIMIT set at -255

Usually when I run a program, as I set home and stuff like that manually I'd home to a mark on the column, then bring the tool down to a height of 6.35mm above the stock, set by a pin, touch off at that height. Which sets the Z zero on the stock.

Unfortunately the 2.9.3 image you refer to has been removed from the server.
There is a new image that has 2.9.7 and is much more raspios like.
The thread is here which has one image suitable for both the 4 & 5:
forum.linuxcnc.org/9-installing-linuxcnc...trixie-images#338181

As this is an experimental image I would be very interested in feed back.
If you need to install probe basic there are 2 extra packages to install after following the Probe Basic install instructions:
forum.linuxcnc.org/38-general-linuxcnc-q...-launch-issue#338654

If you are not installing Probe Basic there is no need for these packages.

Hi, this is my first post outside of the Ethercat section.

I'm getting beat up by a z axis travel limitation, although I did somehow get the program to run once. My understanding of the problem is that my g54 is in the wrong spot. 

Fusion 360 says the max Z height is 0.6", so I moved my Z axis almost all the way up, then set the G54 Z position to 0.6". I did have the program run once, but then I stopped the program. When I go to re run the program I keep getting the same z axis error.

I've attached some phone pictures.

   

And one more question. Can I use the same encoder for both feed and MaxVel? I don't really like the two-button operation for feed control

My maxveloverride isn't working. It's on enc3, and spindle override and feedrate override work there, but not maxveloverride. Is this due to gmoccapy? The entries in the HAL file look the same as for spindle and feedrate.

Ok 500 is fine. I knew it is 1000 for 1 ms but not how it scaled.
I was looking for a reason for the following error.
Since the feedback comes from the step generator and not the actual machine,
it seems to me the step generator is to blame.
You get following error even when running in air, right?
Basically linuxcnc, or perhaps the step generator, generates the wrong tool path in Y.
Unfottunately I don't know how to fix it.
 

This image was previously available, but when I tried to reinstall it, I couldn't find the specific "

Interesting I will give it a shot repairing the hydraulic system before abandoning it.

forum.linuxcnc.org/18-computer/54314-10-...ble-retrofit?start=0

Here is a link to the thread of me documenting the process of building the table to get to where it is right now. Yes the motors are overkill but they are not really too big of a form factor and the gantry estimated weight is 400-800lbs. I have the machine geared to run 700ipm rapid if I remember correctly. Alot of force required to rapidly change directions at fast cut speeds on a gantry this large. And yes the list is long. Really I need help documenting and planning this project to speed things up. Draw a wiring diagram and point me in the right direction for parts. I want a diagram so its easy to fix for the next guy, and I can make sure then that everything is properly grounded/bonded and resistant to interfearence. The only thing I forgot on that list is a circuit for e stop maybe using a saftey relay and I may add in a lube pump to pump oil into the tracks and rollers.

Personally I would have the estop connected via Normally closed switch, and the estop is signaled via opening connection. This way if, for whatever reason, the estop wire is broken or falls off either connection the machine will go into an estop condition.
The way you have your schematic, you'll only know that something is wrong with the estop when you go to use it.
I'd rather a failing estop not let the machine run.

That's what I originally thought (onboard looking after making VIN a safe value from VFIELDB) but the more I looked at it the more nervous I got.
Thanks for the verification

Moving ahead in glacier like strides, limit switches are next.
M

If I use the following code which has the one missing dash error that I corrected:

# estop
loadrt estop_latch
addf estop-latch.0 servo-thread
net estop-loopout iocontrol.0.emc-enable-in <= estop-latch.0.ok-out
net estop-loopin iocontrol.0.user-enable-out => estop-latch.0.ok-in
net estop-reset iocontrol.0.user-request-enable => estop-latch.0.reset
net remote-estop estop-latch.0.fault-in <= parport.0.pin-in-10-not

The bug-a-boo for me is how do I tie the GPIO25 to the remote-estop. Do I change the last line to:
net remote-estop estop-latch.0.fault-in <= hal_gpio.GPIO25-in-10-not

?

Most normal wiring would be:

FIELDA  +24V
FIELDB  +24V
VIN (unconnected)
W1 LEFT