[mm_cristi]

This is the second CNC machine i'm trying to build.

The structure is mostly aluminum plates and extrusions with a few exceptions. The main X-axis work table is cast iron. It is a commercial extension table for a manual milling machine. I have some videos with the modifications i have to make to it to accept the linear rails i intend to mount on it. The machine will have linear ball bearing rails and ball screws on all axis for reduced play and backlash. These parts are very expensive new, so i have them all used from ebay.

I'm using Sketchup to design and make the sketches. I like this tool a lot, intuitive, very easy to use and, very important, free.

Attachment 201810 Attachment 201812 Attachment 201814 Attachment 201816 Attachment 201818

I've got almost all materials and parts needed, maybe except some small things that i can decide on later like shaft couplers and other things. Some of the parts need to be machined, and i'm trying as much as possible to make them myself, not because it is more economical, but because i am learning. The main tool i'm using is another CNC machine i built which atm only has stepper motors mounted on XY axis. Z is manual. Even if it would be nice to have motion on Z as well, somehow it feels safer not to have it yet, as i don't have to care about accidentally typing a wrong Z value in the commands. Anyway, here are a few pictures from the balcony shop where i'm working:
Attachment 201830 Attachment 201832 Attachment 201834

Daniela, my wife, filmed the shop here, i think she liked how i rearranged things to get more work space on the table. Sorry for the combination of romanian and english.

A bit of my shop - YouTube

The most interesting thing here maybe is the software. I completely rewrote it from scratch. It's running under Linux real time (Ubuntu). It is based on a server-client architecture. The server is written in C++, and is capable of interpreting basic commands like motion in a straight line between two points, pause, resume, set parameters and so on. It controls the machine trough the parallel port, and controls speed and acceleration of the motors. The user interface (UI) is the client, it connects trough TCP-IP, and is written in Java with Eclipse. I chose this architecture for several reasons. I tried very hard to use a RTOS (Real Time Operating System) because i was very disappointed by the performance of the old software under Windows. I can easily get 5x times the speed in the motors now. I get no more hickups and stalls in the motors. The reason i split the application in two, is i wanted to have the UI not interfere with the delicate process of controlling the motor pulses. So i can theoretically run one part on one computer, dedicated to controlling the machine, and another one dedicated to showing the eye candy on another computer. Even though atm i'm running both on the same computer which makes the UI less responsive because it's a single CPU core machine. The UI can also run on another OS, since it's based on Java. I chose Java for the UI because it's portable and easy, and this is what i know best. On the server side C++ gives me easier access to resources like parallel ports and other things. I'm thinking in the future to change it again to support G-CODE since this seems to be the standard. Atm it supports some custom formatted commands i invented myself. I could make this an open source project and this could be the biggest contribution from my side to the community if i see the interest out here. I know there already is free software for Linux, which most likely is much more advanced then what i did. Anyway, it seemed much more interesting and fun to try and write my own as i liked, since this is what i'm doing for a living too, writing software. My impression is that there is still missing a good simple free open source CNC software for homemade machine enthusiasts like myself, who like it simple.


One of the most complicated tools i made is this fly cutter made out of a big block of aluminum. Got the idea from someone else, but i don't remember exactly the link.

Homemade fly cutter - YouTube

X axis table and linear rails - YouTube

I worked very hard here to get the surfaces smooth and on the same plane for the linear rails. The milling job that was originally there was a bit disappointing. I had to mill it first, then using sandpaper and repeated measurements, i managed to get it down somewhere close to 0.005mm deviation. In the video i'm mentioning 0.05 but this was because of the stress of talking in a video.

X-axis linear rails mounting surfaces - YouTube

This is one of the most complicated parts of the entire project. It's a block that goes at the end of the X-axis to support the ball-screw and the motor. It will be attached with screws directly to the table. The milling cutter used here is a 16 mm roughing cutter, a bit on the big side for this machine. It's held in an ER32 collet. The spindle and the motor are from an sieg X2 mini mill. I hope to get a bigger motor someday for the new machine, you can see this one doesn't have enough torque.

