Contest for the most insane member (They will be a Maho owner)

Awesome thread so far, you are my kind of crazy!

Question: did the Mori SL6B come from a shop in Ottawa?

If so I saw that machine sitting in place when I bought my first ever VMC! I remember standing in front of it honestly awed by the size... Most horizontals I've seen are not nearly as imposing to stand in front of as that Mori was!

Crazy are the folks who don't see potential in these fine old machines. I've been wanting to know more about fans and now I know. I love this place

sledgefinder said:

Crazy are the folks who don't see potential in these fine old machines. I've been wanting to know more about fans and now I know. I love this place

Click to expand...

No, crazy are those who take the time to fix them properly, hence why I called this thread "Contest for the MOST INSANE member". For the hours I have spent on my Tree, the MC800H and the Mori SL-6B (Not even including the Daewoo) had I been just working a normal job putting in paying hours I would have been able to easily buy a couple new machines already.

This is why it is important to be very picky about which machines are going to be fixed. If the machine would have a extremely high replacement value like the MC800H (if you tried to spec out a similar machine new) and you have the ability to leverage it's capabilities then it might be worth it, assuming you have the time to soak into without putting yourself in a bind.

The main reason that machine isn't finished is because I have to throttle back my time in so I'm not hurting cash flow by working on it. The Mori SL-6B came from here in Calgary (to answer Aaron) and not only did I get it for a good price but what I make really can benefit from that exact spec of lathe and to get one in excellent condition that can be relied upon for a long time would be quite costly. Not in the realm of the MC800H, but then again it hasn't been the same level of work to go through as the MC800H either.

An update: The last few days I've been focusing on both machines simultaneously, electrical at my home shop and mechanical/paint prep at the bay. Yesterday was mechanical on the Mori and I had been on the fence about leaving the carriage on the machine and just masking and painting that in place... until I moved it:



The lower way has contaminated oil on it and will be cleaned as well as the turcite when the carriage is pulled. Also the X axis cross slide needs cleaning too, so the entire assembly will be coming apart and meticulously cleaned.

I had to drain the gearbox to the Z axis servo and pull the servo so I could turn the ballscrew. This machine has a gearbox to increase the max torque it can put through the ballscrew for greater Z axis force. The DC servo is a very large already so Mori weren't messing around when they designed this machine. It can put heavy force into the part.



I was trying really hard to not completely dismantle this machine to the bare castings but I think it is going to happen anyway. This way I can repaint everything as I like and it'll look very clean like my Tree lathe. At least I don't have to completely go through the hydraulics like I did on the tree, I think anyway. I need to look in the tank and make sure it looks clean. Everything I have drained thus far didn't look contaminated.

I can confirm that this machine is mechanically capable of traveling almost 1000 mm in Z but the chuck eats up a large amount of this travel. If a collet chuck were designed that fit inside the large 6.4" bore of the spindle (Like the Tree has) then I could have the option to gain that travel with the machine if something came up. These are the details that would be hard to know if such an effort hadn't been undertaken. I've increased travels on other machines before and it made the difference between being able to finish the job or not. One time it was very expensive one off job that came down to less than half a mm before the machine hit a mechanical limit. Worked out in my favor that day!!!

Here is the bad news, the Z axis ball screw has lost preload and has a TON of slop. It'll be coming out and getting rebuilt, I'll probably throw in new angular contact bearings on the ends as well. It is unfortunate to find such wear but not surprising. I may just get the screws rebuilt on all the lathes at the same time just so that doesn't need to be looked at again for many years. Almost all of them are out at the moment. I could get the MC800H's done too but the accuracy of the machine isn't dependent on the screws and they don't have any play right now. Having said this it is a massive pain to get them out so maybe now is a good time. At least crating them would be easier having 9 ball screws in a crate rather than 1 or 2 at a time.

Aaron: You are right about how large the SL-6B is, it is very tall. It is taller than my DMU50V which is a vertical mill! The headstock is absolutely massive and the whole machine just emanates rigidity. Because I am in Oil Country I've seen lathes that make even the Mori look small. My next lathe will have a 10+ bore in it, I hope I can find this same model in the SL-6C variety, though a 7 might work well for my purposes too.

Dave

...after some consideration I may just repack the ballnuts opposed to getting the screws reground, the screws are in great shape and I imagine just some new balls would be enough to breathe a new level of accuracy on these machines without too much cost. Time will tell, it's worth trying at first anyway.

