Advanced Search

Can you post a plot that contains the encoder velocity to determine
if LinuxCNC or the hardware is to blame?

The odd thing is that the 100 RPM plot looks to be as expected
but the 200 RPM plot is obviously broken. (the Z velocity never
reaches a steady state even though it's  obviously possible with
the acceleration constraints)

Also please use the interpolated position, the non-interpolated
position combined with the low resolution encoder makes
everything worse with it's large position steps. This is the intended
use case for interpolated position.
 

This problem, and this forum thread, all started when I was getting gouging when making a 1"-8 thread. After analysis, I believe that the lathe was bogging down slightly when making later passes in the increasingly deep thread. I've confirmed that the position of the thread changes with speed. The slight decrease in speed made the cutter take a larger bite, which caused further bogging down and then an even larger bite. Eventually, the lathe reached stability and was able to speed up and quit gouging.

Today, I tried making the thread again. I kept thinking that the Monarch lathe motor is large (7HP), and should be able to power through the threading cuts. My lathe has a back gear (speed reduced, torque increased), which I have never used. I put the lathe in the back gear and tried the thread cut. The gouging stopped completely. So that problem is solved to my satisfaction.

The contributing problem, thread position varies with spindle speed, seems to be built in to the LinuxCNC code. Spindle speed should not be changed during the threading operation. I'm not convinced that replacing the Z stepper with a more powerful motor, which would allow me more acceleration, would change this behavior very much. I'm also not convinced that having more pulses per spindle revolution, either through making a new gear with more teeth or using software to synthesize more pulses, would make much difference.

Please let me know if my logic is flawed.



 

Latest Version of program. I found that the entry and exit taper part of the code didn't work. I revised and tested it, so now it's working.

 
 

to my eyeballs that looks like either a 10mm x 1.25 pitch or a 12mm x 1.25 pitch bolt, both are very common on Toyota engines. Measure the major diameter of the threads. post that up and measure from peak to peak across 2 threads. Push come to shove most hardware stores that have a nice nut bolt isle should have a thread gauge, also Tractor Supply has thread gauges as well. Looking at the condition of the threads, I would get a thread chaser tap, they don't cut they just reform thread. If you can't get that to start, you have 2 options.

1. helicoil or timecert repair

2. tap and drill to the next size

if you end up doing a thread repair or oversize drilling, piece of advice, don't use a fine thread, use a course thread pitchs like 1.5 or 1.75, I have no freaking idea why the hell toyota, nissan and honda have to be so stupid about thread pitch in cast aluminum, but here we are 60 yrs later with the same stupid problems.

Hakan wrote:

No idea really, but you can always try the "lcec_configgen" command to see what lcec's guess of a config can look like.
EL5102 is available as a lcec device if you want to look at how it is done for that one. I is a similar encoder I think.

Oh, that was a neat tool! Thanks! That Scott-guy has been busy! The resulting config looks very similar to what i'm trying to do...apart from it defaulting to 1xABC aswell(0x1600/0x1A00) and then i got some of the types wrong(u32 vs. s32)...

However! I restart the module(power off/on) then the new config worked! I'm not quite sure why though, which annoys me quite a lot! I even managed to change the pdos to use 2xAB(with 0x1602/0x1A02) and it still works...and i'm getting proper data from my encoder... I ran a diff between the two configs and apart from the type-error and naming they are identical...

My current/best theory is that one of the configurations i've made yesterday somehow made the module go into an "error mode" of sorts and only a physical powercycle could get it out again. So i might have had it correct in one of my attempts, but since i never powercycled the modules i somehow kept getting "old errors" or something along those lines...jezz... anyways, it is working, so thanks!

/Thomas

Don't think my first reply went through.

I apologise for long wait in reply. I am away with family on holiday.

I did get this resolved. It was a lazarus setup issue. The link is here for those interested

forum.lazarus.freepascal.org/index.php?a...71318;area=showposts

I did an install on VirtualBox as well so that I can experiment further in simulation mode. Had same issues but resolved.

However, now having the issue "Cannot Home While Shared Home Switch is Closed" but will raise a separate thread if I cannot resolve.

OK the drive does all 3 types and so does LinuxCNC with Mesa.
Drive modes from your pictures are:
0 = up/down step pulses
1 = step/dir
2 = quadrature
-
LinuxCNC modes:
0 = step/dir
1 = up/down
2 = quadrature

linuxcnc.org/docs/html/man/man9/stepgen.9.html

No idea really, but you can always try the "lcec_configgen" command to see what lcec's guess of a config can look like.
EL5102 is available as a lcec device if you want to look at how it is done for that one. I is a similar encoder I think.