Need a bigger motor - YouTube

Some pictures of the main support plate of the X-axis. Drilling the holes for the screws that will hold the rail blocks and the ball screw nuts of X and Y.
Attachment 201820 Attachment 201822 Attachment 201824

And that X-axis end part again. There was and still is a lot of material to remove in there. It is still far from finished.
Attachment 201826 Attachment 201828

Thanks for watching and reading, hope you enjoy. I'll try to keep posting as i move along with the build. It's going slowly atm.

[mm_cristi]

I became a bit worried about two (actually three) things in my design:
1. The whole X-axis is supported by a big aluminum plate 25 mm thick, 145 mm wide and 260 mm long. The concern is that this will bend a little under load or vibrate. But there isn't much vertical load usually. So that's what i'm counting on.
2. The linear rails for the X-axis are SSR15. I don't have experience with such things and compared to other builds they look flimsy. I don't have an idea how strong these things are. I am not a mechanical engineer, and please correct me if i'm naive in my calculations. I read in this document: https://tech.thk.com/upload/catalog_...12-12E_SSR.pdf that one such block can take 9kN dynamic radial load. Lateral is half that, so 4.5 kN. I've got four of them. So maximum lateral load would be 4.5x4=18kn. To be conservative, and because they're used, i assume half that, so 9 kn maximum lateral load. That's like holding 900 kg, almost a ton. Should i expect bigger forces during a milling operation ? Should i be concerned at all or is it a safe margin ? Under such forces i presume things will start to slide around and the screws won't be able to hold them tight. Ah and now i remembered the third concern.
3. The linear blocks are not held for lateral slipping by any raised margin. I've seen this is how i'm suppose to mount them in a medium where vibrations occur. But i imagine that if i tighten 16 screws (4 blocks, 4 each), that this requires an insane amount of lateral force to slip. At least that's what i'm hoping for.

Anyway, today i used for the first time a carbide end mill. What a difference. These things are amazing. There are some really smart people out there who designed and built these things. I didn't think there's such a big difference compared to HSS tools. Cuts trough aluminum like butter and it's sharp as a razor blade.
I managed to finish the part that goes at the end of the X-axis and supports the ballscrew and the motor mount. It's late now and i didn't take the time today to make pictures. So focused to finish what i started that i even forget to drink water when i'm working. Hopefully tomorrow i'll have something to post.

[wizard]

This is a very interesting build, thanks for posting!

If you went to Linux with realtime extensions why not use LinuxCNC instead? You seem to have considerable programming talent so the LinuxCNC team might benefit from your abilities here. On the other hand new approaches to computerized machining are always worth looking into. The problem you have though is that G-Code is widely supported with man tools to make life easier for the CNC machinist.

It is certainly a mixed bag if you don't support G-Code you can't benefit from all the software out there that targets G-Code. On the other hand if you target G-Code innovation is harder to do. So I have this idea for you, create a system where G-Code is the low level interface and work on a high level GUI to drive that low level system. This would be similar to conversational programming on some controllers. Frankly LinuxCNC would be ideal here as one can easily change GUIs. Further I suspect the LinuxCNC guys would welcome a high level interface to update their GUIs with

[mm_cristi]

If you went to Linux with realtime extensions why not use LinuxCNC instead?

A very good question. And one that i find hard to answer. I can think of two reasons:
1. At the first look on the projects home page it didn't captivate me. It's hard to explain, i didn't like how it looked, i thought it's too difficult to configure, too difficult to use in the end. It's true i didn't even bother to try it. Maybe i will, and it can very well be that my first impressions are all unfounded. But this is anyway not the most important reason.
2. I wanted to have my own software, made by me, where every bit of the program is known to me. That i know every second what the program is doing. If a bug or something unexpected comes up, i know where to look. If i were to know linuxCNC that well it would probably take more than a year, realistically speaking.

