Advanced Search

setp hm2_7i92.0.packet-read-timeout 30

I would set this to 80 ( 80% = 800 usec at a 1 ms servo
thread period), or just comment it out
If you are dropping many packets, that might
be an issue.

Loss of steps might be an issue also. This may be improved
by using the interpolated encoder position, as a 10 count
per turn encoder is going to give a very rough Z axis position
command, only smoothed by the acceleration limits.

The Z motion plots look linear so the main error seems to be a variable offset
at the start. Are multiple passes at the same speed perfectly aligned?
The start and end of motion use maximum acceleration so  possible
locations of lost steps.

Or maybe you have a better way to run more than 3 axis look ahead?
I think along with the s-curve another major update would be the look ahead.

Snowgoeroe,

For my clarity.
You want pathpilot planner running in lcnc?
 

Grotius wrote:

The planner can be used in lcnc within a few hours of work.
I can do that on request.

May I formally request this, please?

The work you guys are doing does seem very nice, but I do think there is value in having >3 axis look ahead using the current TP, on the master branch of LCNC.

Hello.
I have a 3T knee mill 1000mm x axis 400mm y/z axis.
What motor reducer you suggest for a rotating axis ?
Stepper with encoder and planetary reducer is good option ?

scotta wrote:

Hi, you cannot use ST-Link utility to flash the RT1052. You will need to use pyOCD with an ST-link (probably need to flash the CMSIS-DAP firmware).

//github.com/scottalford75/Remora-RT1052/tree/main/CMSIS-DAP
 

sorry it's really not clear, on the video no pyOCD and utility st LINK, I installed pyton 3.13.1 then pip 24.3.1 then pyOCD and afters

Legal obg

Your attachments did not seem to get attached...

A good tip would be to help the next guy with a hal / LinuxCNC question.
 

I am running Stable.

Now the main question I have is as follows: Do I need the probe_basic_postgui.hal to include some code as it currently has nothing and I dont want to cause any issues with runaway etc... What should it include?


 

These are some great questions. I spent some time collecting information to address them.

cakeslob question: I ran the 1"-8 scratch threads again. I tried hand turning the spindle, then ran it at 100, 150, and 200 RPM. I found the following:
1) Yes, you can run the threading G-code and cut the thread by turning the spindle by hand
2) The hand turned scratch wobbles a bit compared to the ones at set speeds
3) The hand turned scratch is the leftmost one in the photo, then the 100 RPM to its right, then the 150 and the rightmost thread at 200 RPM.
4) The spacing of the scratches, measured as best as I can from the hand turned scratch line, is
     a) 0-100RPM -0.025"
     b) 0-150 RPM -0.055"
     c) 0-200 RPM -0.085"

This supports andypugh's comment about the Y axis having to catch up the position after it detects the index pulse. The faster the speed, the more the thread falls behind the desired position.

PCW question:
I've attached my INI and HAL files.


Here's the section for the Z axis



I used HALSCOPE and watched hm2_7i92.0.gpio.014.in_not (spindle index) and hm2_7i92.0.gpio.016.in (spindle A). That was working as expected, as I got one index pulse per 10 "A" pulses.


I then watched the spindle index and hm2_7i92.0.stepgen.02.position-1b (Z axis position) while running the threading program.

For 100 RPM:


For 200 RPM:


This looks to me like it's working as expected, where the falling index pulse begins the carriage Z movement. Note that I have steppers and this is not a real feedback signal on the position..That leads me to believe that LincxCNC is working correctly and that my problem is a physical one with my lathe.

M4MazakUser question:
Yes, both the index and "A" spindle signals are driven directly off the spindle.

andypugh question:
I'm using the threading program from the O-code section of the forum (and which I wrote). Before issuing the G76 code, the program moves the tool to the starting X and Z position. I think that there's validity to your comment about the axis acceleration perhaps affecting the spindle synch point.  I'm not sure what to do about it, though. The carriage on my lathe probably weighs nearly 100 lbs, and the stepper motor is probably undersized. I've had to limit my Z acceleration to 2 i/s^2, or it loses steps.

I ran the calcs you suggested (v = sqrt(2as)) for the 8 tpi thread I'm trying to cut. For the final velocity, I need to cut 1/8" per revolution at the set RPM.
For 100 RPM, v = 100 r/m / 60 s/m / 8 r/i = 0.208 i/s
And the distance to reach that speed s = v^2 / 2a, or 0.208^2 / (2 * 2) = 0.011"
For 200 RPM, s = 0.043"

The takeaway here is that the calculated distance is exponential with speed. When I measured the scratch marks from the hand turned (very slow RPM) values I got 0-100 RPM was 0.25" and 0-200 RPM was 0.085", which is exponential behavior. They're also about twice the values calculated in the formula.


So, I'm still not sure there's a path forward to correct this. A larger stepper, able to accelerate the heavy carriage would likely help, in that I could increase the maximum acceleration. But I'm not losing steps, so the program should be able to handle this. Perhaps a servo motor with closed loop control would fix it.

"When the machine stalled, did it write toollength before?"

No it did not.

I will check again shortly. Although, I'd realistically like to see someone's qt_auto_probe_tool.ngc file that
has the versaprobe routines successfully running.

Sounds as if you have the same or similar problem as I and a few others.

You can see the thread  Inconsistent values from Versaprobe  and see if that's what you are encountering.

The probe height and block height are read-only and set based on 3d probe and tool touch off values.

 

Yes it does. It works for 64-bit floats. Also lcec does support it. The whole chain works.
Actually, Scott added support for Ethercat 64-bit floats in lcec on my request.
I have tested with my own ethercat device with 64-bit floats. Works fine.
So it is "just" to make the device use another datatype - 64-bit floats. Unfortunately that "just" is impossible I guess.

Then the question is when do you actually need that much precision for the encoder?
This has been a limitation since day one, and things still work.