Am I thinking about this correctly?

[krby]

I'm posting to get a head check on what I want and if I'm thinking about it the right way:

Overall, I'm looking at a benchtop CNC mill, something about the size of a PM-25. I've done some research and realized there's quite a bit of overlap with the concepts of a 3D Printer (which is basically a CNC hot glue gun).

What I think I'd like to end up with is a small CNC mill that I can also use in sort of manual mode.

On the electronics side, it looks like motor, drivers, a controller, and a computer. The computer interprets the g-code, sending pulses to the controller which then uses the drivers to rotate the motors a specific distance.

Comparing this to a non-CNC mill, the computer and its monitor can serve as a DRO, right? Do folks use CNC machines this way? Are MPG pendants used to control are would I continue to use the wheels on the mill?

Also, historical posts make me thing CPU power was a problem in the past, is that still problem given modern PC hardware? I'm assuming CNC controllers no longer use parallel port connections, and USB is fast enough? For comparison, on one of my 3D printers, the "PC" is a Raspberry Pi4, and it is capable of controlling 7 stepper motors (4 motors for Z, 2 for X/Y, 1 for the extruder) without breaking a sweat.

 

[ttabbal]

Unless the cnc has encoders, the computer DRO is just telling you how many pulses it sent. So it wouldn't be able to tell if you moved things manually. I've seen people do things like that with the pendant, but beyond the really simple stuff, it makes sense to use gcode or the interactive programming if it's available.

3d printers are using even less cpu. Mine still runs an 8 bit AVR. CPU might be a problem for interactive programming systems, but gcode is really simple. CAD/CAM can use a lot of power, but you don't need that at the machine.

USB is fast enough, but you need a microcontroller on the other end to convert the data into pulses for the stepper controllers. Parallel port systems just connect the drivers to the parallel port and the computer drives everything directly. A pi could easily handle that with the gpio header.

 

[krby]

Unless the cnc has encoders, the computer DRO is just telling you how many pulses it sent. So it wouldn't be able to tell if you moved things manually. I've seen people do things like that with the pendant, but beyond the really simple stuff, it makes sense to use gcode or the interactive programming if it's available.

3d printers are using even less cpu. Mine still runs an 8 bit AVR. CPU might be a problem for interactive programming systems, but gcode is really simple. CAD/CAM can use a lot of power, but you don't need that at the machine.

USB is fast enough, but you need a microcontroller on the other end to convert the data into pulses for the stepper controllers. Parallel port systems just connect the drivers to the parallel port and the computer drives everything directly. A pi could easily handle that with the gpio header.

Ok, so a typical setup is PC running Mach3 or similar interpreting g-code and providing a GUI (where I could manually enter g-code) connecting via USB or Cat5 to a CNC motion controller (the MCU) which drives the motors. In this situation the PC is generating the steps.

So from your post, I just learned is that CNC systems don't typically use DRO scales mounted on the machine, so the feedback is either none (for a typical stepper motor) or how much the motor rotated if I'm using servomotors, but that still has to account for backlash. Given that scales and DROs which read actual movement are a common addition to non-CNC mills, is surprises me that DRO-type scales aren't used for positional feedback!

In any case, do a lot of CNC mill folks do "manual" milling from their PC GUI? Looking at the displays, it seems like it would be pretty easy to do using the software.

 

[RJSakowski]

I have a Tormach PCNC770 which has a pendant to allow jogging on any single axis ei5ther by stepping a defined increment or at preset rates. I use the pendant to do manual machining more often than I I use G code programming.

The electronics is propitiatory so I don't know what happens internally but movement via the pendant does update the DRO. Originally, the 770 used a parallel port for communication. Tormach updated the controller with a dedicated board using the Mesa 5125 Superport.

 

[RJSakowski]

Ok, so a typical setup is PC running Mach3 or similar interpreting g-code and providing a GUI (where I could manually enter g-code) connecting via USB or Cat5 to a CNC motion controller (the MCU) which drives the motors. In this situation the PC is generating the steps.

So from your post, I just learned is that CNC systems don't typically use DRO scales mounted on the machine, so the feedback is either none (for a typical stepper motor) or how much the motor rotated if I'm using servomotors, but that still has to account for backlash. Given that scales and DROs which read actual movement are a common addition to non-CNC mills, is surprises me that DRO-type scales aren't used for positional feedback!

In any case, do a lot of CNC mill folks do "manual" milling from their PC GUI? Looking at the displays, it seems like it would be pretty easy to do using the software.

The Tormach CNC doesn't have a typical DRO but calculates position based on the number of steps sent from a reference position. As such, it doesn't account for lost motion. With the ball screw drives, this typically amounts to around 1 mil. While I haven't used it, I believe that there is a lost motion correction option that can be applied when running a CNC program to avoid a step when reversing direction.

 

[JimDawson]

Yes, CNC mills can be operated manually, I do so all the time with my machine. For some simple operations it is much faster than creating the G-code to perform the operation. It's my opinion that a MPG is pretty much useless on a CNC mill, especially one with hand wheels, but that is just a personal opinion. Having said that, I use the MPG on my lathe all the time, it's near impossible to set it up without that.

In general, simple open loop step & direction systems do not have any provision for position feedback. So when operating in manual mode with hand wheels, you get no on screen DRO position data. Position feedback is normally provided by an encoder, either rotary, attached to the ball screw drive system, or linear attached to the axis. Some people have used a separate DRO installation to provide position feedback in manual mode.

If you are going to install linear scales for a DRO, you may as well tie those back to the interface board and have a full closed loop system. This of course requires an interface board that will accept encoder inputs and close the loop at the controller level.