In my opinion the LinuxCNC project wants to be too many things at once. I would categorize it as a very complex framework for building CNC control softare. I think the guys who built it are very smart, but here's the catch. The more complex a software project becomes and the more it tries to be at the same time, the more it scares potential users. Since you don't even know where to start with it. I like specialized software, where i know this software is only for milling machines 3 or 4 axes. Not for lathes at the same time. I hope it makes sense what i'm trying to explain.

But i think you gave me a very good idea, with the high level interface. What i didn't like about GCODE is i have to remember G01 G02, basically numbers. Humans are not good at remembering that very well. For sure if you work in the field 20 years, this is child's play. But for newcomers like me this is bad. So what i could do, is i could make the low level interpreter understand G-CODE. But in my user interface allow the possibility to type REC or RECTANGLE instead of G01 for example. This would make the code more human readable in my opinion, while still supporting automatically generated code in the controller, to take advantage of the software out there which can generate this.
Atm. my user interface looks like this:
Attachment 202654Attachment 202656Attachment 202658Attachment 202660
It probably doesn't make sense to explain it too much here, nothing fancy really. The hardest part is in the interpreter-controller part. Especially accelerations, i really think controlling and fully understanding accelerations is hard, even though it looks simple.

Thank you for the valid question and ideas, and maybe someday i'll get in contact with the LinuxCNC guys, who knows...


Anyway, today i continued with the build. I had to mill a pocket in the X-axis base plate, to make room for the ball screw support and nut. This took again longer then expected. It's always like that. I spend a lot of time with work piece setup and changing tools. I understand now why people invented ATC's.

Attachment 202648Attachment 202650Attachment 202652

Two short videos of the process. Like i said in an earlier post, these carbide cutters are really nice. I can't take full advantage of them yet, but they are worth every dollar. Feed rate here is about 5 mm/sec. I tried different depths of cut, from 0.2 to 3 mm.
Carbide cutter - YouTube
X axis plate milling pocket - YouTube

Cheers.

[wizard]

A very good question. And one that i find hard to answer. I can think of two reasons:
1. At the first look on the projects home page it didn't captivate me. It's hard to explain, i didn't like how it looked, i thought it's too difficult to configure, too difficult to use in the end. It's true i didn't even bother to try it. Maybe i will, and it can very well be that my first impressions are all unfounded. But this is anyway not the most important reason.

User interface, and ones perception of complexity are all valid concerns.

2. I wanted to have my own software, made by me, where every bit of the program is known to me. That i know every second what the program is doing. If a bug or something unexpected comes up, i know where to look. If i were to know linuxCNC that well it would probably take more than a year, realistically speaking.

Will you consider marketing or making the code base open source in the future?

In my opinion the LinuxCNC project wants to be too many things at once. I would categorize it as a very complex framework for building CNC control softare. I think the guys who built it are very smart, but here's the catch. The more complex a software project becomes and the more it tries to be at the same time, the more it scares potential users.

Maybe, honestly I think Linux scares more people away from LinuxCNC than LinuxCNC itself. This is one of the reasons I keep an eye on the different projects out there to do G-code on micro controllers.

Since you don't even know where to start with it. I like specialized software, where i know this software is only for milling machines 3 or 4 axes. Not for lathes at the same time. I hope it makes sense what i'm trying to explain.

I understand, I'd like to see more turn key solutions for 3 axis milling. These guys: Smoothie Project, are about to launch a single board solution which I find very interesting but they did throw in everything but the kitchen sink. Unfortunately the way they did it is a bit of a kludge.

But i think you gave me a very good idea, with the high level interface. What i didn't like about GCODE is i have to remember G01 G02, basically numbers. Humans are not good at remembering that very well. For sure if you work in the field 20 years, this is child's play. But for newcomers like me this is bad. So what i could do, is i could make the low level interpreter understand G-CODE. But in my user interface allow the possibility to type REC or RECTANGLE instead of G01 for example. This would make the code more human readable in my opinion, while still supporting automatically generated code in the controller, to take advantage of the software out there which can generate this.

