Considering a Full Rewire on a Working Schaublin 125 CNC

The question about the grease in my head is that the spindle seems properly lubricated right now — no strange feeling, no signs of anything bad. So if I pull the spindle and put it back after installing the replacement belt, I’m hoping I won’t make it worse than it is. When it comes to regreasing these high-precision bearings, I’m hesitant — I’d rather learn on less costly spindles first.

Regarding Mach: the seller provided a copy of his Mach3 folder. I didn’t know this before, but you can just put that folder on the PC and it works—no installation, no configuration, no compiling anything custom.

It is not difficult to pull the spindle. I just welded up a U frame to pull against and used all thread to draw it out. 
Schaublin recommended disolving Kluber in some solvent like trichchlorethane which we cant get. I don't yet know whether I screwed up good bearings or saved them. Time will tell. Starting over I would probably have just injected a little fresh grease. It is easy enough. 

If the dovetail fits, you could also just drill and tap the height adjuster holes on the other side.You can never have too many tool holders

I wonder why the replaced the X servo, but left the Z one?

 

RotarySMP wrote:

... Starting over I would probably have just injected a little fresh grease. It is easy enough. 

 

OK, so I can just do that and tell myself I’m not being lazy — it’s science. We’ll make an A/B test and see how the machines behave over the years.
Yes, that sounds like it could actually be a thing.

 

I already ordered a tube of Klüber LDS18, according to one of Rotary’s videos, this is the right stuff for the spindle.

It’s really unbelievably helpful to have resources from someone restoring the exact same lathe.

RotarySMP wrote:

...Could you please post some close up photos of that MACH interface board at top RH in the control cabinet. Is that something like a smart servo for Mach 3?

These are: the CSMIO-IP-S (controller), CSMIO-ENC (encoder interface), and CSMIO-MPG (MPG interface). The picture is attached.
I think I’ll try selling these when I don’t need them anymore, but for now they’re helpful for seeing how the last owner had everything implemented.
The screw-terminal to flat-cable interfaces around these modules are something I will probably keep; they might help clean up the incoming signals in the electrical box.And the answer to that L-holder with the bend on the wrong side is actually that it’s for the single back toolholder. I’m not sure how long it would have taken me to come up with that idea.

Hi everyone,
I’ve been thinking about how to handle the toolchanger logic on my lathe, and it’s turning out to be more complicated than I first expected. I’d like to get your opinions on the approach I’m considering.

Problems I’m trying to solve
1. My machine has a 4-position turret plus a back-toolpost. When a tool change is commanded, LinuxCNC needs to decide whether the turret actually needs to rotate or not.
2. Some toolholders can carry multiple tools, so I need a way to define several tool offsets for the same physical holder.
3. A program might use more toolholders than I currently have installed, which means a manual tool change may be necessary.
4. But if the requested tool is just another tool inside the same holder, then no manual intervention should be required.
5. I want to achieve all of this without making CAM programming more complicated.

Nomenclature
Toolholder: The physical holder that can contain up to four tools.
Toolchanger position: One of the physical locations where a toolholder can be installed.
• Back-toolpost = position 0
• Turret stations = positions 1–4
Tool pocket: A logical element in the tool table used to identify and group a toolholder and its tools. A tool pocket maps to a toolchanger position using:
tool pocket number % 5 = toolchanger position
For example, tool pocket 7 corresponds to toolchanger position 2 (because 7 % 5 = 2).
Tool table number:
The line number (ID) in the tool table.

My idea
I’m proposing to use the tool table in an unconventional but structured way:
• Every tool table number divisible by 5 is used as a toolholder descriptor.
This tool table entry represents the holder itself and indicates which tool pocket (and therefore which toolchanger position) it belongs to.
I plan to store the tool pocket number in the diameter field.
• The four following tool table numbers describe the actual tools inside that holder.
These tool entries can be used normally in CAM and have their own offsets, as usual.
In summary:
Toolholder → tool table numbers 5, 10, 15, …
Tools inside holder → table numbers (N+1) to (N+4)

Additional requirements for the component
This approach requires the component to check a few things when a tool change is requested:
• Is the requested tool number divisible by 5?
(If yes, the request refers to a toolholder descriptor, not an actual tool.)
• Does the corresponding toolholder descriptor exist?
The component needs to confirm that the descriptor entry is present in the tool table.
• Is the diameter field of that descriptor a valid integer?
This determines which tool pocket (and therefore which toolchanger position) the holder belongs to.
These checks should be fairly easy to implement.


What this should allow my component to do
• Decide when a turret rotation is required
• Decide when a manual tool change is required
• Select and apply the correct tool offsets
• Remember which toolholder is installed in each toolchanger position (even if that position is not currently active)

Questions
Does this approach make sense?
Is there anything fundamental I may be overlooking?
Any feedback or suggestions would be appreciated!

I suspect you dont need to do any of that. LinuxCNC tool tables aready define both tool number and pockets. Tool numbers are unique, but pockets dont have to be. 

There is a carousel tool changer comp which supposedly already works with the Schaublin tool changer.
www.forum.linuxcnc.org/10-advanced-confi...carousel-toolchanger

So lets consider your example.
For a job we mount all of these tools. The first three go on the three postion gang tooling holder you have. We mount that in turret position 1 which in the tool table is pocket 1.
T1- Spot drill - Pocket 1
T2- Drill - Pocket 1
T3- boring bar - Pocket 1

T4 - RH VCMT turning tool in pocket 2
T5 - Kurling tool in pocket 3
T6 - LH VCMT turning tool in pocket 4
T7 - but we also need a threading tool, so that is on another tool holder, and will be manually changed into pocket 1.

T8 - Parting tool on the rear tool post, which we will call Pocket 5.

