Advanced Search

I took the brave pill and tried rigid tapping for the first time this weekend. Even though it was nerve wracking to watch it worked like a charm.



I read through the documentation for rigid tapping on the LinuxCNC website but there was one thing I couldn't find. How do I do rigid tapping with chip breaking/pecking?

I plan to use your updated deb package. If there are any problems, I will try to compile it myself. Thank you.

What should we do? Any thoughts about validating the filletized trajectory path?

I would just go for the easiest solution for now. Once we see that the optimization actually works we can still think about a better preview solution.

Not sure, I have no issues loading your gcode (after changing the extension from '.tap' to '.ngc'). Do you maybe have a python filter script set for .tap files?

You have a work offset of -90 set for Y (joint1) so your position is actually indeed -110.

No that is not possible, subroutine calls need to use the 'O' Word (O <your_subroutine> CALL)
Note: lowercase lettering is also fine like in my last post. Subroutines can also accept parameter values (O <your_subroutine> CALL [123] [456] ...)
Remapped Mcodes can also pass P and Q words: (M456 P1 Q2)

Up until now I was mostly using VFD's from SEW -- some EMI is to be expected but the interference this VFD is emmiting was unexpected.

Did you use the 'PNCConf' tool to create that config?

haven't looked but I am fairly sure the the software supports mcode with decimal places ? M7.0 or m7.1 etc and so on.

As far as I'm aware Mcode numbers must be integers (Gcodes can have decimals)
You could create a single custom mcode with a P word though.

That icon looks great

 

Hi.
Probes have a specific way to go, before they break. I use this distance to calculate a max velocity while probe operations. For this I use usually fixed accelaration values. Of course debounce times and so on also.

If there will be non predictable acceleration values, or better non predictable distances right now I would struggle to implement such safety checks.

Attached my safety check for easyprobe.

Minor suggestion - leave the mist as M7, and flood as M8 and save the 'derivative' M-codes as M7.n or M8.n

M8 - main flood
M8.1 - supplemental
M8.2 - TSC
M8.3 - washdown

M7 - main mist
M7.1 - supplemental

Etc.

[Deb12, LCNC 2.9, PB APT stable]

Setting up and calibrating my spindle probe and am running in to an odd problem. I'm not sure where to start troubleshooting.

When I run the calibration routine (ring gauge), about one in three times the routine 'misfires'.

• Behavior #1
  • After the second (slow) touch, the probe does not return to center before starting the next move.  The next move (opposite axis) is started at the back-off distance.
• Behavior #2
  • After a fast probe touch, it backs off but then fails to do the second touch and continues on to the next move in the routine.
• Bonus
  • The probe calibration offset field doesn't update after a successful calibration routine.
  • Example: probe a 0.7874" (20mm) ring
  • Results window: X-dia = 0.7886, Y-dia = 0.7884... but the offset field stays 0.000000 as if there is zero trigger distance.

The 'mis-probing' (#1 & #2 above ) has happened in both X and Y axis moves, and not at the same point in the routine.  I don't think it's an error in the subroutines as the behavior isn't consistent.

Settings:
Fast probe: 20ipm
Slow probe: 1ipm
Back-off: 0.025"
Non-probe traverse: 50ipm

I do have a false-trigger logic sequence in HAL to stop 'probe tripped during non-probe move' errors.  This logic only permits the probe signal to pass to motion.probe-input when a probe move is in progress. However, bypassing that logic (probe pin direct to motion.probe-input) didn't change or reduce the frequency of probing routine hiccups.

I've not done extensive testing, but similar behavior has happened twice during the four or five times I just tried probing the ring gauge with a 'normal' routine (not calibration screen).  Probe/spindle orientation doesn't make a difference.

I can fudge the probe tip diameter and wind up with the right dimensions, but I'm not sure where to start on the intermittent 'mis-probing' thing.  I can slow it down and try to see if the distance-to-go is appropriate before each move, but I'm not sure I'm going to catch it.

Any suggestions?

Hi
I know it's been months since I did my last post but i've been fiddling with this thing in my spare time. just to clarify, I have a Probotix box with motors, which I plugged into the computer running the mill and I could jog those motors. when I checked the voltages to the motors on the control box thats not working, I found the red and black have 22ish, the white and gray have the same but when I jog it doesn't change. What brings that signal to the driver. Thanks