There are a number of different approaches out there on commercial systems. These are often called conversational controllers. As you not higher level software is used to generate lower level G-code.

Atm. my user interface looks like this:

It probably doesn't make sense to explain it too much here, nothing fancy really. The hardest part is in the interpreter-controller part. Especially accelerations, i really think controlling and fully understanding accelerations is hard, even though it looks simple.

If it was easy we would have all sorts of systems available to use. It is interesting but LinuxCNC took a long time to get to the point it is now. Likewise even commercial software slips, due to those pesky bugs.

Thank you for the valid question and ideas, and maybe someday i'll get in contact with the LinuxCNC guys, who knows...


Anyway, today i continued with the build. I had to mill a pocket in the X-axis base plate, to make room for the ball screw support and nut. This took again longer then expected. It's always like that. I spend a lot of time with work piece setup and changing tools. I understand now why people invented ATC's.

This is part of the reason LinuxCNC is so complex, anything beyond trivial machine control requires a lot of flexibility. There are all sorts of ways to do an ATC for example so you need to be able to adapt to the challenge at hand.

Two short videos of the process. Like i said in an earlier post, these carbide cutters are really nice. I can't take full advantage of them yet, but they are worth every dollar. Feed rate here is about 5 mm/sec. I tried different depths of cut, from 0.2 to 3 mm.


Cheers.

Best of luck, you are bringing new meaning to Do It Yourself CNC.

[mm_cristi]

Thank you, i am thinking seriously about making it open source, i never did something like that before. I used a lot other peoples open source software, and i feel i should give back something.

I know what you mean, linux scared me too. I never even used an RTOS before, and it took me maybe more than a week or so to get it up and running. Because i had to figure out which version to use, than which RT patch to use, the documentation could be better there. I should have documented each step, and each linux command i used, but it's all out on the net, you just have to figure it out of the tons of info. But this is the interesting thing with my software. Because you mentioned microcontroller based boards that can understand G-CODE. The alternative with my approach would be, setup a cheap old computer with linux RT on it, set it up to run the server part of the controller at system bootup. Have a secondary computer, even a laptop, even with wireless connection, even running another OS like windows. You just need a network connection to the controller PC. Then run the interface part of the program (which is portable) on the second machine, and have it connect to the controller PC.

The advantages i see here:
1. you have the full power of a PC to back your controller
2. keeping the flexibility to use a different OS on a daily basis, and avoid too much contact with Linux which is indeed a bit scary for normal humans.
3. complete separation of user interface from the controller, which leaves the controller use it's full potential, while you have a fully responsive user interface.
4. you can completely separate an expensive computer from the whole machine, you can have a cheap computer do the "dirty" work of handling the sometimes dangerous drivers which can fry it, while your laptop or whatever is safe connected to the network maybe trough wireless.

I can even imagine an installation pack that comes presetup with the controller server part. Maybe one that starts everything from a stick. I didn't have time to investigate how easy it would be to make something like that.

If one finds it's an overkill to use two PC's you can still have the interface on the same PC as where the controller is running.

Cheers.

[wizard]

Thank you, i am thinking seriously about making it open source, i never did something like that before. I used a lot other peoples open source software, and i feel i should give back something.

Well that is up to you obviously. It can be a huge distraction though, so you want to contemplate how you will deal with all the different users and the stream of questions, comments and distractions.

I know what you mean, linux scared me too. I never even used an RTOS before, and it took me maybe more than a week or so to get it up and running.

I was never personally scared of Linux as a grew up with computers and have a slight hacker mentality. But I've seen eyes glaze over many times at the mention of Linux. The interesting thing in your case is the use of Java which might lead to a fairly portable application to all major platforms. Currently I tend towards Macs for general use as I like that low level UNIX is never far away on a Mac, yet I have great GUI apps, however the platform needs more tools for this sort of thing.

