Advanced Search

 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?

Endian, you should use or2 gates, not and2, if for example only X is homing you still want planner 0
Also the mux2 values I think are reversed.

I just now tested on a virtual machine, QtDragon XYZ Inch simulation. I can select jog increments and click the jog buttons and it seems to move correctly. But my keyboard is jogging in continuous mode regardless what increments I select. Resulting in a random amount of movement each time I peck an arrow key.

My LinuxCNC version is 2.9.2, I didn't find quick where to see what QtDragon version I've got.

Small increments is working but not the larger ones, same as you described.

Sorry to bring this up again. Now upgraded to the latest release of Linuxcnc 2.9.8 as a fresh install. Changed to a new keyboard and the jogging issue with increments is still there.
Software buttons in qtdragon_hd work fine. Keyboard arrow keys for xyz yield random results for anything larger than 0.1mm increments.
Could anyone please try their keyboard to see if they get the same problem?
Thanks in advance

Hello, I picked up awhile back a 3D touch probe and I can't seem to wrap my head around Z zero.
 I have not installed it yet, installation and configuration I have no issues. I currently have a tool setter and touch plate.

 My question I can't see in my head is Z zero, when the touch probe detects a material surface Linuxcnc has no idea where that probe tip is in space so of course it Zero's Z. Now when you change to a bit and the toolsetter routine creates a zero offset for it the offset is to what?

 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.

 Thoughts?
Thanks

Attaching what documentation I could find, though these refer to the boards having baud rate jumpers, which mine did not.