What I'm curious to know is how anyone can find out the original specification of the balls when they are all worn already? These are very high precision balls, how to get the appropriate values? I could take the amount of play as compared to the existing ball diameter and then take some measurements of the screw and nut to calculate the ball size to have no backlash with the existing preload setting (these are two-nut preload design) but I'm not certain this is the most efficient way to do it? I can only assume that there is a max size of ball the screw is designed for and then you must keep the balls below that size so they don't rub on the back sides of the balls, they should be making an angular contact with the nut and screw only.

I'm not sure if any ballscrew experts are on here but are nominal values typical for manufacturers or do they change sizes to suit actual units like they do in motorcycle engines with cam bucket clearance shims for valves?

Dave

I've done linear way trucks and the balls weren't worn much. The truck wore the most. Every other ball was a spacer about half thou undersize. I think I went or tenth or tenth and half oversize to tighten them up. Basically worked out to go from a metric size to a fraction size to get what I needed.

Very time consuming and boring to reload the balls.

Hi Garwood,

I hear you on repacking as a process, I've repacked many blocks and nuts just not with new balls, just cleaned ones. I can see how wear would be low on the balls since they are so hard. For some of my units it is corrosion on the balls that would be nice to be rid of, but on those I can just measure the good balls and repack with that.

I've hear of alternating ball size as spacers and I saw some manufacturers even putting in small plastic spacers too to help with friction, lubrication retention and noise at the expense of bearing load area.

Thanks for your feedback.

I just had a lesson in ballscrews on my MH700C that overtraveled out one half of the nut. The 3.5mm balls didn't look good at 10X. Bearing shops in US don't carry loose metric balls. I found them in 440C stainless at MSC so unless I find better information I can only assume they are better than the beat up ones I reassembled with. The washer in between nut halfs determines preload

On the ball nut repacking I have seen guys buy several different ball sizes in tenths increments and kinda trial and error to get a good preload. I have also heard of alternating the balls with one on size and one off size. I think for the money you are putting in getting several sizes of balls will be cost effective as it could easily be different between the different screws of the same model in the machine.

sledgefinder said:

I just had a lesson in ballscrews on my MH700C that overtraveled out one half of the nut. The 3.5mm balls didn't look good at 10X. Bearing shops in US don't carry loose metric balls. I found them in 440C stainless at MSC so unless I find better information I can only assume they are better than the beat up ones I reassembled with. The washer in between nut halfs determines preload

Click to expand...

Why would Metric or inch size matter? You can buy bearing balls in any size you want. Tenth or less increments. The increment is not the problem. You want the size tolerance adequate for what you're doing. If you're balls go up and down in size several tenths they aren't going to work as well as ones that are twice as accurate.

I would not be buying bearing balls from MSC for this. That's probably not going to end well for you. I don't know about stainless either. These should be bearing steel.

Garwood said:

I don't know about stainless either. These should be bearing steel.

Click to expand...

The 440C balls he mentioned are usually hardened to 60HRC, roughly the same as the 'normal' balls made from 52100 so I don't think hardness will be an issue. Wear resistance is actually likely to be a fair bit higher as 440C has a fair quantity of chromium carbides in it after hardening whereas 52100 has relatively low carbide volume.

The engineers I talked to laughed when I said I was trying to get information from a bearing company or supplier. Those days are long over if you don't have an in. They did say 440C is common now and mix or match to 440C or 52100 or I think 8620 should't be an issue. The double nuts on mine are like a pair of 3 row recirculating angular contact bearings. The washer is a distance spacer. I don't doubt odd size balls are available for some applications but putting bigger balls in wont help with thrust it will load it radially think friction heat

More updates on progress, but first, a question about the EPC-8 CPU board used on both my Deckel Maho machines:

Since this thread has started I have learned more about the performance of the Maho 532/Millplus VME based control from a hands on point of view. The control is quite capable and I think it is much more user friendly than the Fagor and Fanuc controls I've used on other machines.

It was suggested to me that I upgrade the control processor from the Intel 486DX2 66MHz to something like the Kingston Turbochip 133, which is an AMD 5x86 CPU on an adapter board that changes the voltage to suit the newer CPU as well as a some other things.

When I started down the path of trying to understand what would work best for the EPC-8 board due to its industrial architecture as compared to older typical home PC boards I started running into terms like "zero wait state" performance and discussions about the bus speed and multipliers and cache... and I decided it was time to ask advice from others that have far more experience in this area than I do. The DAX boards in both these machines, which are different in design in the MC800H vs the DMU50V, are likely more of a bottleneck in actual multiaxis performance than the CPU board is but I would like to see how much I can upgrade the CPU with this existing VME unit. Can anyone comment on what processor they would recommend for a EPC-8 motherboard based on how it laid out and the tasks it will do? The manual and datasheet on the board can be found here:

https://www.artisantg.com/info/Radisys_EPC_8_Manual.pdf
https://www.artisantg.com/info/Radisys_EPC_8_Datasheet.pdf