Because i had to figure out which version to use, than which RT patch to use, the documentation could be better there. I should have documented each step, and each linux command i used, but it's all out on the net, you just have to figure it out of the tons of info. But this is the interesting thing with my software. Because you mentioned microcontroller based boards that can understand G-CODE. The alternative with my approach would be, setup a cheap old computer with linux RT on it, set it up to run the server part of the controller at system bootup.

My thought is that you make the interface to the controller as generic as possible so that you can communicate with an embedded PC running LinuxCNC or any of the other G-code interpreter boards out there. This would allow for a GUI that can be hooked up to a number of different G-code interpreter boards, LinuxCNC or whatever. That would require a modular communications subsystem though. Beyond the communications subsystem though you could concentrate on your high level code and the translation to G-code.

Have a secondary computer, even a laptop, even with wireless connection, even running another OS like windows.

Or we could just leave Windows out of this.

You just need a network connection to the controller PC. Then run the interface part of the program (which is portable) on the second machine, and have it connect to the controller PC.

I'm no expert on LinuxCNC but I believe they already support this. That is splitting the GUI off the controller platform.

The advantages i see here:
1. you have the full power of a PC to back your controller

That is good of course but these days micro-controllers are often 32 bit chips with plenty of support for real time operation. The idea here is to give users of your app options as far as what controller to use.

2. keeping the flexibility to use a different OS on a daily basis, and avoid too much contact with Linux which is indeed a bit scary for normal humans.

Yep! I knocked Windows above because I don't personally like it, however most of the world revolves around Windows and just isn't ready for Linux or even a Mac. Mention BSD and Windows user will run off like a gun shy dog.

3. complete separation of user interface from the controller, which leaves the controller use it's full potential, while you have a fully responsive user interface.

Further that much more expensive PC can easily connect to many different machines, if by nothing else plugging into a USB port. Besides that most of these machines have little to nothing in the way of realtime support and Java has even less.

4. you can completely separate an expensive computer from the whole machine, you can have a cheap computer do the "dirty" work of handling the sometimes dangerous drivers which can fry it, while your laptop or whatever is safe connected to the network maybe trough wireless.

This is the goal, make the controller as cheap as possible as long as it gets the job done.

I'd actually like to see a software package that allows driving multiple machines from one PC at the same time. Either by some sort of tabbed interface in the app or by the ability to run multiple instances of an app at the same time. The idea of course is to leverage that expensive platform across multiple machines. Some might see this as a good idea, but with effort I think it can be done well.

I can even imagine an installation pack that comes presetup with the controller server part. Maybe one that starts everything from a stick. I didn't have time to investigate how easy it would be to make something like that.

Installation is a problem with a lot of thIs type of software. It is never plug and play, some configuration is always needed.

If one finds it's an overkill to use two PC's you can still have the interface on the same PC as where the controller is running.

Cheers.

We live in an electronics age now where it is possible to get, the controller, motor drivers and support interfaces all on one small PCB. I see this as the way of the future as far as controlling cost of CNC systems. One of the problems with LinuxCNC is that it doesn't address the low cost machine segment very well at all, some of the LinuxCNC control systems are as expensive as the physical machine they are driving. Of course LinuxCNC is perfectly capable of also driving much larger machines at very cost competitive manner. However for a person building a small router, laser cutter, Reprap or other small device it can become very expensive sourcing hardware for a LinuxCNC based controller.

So what I'm saying here is that there is a large future available for these low cost boards and the software that communicates with them.

- - - Updated - - -

Thank you, i am thinking seriously about making it open source, i never did something like that before. I used a lot other peoples open source software, and i feel i should give back something.

Well that is up to you obviously. It can be a huge distraction though, so you want to contemplate how you will deal with all the different users and the stream of questions, comments and distractions.

I know what you mean, linux scared me too. I never even used an RTOS before, and it took me maybe more than a week or so to get it up and running.

