What, exactly, is Hands-On CNC?

[Jeff]

As an introductory post, I'd like to explain more about what I mean by Hands-On CNC machining.  Way back when I started my first company making robot arms, my machinist made all the parts by hand.  Well, almost.  He had a partner in the same shop with a CNC mill.  He didn't think to much of his partner, and was constantly pointing out that by the time his partner got his G-Code program written and tested, he could have long finished making the part by hand.  And it was true.  I was getting sets of parts made 2 or 3 at a time, and he was still faster.  However, there was one part he couldn't make by hand, and he'd have to hand it over to his partner.  When it got to making 5 or 10 of something, the CNC clearly won, but for the bulk of the work this shop did, my guy was far more productive.

CNC programming and CAM software has gotten infinitely better over the last 25 years, but there is still no end to the number of diddly little jobs I want to do on a milling machine by hand. Drill a few holes, widen a slot, take a little off one edge.  I'm not about to write a G-Code program for this, or even bother bringing up a CAM program to generate G-Code for me.  For simple things, I just want to clamp my part in place, turn on the spindle, and then turn the cranks.  I do, however, want a DRO display to tell me exactly where I am.

At the same time, there's no substitute for CNC control.  For carving 3-D surfaces, there's really no other way.  For any halfway complex part designed in CAD, CNC machining is way easier.  Even when machining by hand, I may want to bore a hole for a bearing, something that's also easier with CNC.  That's why I designed the Lobo milling machine the way I did.  It couldn't be just a CNC machine - it also had to be convenient for doing stuff by hand.  Otherwise, it would just collect dust.

To start off with, I chose a bed-type milling machine over the more ubiquitous flat-bed router configuration.  The bed-type mill affords the user much better access to the tools and work piece for setting origins, hand machining, applying coolant, etc..  Bed-type mills also make it easier to have a large Z-axis range of motion.  This means you can mount a vise on your table and still have room for deep machining - something you can't really do on most flat-bed routers.

The other enabling technology is the use of servo control rather than standard stepper drivers.  Aside from performance advantages, the encoders on the motors let you keep track of your position with the servos disabled.  The Lobo controller software takes full advantage of this by letting you go back and forth seamlessly between manual positioning and computer control.  Whenever the computer is not actively trying to move the mill, you are free to move it by hand.  Very often, I'll start by running a G-Code program, stop, add some features by hand, go back to CNC, etc, etc.  That's what I mean by Hands-On CNC.

[JohnAspinall]

Agree 100% that making the mill equally friendly for manual or CNC operation is a big plus in usability.

You talked about the role of servo drive in achieving this goal, you also mentioned mill geometry. You didn't mention the G-code interpreter. Are most G-code interpreters, not just yours, capable of dropping into a "don't power the motors, let them turn freely, but track the position for me", mode?

Suppose, for example, I had LinuxCNC as the G-code interpreter. Could it drive your motor driver board with full functionality?

[Jeff]

Most of the experience I have with G-Code interpreters are ones designed for stepper control, and they don't have any ability to track the position if you disable the drivers.  I would imagine, though, that any machine controller/G-Code interpreter designed to work with servos in particular would let you track the position with the drivers disabled (no reason not to, eh?).

However, to use something like LinuxCNC, your would need to operate the Lobo's S3x3 controller board in Step & Direction mode because it doesn't look like LinuxCNC had communications support for the PIC-SERVO controllers on the S3x3 board.  If you need more functionality than our free PSCNC machine controller/G-Code interpreter, you'd probably be better off with a Windows program like Mach3.  This is because we have a separate DRO Windows utility that you can run in parallel with Mach3.  (ie, while Mach3 is sending Step & Direction signals over a parallel port, the DRO program can be separately monitoring the position over a USB port.)  

LinuxCNC can be used with servo control, but it looks like  that requires the PC to be doing all of the servo control (with special hardware connected for reading the encoders and sending analog signals to the amplifiers).  To use an integrated servo controller board like the S3x3 board, it would need communications and control drivers written specifically for the PIC-SERVO controller chips.

-Jeff

[JohnAspinall]

Thanks for the reply - very informative. I'm a CNC newbie, but have experience with servos in other areas. My gut reaction is that closing the PID control loop over the PC-to-driver-board connection is not a good idea. It can be made to work, but it would seem to place far greater realtime demands on the PC; demands that are unnecessary, given a decent servo driver like yours.

But what does the (generalized, abstract) interface to a servo controller look like? Once the G-Code interpreter has computed a path and a velocity, what does it send to the drivers? A stream of Go-To-Positions? A stream of Go-To-Position-At-Velocitys?

And what, specifically, does the PIC-SERVO interface expect?

(Gee, I realize I'm hijacking the thread here. It's your board; feel free to manage/redirect as you want.)

[Jeff]

All good questions.  The generalized interface to a servo control system can take a couple of forms, depending on the sophistication of the servo controller: 

- A really simple servo controller (like a Gecko drive) which does nothing more than close the PID servo loop simply takes a goal position as the input and then tries to go there immediately.  With a Gecko-type drive, the position input comes in the form of step pulses (plus a direction signal).  The catch is that somebody (usually your PC) has to put out step pulses at just the right rate for each axis to get the proper coordinated X-Y-Z motion.

- The next level up in sophistication is for the PC to send a series of velocity commands to each axis.  This can considerably reduce the amount of data than needs to be sent, but still, the PC must send velocity commands at very precise timing intervals, and also it must monitor the actual motion and correct for any creeping errors on-the-fly.

- One more level up is how the PIC-SERVO controllers used on the Lobo CNC board work.  Each axis controller has a buffer that can hold up to 120 path points.  The path points are spaced at typically 60 Hz or 120 Hz intervals.  The PIC-SERVO then takes care of moving from one path point to the next with very precise timing *and* at a constant velocity (ie, the motor does not just jerk from one path point to the next).  The result of each motor moving from one path point to the next, synchronously and at a constant velocity, is that the resultant 3D path will be a series of very short straight-line segments connecting one path point to the next.  

From the PC's point of view, it has to calculate all of the path points and load the buffers, but none of this has to happen in real-time.  The PC only needs to be able to check the buffers a few times a second and refill them as they get low, until the path is complete.  Because the PC does not have to communicate at fixed, high speed timing intervals, it is relatively easy to implement the G-code interpreter in Windows, which is otherwise not a great platform for real-time control.   (Linux is easier doing real-time control.)

- The highest level of sophistication is found in multi-axis servo controllers like those form Galil or Delta Tau.  These boards have built -in multiaxis path commands.  Your PC just sends them a X-Y-Z goal point, or a set of arc parameters, and the board takes care of execution until the path is complete.

You can find complete low-level details of using the PIC-SERVO's path mode in the data sheet: jrkerr.com/picsrvsc.pdf.  There are also various software examples at jrkerr.com/software.html.  

-Jeff

[JohnAspinall]

Thank you; excellent explanation at a level of detail I don't often find in most CNC-hobbbyist presentations.