Considering a Full Rewire on a Working Schaublin 125 CNC

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.