I was never personally scared of Linux as a grew up with computers and have a slight hacker mentality. But I've seen eyes glaze over many times at the mention of Linux. The interesting thing in your case is the use of Java which might lead to a fairly portable application to all major platforms. Currently I tend towards Macs for general use as I like that low level UNIX is never far away on a Mac, yet I have great GUI apps, however the platform needs more tools for this sort of thing.

Because i had to figure out which version to use, than which RT patch to use, the documentation could be better there. I should have documented each step, and each linux command i used, but it's all out on the net, you just have to figure it out of the tons of info. But this is the interesting thing with my software. Because you mentioned microcontroller based boards that can understand G-CODE. The alternative with my approach would be, setup a cheap old computer with linux RT on it, set it up to run the server part of the controller at system bootup.

My thought is that you make the interface to the controller as generic as possible so that you can communicate with an embedded PC running LinuxCNC or any of the other G-code interpreter boards out there. This would allow for a GUI that can be hooked up to a number of different G-code interpreter boards, LinuxCNC or whatever. That would require a modular communications subsystem though. Beyond the communications subsystem though you could concentrate on your high level code and the translation to G-code.

Have a secondary computer, even a laptop, even with wireless connection, even running another OS like windows.

Or we could just leave Windows out of this.

You just need a network connection to the controller PC. Then run the interface part of the program (which is portable) on the second machine, and have it connect to the controller PC.

I'm no expert on LinuxCNC but I believe they already support this. That is splitting the GUI off the controller platform.

The advantages i see here:
1. you have the full power of a PC to back your controller

That is good of course but these days micro-controllers are often 32 bit chips with plenty of support for real time operation. The idea here is to give users of your app options as far as what controller to use.

2. keeping the flexibility to use a different OS on a daily basis, and avoid too much contact with Linux which is indeed a bit scary for normal humans.

Yep! I knocked Windows above because I don't personally like it, however most of the world revolves around Windows and just isn't ready for Linux or even a Mac. Mention BSD and Windows user will run off like a gun shy dog.

3. complete separation of user interface from the controller, which leaves the controller use it's full potential, while you have a fully responsive user interface.

Further that much more expensive PC can easily connect to many different machines, if by nothing else plugging into a USB port. Besides that most of these machines have little to nothing in the way of realtime support and Java has even less.

4. you can completely separate an expensive computer from the whole machine, you can have a cheap computer do the "dirty" work of handling the sometimes dangerous drivers which can fry it, while your laptop or whatever is safe connected to the network maybe trough wireless.

This is the goal, make the controller as cheap as possible as long as it gets the job done.

I'd actually like to see a software package that allows driving multiple machines from one PC at the same time. Either by some sort of tabbed interface in the app or by the ability to run multiple instances of an app at the same time. The idea of course is to leverage that expensive platform across multiple machines. Some might see this as a good idea, but with effort I think it can be done well.

I can even imagine an installation pack that comes presetup with the controller server part. Maybe one that starts everything from a stick. I didn't have time to investigate how easy it would be to make something like that.

Installation is a problem with a lot of thIs type of software. It is never plug and play, some configuration is always needed.

If one finds it's an overkill to use two PC's you can still have the interface on the same PC as where the controller is running.

Cheers.

We live in an electronics age now where it is possible to get, the controller, motor drivers and support interfaces all on one small PCB. I see this as the way of the future as far as controlling cost of CNC systems. One of the problems with LinuxCNC is that it doesn't address the low cost machine segment very well at all, some of the LinuxCNC control systems are as expensive as the physical machine they are driving. Of course LinuxCNC is perfectly capable of also driving much larger machines at very cost competitive manner. However for a person building a small router, laser cutter, Reprap or other small device it can become very expensive sourcing hardware for a LinuxCNC based controller.

So what I'm saying here is that there is a large future available for these low cost boards and the software that communicates with them.

[mm_cristi]

Been a couple of days since the last update, but i'm still working hard on it and i've been focusing on finalizing the X-axis.