Since my last post this whole pandemic became an issue. When this came up I decided to move the DMU50V back to my home shop and while I was at it tore most of the sheetmetal off and had it coated with Endura epoxy/urethane. I changed the paint scheme to match the big lathe and soon, the MC800H. Although this wound up being a large ordeal everything is pretty much back together now.

Before:





After:





I switched the windows from Polycarbonate to Acrylic after doing abrasive testing and learning about the hygroscopic properties of polycarbonate that can cause it to start soaking up the oil from cutting fluid and then cracking in areas you wouldn't expect from embrittlement. At the same time an O-ring groove was machined into the windows so neoprene foam o-rings could be installed into the windows to seal them but also allow easy removal later (Unlike the OEM Butyl tape that as used)

Now I'm making new ATC carousels out of billet aluminum to replace the damaged cast iron stock units. The OEM carousels will not work with Emuge/Albrecht Uberchuck tools (They actually broke my carousel! I've had to manually load them since) but I like the tools enough that I've tweaked the design to accept them and still work with everything else. These should be finished in the next day or so. It will be nice to be back at 24 tool capacity again!



More in the next post...

MC800H (Maho Sr.): This machine has been getting far more time and money lately than I probably should be giving it.

Almost all of the sheet metal has been stripped of hardware, straightened as required and sent off for Endura coating with the newer color scheme. It will look more similar to the mid 2000's DMC80FD as an example, with white sheet metal paneling everywhere except the drip pans which are light grey as well as the electrical cabinets. Dark grey on the outside white on the inside (For light reflection, like a paintbooth) of the APC doors and sliding door to the machining area. Deckel Maho switched to lighter grey on the castings in the machining area around 2000 but I think I'm going to leave them dark grey on the MC800H. It would have been easier to change it when the trunnion was out but really for the time and effort involved I'm not sure the change is worth it. The shroud that attaches to the pallets has been changed from dark to light grey already. It has been a large amount of work to remove all the windows, they were put in with the same butyl adhesive that is used on windshields!

The rotoclear was in salvageable shape and will be rebuilt. As with many parts of this machine, it was a good thing no power was applied to it before this process was undertaken for many parts would have been badly damaged.

I started cleaning the MC800H's Tool changer chain parts. This is going to take a long time... since it is a 120 tool chain. A stubby CAT40 tool was used to hold a 3/8 edge finder shank which I loaded into a small drill press. The press doesn't have much torque such that if I grab the tool by hand I can stall it, this is desirable in this case as I wanted to be safe while being able to spin the parts to polish and clean them.







Each "roller" of the chain is clicked onto the tool, spun and cleaned and then taken further apart to do some hand cleaning internally. Right now it's taking me 10 min to clean one but I think it'll get faster as I do more.

Most of the cleaning is done with the white 07445 (Aluminum Silicate, Nepheline Syenite) pads with WD40 to preserve the black oxide finish as much as possible. The areas with light corrosion were lightly spun with abrasive maroon 07447 (Aluminum oxide) pads and then cleaned and greased.

No idea when the MC800H will be done, but at the very least it'll look nice! I'm still undecided on what I'm going to put in place of the pink strips that were on the original machine. I may put in stainless or aluminum flat bar and then put a brushed finish on it. we'll see.

I hope everyone out there is safe in this pandemic situation! I know it given me more time to focus on these large projects.

If the performance of the current control is adequate 'as is' I'm not sure I'd be itching to try to upgrade the CPU. There are a lot of potential pitfalls there, the most obvious of which is that because we're talking about a 'hard real time' application there are likely things in the code that rely on the frequency of the current CPU. For a concrete example of this: there were quite a few old games written during the 386 era that became unplayable on 486 or Pentium machines because the game itself sped up with the CPU frequency... Code written with multiple platforms in mind will use the system clock for timing, but there is no guarantee that there is no code tied to the CPU frequency in the current control.

If the CPU is easy to swap then it should be ok (from a software standpoint) to try it, but it's hard to anticipate what the side effects might be. I'd personally only go there if there were looming performance problems that I needed to overcome...

I am a software developer with ~18 years experience but relatively little experience related to real-time systems or older (pre pentium) systems so take my advice with a grain of salt!

Thanks Aaron for your prompt feedback on this,

My understanding is that the Kingston 486 upgrade kit that uses the AMD 5x86 processor works quite well with the VME board, that has been done and they run every day with no adverse problems (I know a guy in the USA that has done this to several machines). It would be simplest to just do that but those kits are near impossible to find now. I can only assume that getting any of the kits that use the same processor will have similar results? That is only an assumption though which is why I thought I would call out to see if anyone that really knows this subject had any additional insight into this.