I have not looked at the code of that carousel.comp, but suspect it only trigers activity of the tool holder when a pocket in it's assigned range is called.  So if pockets 1-4 are assigned in the comp to the carousel, then the behaviour would be:

At the start of the program, I would add an M1 and a pop up message to remind that the gang tool has to be in pocket 1.
The M6T1G43, the carousel indexes back to pocket 1, if not already there.
First three M6TxG43, the carousel is not called, LinuxCNC just assigns the correct called tool, offset, orientation and nose radius, and continues.
M6T4 G43 - Turrent indexes once, then LCNC assigns the correct called tool, offset, orientation and nose radius, and continues.
It would be at this point that I would have programmed in the M1 stop, to manually remove the gang tool holder with it's T1-3, and load T7.
M6T5 ( and T6) Indexes around one.
Calling M6T7G43 would rotate the turret back to pocket 1, with its changed tool.
M6T8G43 I would expect to again do nothing with the turret and just load the offsets for the parting tool.

It would probably be a good idea to add another M1 and text pop up at the end of the program to remind to reinstall the gang tool in pocket one, so the program is ready to go on a restart.

Of course I could be wrong about that carousel.comp not moving the turret on a tool change which calls a pocket outside it's range (or no pocket). But if that is the case, it would be best to modify the comp. Misusing the tool diameter for this would lose the ablity to do tool radius compensation, which is important on a lathe.

CAM software doesn't care where the tools come from. It just assumes the appear with the correct offsets, orientation and radius.

For tool table hygiene, it might be good to standardise like anything in pocket 1 is called T1xx, in pocket 5 -->T5xx etc.
Cheers,
Mark

 

I may be misunderstanding something, but I personally would not want to think about where I need to insert an M1 to manually change a holder. I want LinuxCNC to make that decision automatically based on the tool table.

That’s not actually the case in my system.
The diameter is only used on the “tool descriptor” entries, which represent toolholders, not real tools.
These descriptor tools never get used for cutting, so they never participate in G41/G42 or wear offsets.
But yes—this could just as well use the Pocket field. I didn’t think of that originally.
I will lrady make that change in the rest off this post.

Why I believe encoding the holder layout in the tool table is better

Here is a heavily simplified tool table to show the idea:
T5 P1 X0 Z0 D0 // holder #1 in turret pocket 1
T6 P— X100.34 Z-15 D10 // spot drill
T7 P— X120.876 Z-32.657 D10 // drill
T8 P— X140.298 Z-15 D10 // drill
T9 P— X160.3 Z-15 D10 // boring bar

T10 P5 X0 Z0 D0 // holder #2 in pocket 5 (5%5 = 0 → rear post)
T11 P— X100.23 Z23.456 D0 // parting blade

The descriptor (T5, T10, T15, …) stores the physical pocket number. so they are th single sorse of trus for this.

This means LinuxCNC can always determine:
Whether a manual holder change is needed
Whether the correct holder is already in place
Where the turret needs to rotate
Which tools belong to which holder
Whether a requested child tool even exists

If we don’t have this structure, I don’t see how LinuxCNC could determine where a tool belongs.
You’d have to manually encode the correct pocket into every single tool entry.
This leads to another issue.
Problem with the pocket-in-every-tool approach

Imagine two tools in CAM that both used to be in turret position 1.
But for a different job, you need to rearrange holders.

Then you must:
Change the pocket numbers in LinuxCNC for all affected tools
Update your CAM tool library to match
Remember to do this every time you rearrange holders
Add M1 manually at the right positions
Hope nothing gets out of sync between CAM and LinuxCNC
This is exactly the kind of workflow that causes human error.


Maybe I am overcomplicating things — but in my head this system makes sense.
It gives LinuxCNC the information it needs to make reliable decisions, without forcing the user to manually sync CAM, tool table, and machine setup every time a different combination of holders is used.

I’m heavily dyslexic, so I write it myself but let ChatGPT make it readable, even though it changes the grammar more than I’d like — it’s still better.

Regarding the question of manual tool changes, what I mean is this:

Consider that you have a toolholder with two tools in tool-changer position 1. Because you’re making a very complicated part, you need more toolholders than you have positions in the changer. In this situation, you will eventually have to exchange the holders manually.

What I want is for the machine to ask me only when my input is actually needed. I’m not too concerned about a few unnecessary moves.

What I do want to minimise is the number of times I have to intervene, and the number of points where I can mess up. That’s why I want a single point of truth for the pocket number on a ganged toolholder.

Edit:
Examples of when it should not do a manual tool change:
Changing to a different pocket that already has the correct toolholder in it.
Changing to the same toolholder but to a different tool mounted on that holder.

And if it does need me to exchange a holder, it should have already rotated the turret so the pocket to be used is positioned in front

The sort of thing you are imagining is a bit of a fantasy for our kind of lathe and use case. A perfectly synced tool table in CAM and LinuxCNC is unlikely to work, as you will never have enough tool holders to never have to edit them. Think drills. I can say from experience that the next size drill you need is never the one loaded.

Maybe on those big machining centers with chain type 60 tool magazines, but it is not going to happen on our set ups. 

In practice, there are two scenarios.
- You are making one off home shop/ tool shop parts. You have enough tool holders for  the most common tools, and you have assigned them pockets where they are most often used. For these jobs, you will often not program full multi tool programs, but use a mix of simple programs for more complex bits using a single tool and Lathe macros for simpler paths where you also manually swap in tools. 
- You tool up the machine for a production run. In this case you will go through and set up each tool, assign a pocket and if needed set manual break points for manual tool changes with our lathe. Tool set up is a fact of life in CNC machining. LinuxCNC can't know which tool holder you are planning to swap in manually.

There are many many more things to work through getting your lathe running under LinuxCNC before you even need to consider this issue.