Here are a couple of shots of the modifications i had to make to the base plate to make room for the ballscrew nut block. This also helps increase the travel length by about 4 cm.

Attachment 203486Attachment 203488

I had to modify a little the original nut block that came with the screw to fit in that space in the table. Obviously i preferred to cut the nut than to modify the table. I plan to leave the other end of the screw unsuspended. Other things seem more important than that atm anyway.

Attachment 203490

Here's the thing assembled:

Attachment 203492Attachment 203494

Spent quite some time trying to make everything fit together. Made some annoying mistakes along the way too. Nothing critical, just things that make it look like an amateur's work in some spots. Funny how the brain gets stuck and attached to these things even if some of them will not even be visible.

Anyway, the most difficult thing was to make the screw turn smoothly all the way, even if i left room for adjustments. The ballscrew end block could be moved left and right a little, the nut block attachment screws also had room to move left and right relative to the direction of motion. The nut relative to the block also had room to move up down, left and right a little. But that's where i spent the most time, because this was the most critical space. There was very little margin for error especially up-down. So i had to progressively cut of the top of the block, try to see if the screw still locked, cut some more, repeated about 3 times. In the end it moves under it's own weight if i turn it up. I am still not sure if it's a proper mount. This is the first time in my life i am mounting a ballscrew, and these things are very sensitive to deviations. We'll see how it survives.



But i must say that these screws are serious pieces of engineering. I couldn't detect any backlash. If it's there it's probably under 0.01 mm. Probably under load it will be a different story. Anyway this is a used ground NSK screw. But it's much better than the more than 0.1 mm of backlash i have in the current milling machine i'm using, so annoying sometimes.

[mm_cristi]

Hi guys.
I've been making slow but steady progress with my build. Yesterday i almost finished the nut block for the y-axis ball screw. I made some shots with that:
Attachment 206950 Attachment 206952

and a short video:
CNC2 y-axis nut block - YouTube

The X and Y axis are also mounted together just to see how it looks but i didn't take any photos with that yet. Just the y axis screw and nut are missing, and i am very close to finishing X-Y axis. Still need to make a lot of t nuts for the aluminum profiles, i have some steel bars prepared for that.
Also need to build the motor mounts, and think about couplers. The aluminum profiles need some cutting of the ends too, to make them as close to square as i can with my improper tools.
I'm thinking, once i have the x and y axis functional, to temporarily move the vertical column from my current mill on the new one, to have more space and precision for the parts of the new Z axis, basically starting to build parts of the machine with itself. This is one of the things i like best about this things, building itself.

Hope to post some more pictures with all that soon.

Cheers.

[Madda]

From where do you get your endmills? They seem to be good.

I like your project, many hours of hard work has paid off!

[mm_cristi]

I got much of my stuff from ebay. This particular endmill you see in the last video, is from ebay.de from seller outils-tools (i have no gain from promoting), it's a used tool, probably resharpened, but it's indeed one of the best i got.

many hours of hard work has paid off!

Many hours indeed, but it hasn't paid off yet. Not sure if it will ever do. These things are money and time sink holes. If i were to start again i would probably go a different route, probably would buy myself a g0704 and convert to CNC. Would have been cheaper and ended up with a much more useful machine. Anyway, i like to think that the things i learned along the way will somehow compensate.

[mm_cristi]

Hi guys,
i have problems with one of the ballscrews. The design of the machine is such that i have to take the nut out in order to push the screw trough it's support. Also had to cut a bit of the end of the screw, it was too long. Now this is an old screw, with some rust marks on the screw itself. I figured this shouldn't be a big problem because the marks are somehow dispersed on one side of the screw, so the rest looks good and the balls should have plenty of good surface to run on, while some of them are in the areas where the surface is irregular. Important to know is that i remember the screw was turning fine when i got it. The problem is when i tried to mount the nut back, the screw turned much worse than before. It tends to get stuck. Not completely stuck, but it turns very hard in some places, and the places are not well localized. It feels like jerking. This is all while turning by hand. I think if i use it like this i'll probably ruin it.

