I'm not sure if auto resetting makes sense.

I don't think this would auto reset since I would still have to power the machine on in the ui to reset the drives. Also, the CL57T only allows resetting in this way for following errors and not overheating.

Currently my external estop is wired into the contactor latch for the drives/spindle power. Should I consider changing this?

Looking to join a thread on this topic and collaborate. Is there any progress on a Brake Press UI and a repo or something where I can use/contribute.
I'd prefer not to use a glade UI due to deprecation if possible.

I'm not sure if auto resetting makes sense. Often the alarm is raised when a motor overheats and it will need time to cool before engaging. An alternative would be to incorporate the enable signal into your estop circuit so the drives are only enabled when estop is off.
Cycling the estop will clear the error.

Johnny is on the right track. The following works well with qtdragon.
Tormach sell a granite surface plate with a hole in it for TTS tooling.
tormach.com/small-granite-surface-plate-...KYzs44ICkj1ujSHUakPj

Then you can insert your tools into TTS tool holders and pre measure them with a digital height gauge
www.ausee.com.au/products/digital-height-gauge-0-200mm-8
and record each tool's height into the linuxcnc tool table.
Measure the probe the same way as tool 99.
Then you just need select tool 99 and probe the top surface of your work piece. Now whenever a tool change is required, QTdragon's manual tool change will pause and let you change tools and resume your job.

 My thought was to use the tool setter to detect the toollength of the probe but a combination of multiple spring loaded buttons may throw off the actual tool length.

This should be easy enough to test.  Make a cut at a known height, measure the probe with the toolsetter, and probe the new cut.
 

What I do is put something flat like a 123 block in my vice. I lower the spindle without a tool in it so that it just touches the 123 block. I use TTS tooling so the nose of the spindle is what the tooling is going to seat up against when the tool is installed. With the nose of the spindle on the 123 block I make a note of the ABS Z value. Now I probe the 123 block. Now check the ABS value of the point where the probe tripped. Don't forget to account for the amount that the probe backs off after tripping. Min is .25 inch.

So if the ABS value of the nose on block is -12.000 and the ABS of where the probe was after the probe is -7.750 then account for the .25 backoff and the gives you -8.000 trip point. 12.000 - 8.000 = 4.000 so the probes effective length is 8". Put that value in the tool table as the length for tool 99 (The probe) Then when you touch of on the part it can take the Z position at touch-off and adjust it by the tool length of tool 99 and that value would be the Z would be at if the nose was on the part. Then when the length of the tool is applied Z will be what would put the tip of the tool on the part.

I hope this helps

So should something like this work:

Expected result would be, the alarm triggers the oneshot, which then triggers the amp-fault-in and in turn turns off the machine. The fault is also cleared 0.5s after the oneshot fires thus allowing me to turn the machine back on an clearing the ALM signal.

So the fault pin is only cleared when the drive is re-enabled?

That sounds about right and the fault is preventing me from clicking the machine on in the ui.

Just got done spinning up and testing a 2.9.8 LinuxCNC virtual machine. It works! Or I think it does. If I press-and-hold a keyboard button it travels the jog increment distance (I tried 1in and 10mm, both seemed to work.)

If I just tap the button, it jogs a short random distance. In other words, I jog it with my keyboard but if I want to stop mid-move, I just need to release the key.

So the fault pin is only cleared when the drive is re-enabled?

If so, you might need some hal logic (and + ones-shot perhaps) to mask the error until a bit after
the change to machine-on state

I did this but now run into a different issue. The driver alarm is setup to signal high for ALM. When I have put the following in my custom.hal to use the alarm signal to disable the drives. This works fine for disabling but I can seem to reset.

To clear the alarm, I have two options:

1. Power off the drives
2. Set the drives to disable and then back to enable. This is a "soft" reset and works when I comment out the line above.

I'd prefer option 2. The first part of the reset is actually completed by the ALM signal in (disabling the drives). However, when I try to turn the machine back on via the axis gui, it won't let me since the amp-fault-in pin is set high.

Hi Andrew,

I don’t have anything specifically for hal configs yet, but it is high on my to do list. Your inquiry has helped me to get off my butt and write up what I’ve been doing and experiencing. I have a knee mill with one micron scales, servo motors & drives configured in velocity mode and ball screws.
The ball screws are from Rockford ballscrew they have an adjustable design that is supposed to be able to adjust the backlash out. It kind of works. The problem is instead of backlash they have “wind-up” I guess technically its not backlash like “open space” but the wind-up causes problems very similar. Because adjusting the ball nuts takes a lot of time I put it off and that’s when things got really interesting. The wind-up became more and more, up to nearly +/- ten thousandths. I could measure it because I integrated the original hand wheel dials in my retro fit. The dials are an excellent reference for tuning, you can literally see the oscillations and overshoot. As you probably know because of the windup all of the direction changes in circular interpolations had oscillations which could be seen the halscope but also in the surface finishes but not really measurable. Going point to point was and still is spot on within a tenth. With so much easy windup in the ball nut the cutter would occasionally grab and take a really heavy bite (climb cutting) and pull the wok piece/table into the cutter. It was easy to hear and almost visually perceivable when it happened. When it happens it is so very fast, so fast that I believe it’s beyond the linear scale encoders ability to read and it misses counts and results in a position losses.

I’m pretty sure this is happening because when cutting a pocket that steps down in increments the pocket migrates. Since the grab usually happens in the same place on each level it migrates the same direction, it’s very repeatable. After a few pocket increments I would command the tool to go to program Zero and it go to where the control displays zero but it is NOT at work piece zero. When I back-off the cut parameters so there is no tool grabbing (really light cuts)there is no loss of position. My gut has been telling me this is most likely NOT a problem for large machines with very heavy tables and very little backlash and I’m not sure how much a dual loop feed back will help with the grab and missing counts situation with my machine. If the ballscrews were truly zero backlash there would be no problem, potentially no need for dual loop feedback. I’m going to try some things, hopefully I’ll get some time to do it this winter.
-Doug

Can you compare with PLANNER_TYPE = 0
can you share your testing g-code?

I just need to home with 3phase planner (because of my own code) and then after each joint is hommed I want to use the scurve 7phase stuff..

 It is just quick setup and forum is my external notepad ... 

Luca can I ask you about your ideas of optimalization of the code to avoiding the spikes? 

Which rabbits do you have in your hat btw?