My preference is 1 micron magnetic linear scales attached to the axes. This way you are reading the actual axis position rather than counting on the ball screw for position data. Pretty much automatically compensates for any backlash and ball screw error. I find that the linear magnetic scales are cheap, compact, and pretty much bullet proof.

Then it's just a matter of choosing the motor type (servo or stepper) and controller that you want to use. For motor types, there are steppers, hybrid steppers (with the loop closed at the drive level), and servos. Most modern servos will accept step & direction input with the loop closed at the drive level, or +/- 10V analog command input with the loop closed at the controller level.

 

[krby]

Yes, CNC mills can be operated manually, I do so all the time with my machine. For some simple operations it is much faster than creating the G-code to perform the operation. It's my opinion that a MPG is pretty much useless on a CNC mill, especially one with hand wheels, but that is just a personal opinion. Having said that, I use the MPG on my lathe all the time, it's near impossible to set it up without that.

In general, simple open loop step & direction systems do not have any provision for position feedback. So when operating in manual mode with hand wheels, you get no on screen DRO position data. Position feedback is normally provided by an encoder, either rotary, attached to the ball screw drive system, or linear attached to the axis. Some people have used a separate DRO installation to provide position feedback in manual mode.

If you are going to install linear scales for a DRO, you may as well tie those back to the interface board and have a full closed loop system. This of course requires an interface board that will accept encoder inputs and close the loop at the controller level.

My preference is 1 micron magnetic linear scales attached to the axes. This way you are reading the actual axis position rather than counting on the ball screw for position data. Pretty much automatically compensates for any backlash and ball screw error. I find that the linear magnetic scales are cheap, compact, and pretty much bullet proof.

Then it's just a matter of choosing the motor type (servo or stepper) and controller that you want to use. For motor types, there are steppers, hybrid steppers (with the loop closed at the drive level), and servos. Most modern servos will accept step & direction input with the loop closed at the drive level, or +/- 10V analog command input with the loop closed at the controller level.

Ok, this is what I was thinking of doing!
So with the right controller software and interface box, I can connect scales back to the controller software so it uses that for position feedback. This would let me mostly ignore backlash in both manual and CNC operations, and.I think let me have a closed loop system even with stepper motors.

Do I have that right?

One other question: Is it much tougher to use the handwheels with the stepper motors connected?

 

[JimDawson]

Ok, this is what I was thinking of doing!
So with the right controller software and interface box, I can connect scales back to the controller software so it uses that for position feedback. This would let me mostly ignore backlash in both manual and CNC operations, and.I think let me have a closed loop system even with stepper motors.

Do I have that right?

Yes, it's possible to do that. I have done so using step & direction stepper commands with linear scales. This is getting into dual loop territory. As far as I know there are no available controllers that would do this off the shelf with the factory loaded firmware. I used a Galil controller and wrote my own ''correct-on-the-fly'' algorithm where every 2ms the controller would compare the commanded position to the actual position and make an adjustment as needed, almost like a PID loop. Galil controllers have a lot of built in functionality in the firmware, and additionally have a blank canvas for user written programs. Dynomotion products are also user programmable, and I believe the source code is published. Their products are programmed in C or C++, I forget which. Both the Galil and Dynomotion controllers are real motion controllers and do the heavy lifting, rather than the computer having that burden.

One other question: Is it much tougher to use the handwheels with the stepper motors connected?

Steppers do tend to cog, and offer some resistance to turning. This question came up on another forum in the last couple of days, and the user said that the turning resistance was acceptable when operating manually. If I were to use steppers on a manual/CNC machine, I would add a switch or relay that would disconnect the stepper from the drive when I wanted to use the machine in manual mode.

 

[brino]

@krby

Welcome to the group!

It is the first time I have seen the date written Jan 1, 2022, it made me think.......

Brian

 

[Bi11Hudson]

On the electronics side, it looks like motor, drivers, a controller, and a computer. The computer interprets the g-code, sending pulses to the controller which then uses the drivers to rotate the motors a specific distance.
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
Also, historical posts make me think CPU power was a problem in the past, is that still problem given modern PC hardware? I'm assuming CNC controllers no longer use parallel port connections, and USB is fast enough? For comparison, on one of my 3D printers, the "PC" is a Raspberry Pi4, and it is capable of controlling 7 stepper motors (4 motors for Z, 2 for X/Y, 1 for the extruder) without breaking a sweat.

At risk of stepping off into a subject where I am 40+ years and five strokes out of date, I offer my comments from the perspective of a computer engineer and "tinkerer". I have worked with NC machines to upgrade to CNC. And built CNC controls for my hobby machines. Then took them off. But the controllers were adapted to use servos and measuring phase displacement of "selsyns" to measure distances. The computer controls of today, using steppers, are so far advanced that there is little technical comparison.

On even small machines, there are capabilities to move multiple axes concurrently. To compare machine moves to "people" functions is equivelent to comparing apples to wooden stools. Speed is limited to machine moves while cutting. An example in computer terms would be a "band printer" to a "dot matrix" printer. There is simply no comparison. In 1984, U S Steel had a PLC controlling a steel mill. Where 100 tons an hour were cast with 6502s and Z-80s running at 100 KHz.

In the original post, I noted several inconsistancies in computer understanding. A "parallel" port that was used for printers is also used for other "communications" and is today still faster than a USB. It has been discontinued largely because USB is faster in other respects. And simpler to implement for multiple connections.

I need to back out of this because I am also behind the times on computers. There are places where "X and Y" can be moved as easily by hand as by machine. But the accuracy of hand movements cannot compare to machine movements. On smaller machines, hobby level machines, the manual controls exist. And computer controls are added on. On more commercial machines capable of controlling microns of movement, the manual controls do exist. But cannot control beyond a tenth of a thousandth.

.