Attachment 207092

I have zero experience with such screws and i badly need some hints what i might have done wrong. Did i accidentally reverse the nut ? To be honest i don't remember which way the nut flange was. I just mounted it the way i need it to be. Does it matter ? I also know there was a way to take a nut out and put it back without removing the balls by using a retaining cylinder in place of the screw , and that is what i did. But when i saw how hard it turns after remount, i thought maybe some debris got inside somehow, and i opened it, removed all the balls, washed them in solvent. I was surprised to see that some of them had a different color. So i figured maybe they are different sizes. But the problem is now i don't remember which color goes in which circuit. Is it important ? I know i should have been more careful. I could figure which ones are bigger by measuring. I think i tried switching the balls in the circuits last night, i don't remember, it was very late, but i got similar results no matter what i tried. Is it possible that this being a used nut, somebody tried to reduce some backlash and put a set of balls that are too big for this screw ? But like i already said i don't remember it turning this hard when i first received it, and i didn't replace any of the balls. Is it possible that there are too many balls ? Could it make a difference if i reduce the number? I figure no, but i am willing to try any alternative to make it work again. In the worst case i might try to order a new set of balls of smaller size or use it with just one of the circuits filled. I don't like any of these options.

Any help is appreciated.

Thanks.

[Arich0908]

Im just repeating what Ive read ,
Some higher end ball screws use combination or 2 or even 3 different size balls. Every circuit should have the same amount of balls with sized balls . So you probably have 2 different sizes thats why there different colors. They would go in the screw big small big small ect..
It doesn't make a difference what way your nut faces.

[mm_cristi]

Thanks for the quick reply,

They would go in the screw big small big small

but i don't understand this part, should i have the same size in a circuit ? I know for sure i have two circuits, and two colors. You don't mean to say that i should put in the same circuit balls of intermittent sizes do you ? That would be a little strange.
If i understand correctly that one circuit should have one size only, do you think it matters in which circuit a certain size is ?

Thanks.

[Fastest1]

I do believe he means staggering the sizes within the same circuits. I have heard of nuts being loaded like that.

I am not sure of why though. My best guess would be that it reduces friction to some extent while still allowing for load carrying capacity.

[mm_cristi]

Thanks a lot guys, my hope that the solution you suggest might work grew suddenly after i found the same info on another older thread. Seems counter intuitive. I'll try it this evening if i have the time. Could have avoided all the trouble if i would have opened this thing with more care.

[Stigoe]

If I have understood it correctly, it is to reduce friction and wear on the balls. The large balls are what takes the load, while the smaller ones are there to keep the large balls apart.

One way to easier understand it it to imagine a row of equal sized gears meshing with each other. If you rotate one CW, then the next one will rotate CCW and the third CW again. If you then try to put this string of gears down on a toothed rack and try to rotate one gear, will you be able to do so? No, you won't because every other gear will try to rotate the wrong way. However, if you replace every other gear with a smaller gear, you will have no problems rotating the gear, because the smaller gear will not mesh with the teeth on the rack and all the gears meshing with the rack rotate the same way. Now, substitute the gears with the balls and the rack with the groove in the ballnut and it's not so counter intuitive anymore.

Stig

[mm_cristi]

It worked, the screw rotates fine now. I didn't check my email last evening to see your explanation, i just tried the mount with intermittent sizes, eager to see if it works. But i was thinking this morning about it and came to the same explanation, i even wanted to draw a picture and post it for others, but your description is just as good. Neat stuff. I am wondering now if the same strategy is used in linear ball bearings that don't have a different mechanism to keep balls apart.

Thanks a lot.

[Fastest1]

On linear rails are the balls captured in a cage of some form?

[Arich0908]

Im happy it worked out for you and as I said it was just information I read at one time and repeated it to you. Ive never dealt with different size balls in ball screws. Good thing Fastest1 new what I was trying to say. Because some times I dont know what im trying to say ....