I have managed to get my machine to bog down on code but that was due to my filtering settings in my CAM being set to make very small linear movements, much smaller than normal or than what is typically necessary for what I do. This is an example of something that faster processing may be able to help with. I'm not certain if it helps with actual motion related feedrates.

I spent a considerable amount of time yesterday pulling the bottom driptray back off the machine to send off for paint. Next is to pull the electrical cabinets back off (They aren't really installed at this point anyway) and pull the electrical out (Everything is on internal removable plates) and then send all that out for paint too. I'll likely do this with the Mori lathe too, I was holding back on doing the extra work but now that I've seen the results I would much rather just get it done right and go through everything quick while I'm in there, even if this means only just a little cleaning where needed.

aarongough said:

If the performance of the current control is adequate 'as is' I'm not sure I'd be itching to try to upgrade the CPU. There are a lot of potential pitfalls there, the most obvious of which is that because we're talking about a 'hard real time' application there are likely things in the code that rely on the frequency of the current CPU. For a concrete example of this: there were quite a few old games written during the 386 era that became unplayable on 486 or Pentium machines because the game itself sped up with the CPU frequency... Code written with multiple platforms in mind will use the system clock for timing, but there is no guarantee that there is no code tied to the CPU frequency in the current control.

If the CPU is easy to swap then it should be ok (from a software standpoint) to try it, but it's hard to anticipate what the side effects might be. I'd personally only go there if there were looming performance problems that I needed to overcome...

I am a software developer with ~18 years experience but relatively little experience related to real-time systems or older (pre pentium) systems so take my advice with a grain of salt!

Click to expand...

It's really very unlikely that much of anything is tied to cpu frequency. The vast majority of realtime systems are not truly deterministic, but work either with task priority scheduling or deadline based "bounded determinism", in the latter case an external realtime clock is almost always used to calculate the time allocation. In either case a faster cpu is unlikely to negatively affect anything, but it's also unlikely to positively affect anything either.

Typically in modern (read, not ancient) cnc controls, the main cpu is responsible for program interpretation, trajectory planning, HMI/UI, machine IO control (in the absence of a hardware PLC), and visualisation/graphics etc. Motion control is done in hardware with a motion queue from the main cpu. Real deterministic (hard) realtime is already impossible on such a system, with the actual time critical work being contained within the relatively simple motion control hardware. If you throw in a faster main cpu, the only things that are likely to be affected are user facing things - UI responsiveness etc.

This is of course generalised. I am not familiar with, or an expert on OP's control.

gregormarwick said:

It's really very unlikely that much of anything is tied to cpu frequency. The vast majority of realtime systems are not truly deterministic, but work either with task priority scheduling or deadline based "bounded determinism", in the latter case an external realtime clock is almost always used to calculate the time allocation. In either case a faster cpu is unlikely to negatively affect anything, but it's also unlikely to positively affect anything either.

Typically in modern (read, not ancient) cnc controls, the main cpu is responsible for program interpretation, trajectory planning, HMI/UI, machine IO control (in the absence of a hardware PLC), and visualisation/graphics etc. Motion control is done in hardware with a motion queue from the main cpu. Real deterministic (hard) realtime is already impossible on such a system, with the actual time critical work being contained within the relatively simple motion control hardware. If you throw in a faster main cpu, the only things that are likely to be affected are user facing things - UI responsiveness etc.

This is of course generalised. I am not familiar with, or an expert on OP's control.

Click to expand...

Very cool! Good to know!

While everything Gregor said is totally true, especially for well constructred systems, but history is litered with code that made goofball use of CPU timing loops for all manner of inappropriate ways. (Fixing up such behavoir has been an ongoing side show in the software industry for decades.) I have heard first hand that such issues arose in places where you'd expect people knew what they were doing - such as support systems for military aircraft...

The other thing to recall is "hard realtime" can mean even the fastest processor fails due to variable behavoir on buses, in caches, and so forth. Very high average processing speed is no assurance of reliable realtime behavoir.

None of this informs what will happen with the system under discussion.

I'll be readdressing the CPU subject soon but for now the focus is on other parts of these machines.

Here is progress on the ATC plates for Maho Jr:

Tool pocket machining...



Test with "I will break the OEM carousel if you try to use me" Emuge/Albrecht Überchuck to see if the new pocket design works well (The Überchuck is closest to the camera):



Engraving...



First finished Carousel:



In addition to allowing for the aforementioned tool's dimensions the updated design allows for much easier visibility of which pocket you are looking at compared to OEM.

That machine has been a big time investment for you. Looking forward to seeing it running.
Mark