Resolution and accuracy specs?

[yell...@gmail.com]

Can you give me an idea of what resolution and accuracy specs are for the LoboCNC?  I didn't see anything on the specs page.    I need a ballpark.  Are we talking 1 mil or 20mils?

Thanks,

Dave L.

[Jeff]

First the resolution:  the encoders on the motors yield 32000 counts per inch or 0.00003".  The servo control may have anywhere from 10 to 50 encoder counts of error which machining, so motors are able to hold somewhere between 0.0003' and 0.0015", mostly depending on how fast you are going.

The antibacklash nuts on the drive screws, in practice, allow you to hold 0.001 - 0.002".  Again, because of small amounts of compliance in the drive train, the slower you go, the more accurate your positioning.  Overall in practice, if you are moving slowly and taking very light cuts, you can hold about 0.002".  0.005" is a more typical accuracy for general machining.  These numbers are the relative accuracy when machining a typical sized part (a few inches, say).

Then there is the absolute accuracy over the entire workspace.  Here, the accuracy depends on how square you assemble the axes, how level the table is, and how accurately you calibrate the exact number of TPI in the drive screws.

-Jeff

[yell...@gmail.com]

Jeff, thanks for the reply.  This give me a good feel for the capabilities of the LoboCNC.  I'm new to the whole CNC thing and I'm trying to figure out what I want to do. 

I've been thinking about getting one of the many Chinese X3 mini mill variants and doing a CNC conversion, but I've been pretty turned off by the requirement for a parallel port for most of the stepper controllers I've seen.  How many PCs have parallel ports these days?  Besides that, I have a laptop that wanted to use for the controller.  I'm intrigued with the closed loop servo control of your system and the ability to use the encoders for a digital read-out during manual operations.  Very cool.

I guess a 'perfect' system for me would have the stiffness, torque, and tool versatility of the X3 mini mill and the control system of the LoboCNC. 

So what components of the LoboCNC are open source?  I saw that source code for some of the software was available, but I did not see any mechanical design files or anything related to the controller hardware. 

Also, I'm a Linux weenie.  Do you know if anyone has done any porting to Linux?  Unfortunately, I'm not a software guy, so that's a bit beyond my skill level.  It would be nice if there were a Python implementation of the software... something that is more easily portable across platforms.  Is the controller interface simply a USB virtual comm port, or is it some other type of USB device driver?

Best regards.

Dave L.

[Jeff]

Everything except the firmware inside the PIC-SERVO SC controller chips is open source. All of the drawings (dxf and pdf formats) are available at http://jrkerr.com/lobocnc/parts.html. And the data sheet for the motor controller board (http://jrkerr.com/lobocnc/S3x3.pdf) includes a schematic. I'm happy to give you other document formats if you are interested.

Unfortunately, no Linux version of the G-code interpreter. All the code is in pretty vanilla-flavored C, so I'm hoping some intrepid soul will port it to Linux. (I'd also love to see a port to Android and iOS.)

As for the best machine for you - I think that mostly depends on what you want to do (and on your budget). I use two different milling machines myself: my Lobo mill and another much stiffer more conventional machine with ball screws and 30 taper spindle. For precision stuff in steel or aluminum, I use the stiffer, more precise machine. But the high speed spindle and larger work area make the Lobo mill my go-to machine for wood and most plastics. Interestingly, I also find the Lobo mill more convenient for working on sheet aluminum. Here's a link to a fun project I did on the Lobo mill that's pretty typical of what you can do:http://youtu.be/Xw-nMhwGAIE

-Jeff

[yell...@gmail.com]

Ah, I had opened the data sheet for the board, but didn't get to the schematic at the end.  So the controller is essentially a multi-drop serial bus with your PIC-SERVO SC parts at the endpoints. 

I may be interested in adapting the S3X3 design for controlling the X2 mini mill CNC conversion.  Here's a link that I've been looking at for the conversion on that mill.

http://makezine.com/2011/12/06/kit-review-mini-mill-cnc-conversion/

CNC Fusion makes the mechanical parts for the conversion, and the the article references a kit from Probotix for the motors and controllers.  They're using 280 ozIn steppers for X&Y axes, and a 400 ozIn stepper for the Z axis, which I think would be well beyond the capability of the S3X3 to drive. 

https://probotix.com/specs/HT23-280-8.pdf
http://www.probotix.com/specs/HT23-400-8.pdf

I am a EE, but I have no background in motor control at all.  Would a modification to the S3X3 design to handle bigger motors merely require spec'ing more powerful drivers, or is there more to it than that?  I believe I read somewhere (I think on one of your other motor control products) that you could use an external amplifier to drive the motor.

I've done some Python coding to talk to modbus instruments.  If I take this route I would probably be interested in pursuing  a Python code base that would be truly cross-platform. 

[Jeff]

You should be able to use the PIC-SERVO S3 controller chips can be used with any 8x microstepping driver chips, 1.8 deg. stepper motors and 400 line encoders.  I've used it with a couple of different Allegro microstepping drivers.  The PIC-SERVO S3 chips are a specially modified version of the standard PIC-SERVO chips - let me know if you are interested in getting some.

Note that the stepper motors they are using or hugely oversized.  With the 0.200" lead on the ball screws, 280 oz-in of torque will produce more than 500 lb of force!  The torque does drop off as you move at higher speeds, but realistically, some 120 oz-in steppers should be sufficient for a machine that size.

Regarding the software, I remember back in the day, C was the language of choice for cross-platform compatibility.  You should note that when it gets down to low level real-time control, where you need to pay attention to communication delays, etc. , I'm not sure that any code really works cross platform without some tweaking.  

One other option you might think about for Linux is operating the PIC-SERVO chips in Step & Direction input mode.  Then you could use something like LinuxCNC for the control.  Unfortunately, you then lose the DRO capability for manual machining, unless you wrote a separate DRO program.  (I've got a DRO program for WIndows, but not for Linux.)

[yell...@gmail.com]

Good feedback.  I appreciate it.  Having no experience with motor control I have no frame of reference for how the motors should be sized for this application.  

If the PIC-SERVO S3 parts are operated in servo mode (as opposed to step & direction mode), is there much of a requirement for real-time control?  The computer mainly just keeps the buffers fed, right? 

What would really be interesting would be putting the G code interpreter on the controller board and making it autonomous.  You generate the G code, then download the G code to the controller (USB, Memory stick, etc.).  I think this is essentially what many of the 3D printers are doing.  You could still have hooks for DRO and manual control.

After a bit of looking around I found the TinyG, which I think does essentially what I was talking about.  Pretty sure it just uses step & direction control.  It would cool to modify that to do true servo with the PIC-SERVO S3.

TinyG: https://www.synthetos.com/

I may not be making any sense.  I'm just getting into this and I need to understand the workflow better.  

[no...@nlbrewe.com]

I tried porting the g-code interpreter to the latest Borland/Embarkadero software and was making reasonable progress, but still haven't finished. I like the fact that the existing code runs in windows xp, windows 7, and windows 8 with no install needed. Since this is open-source software, it might be better to port to gcc or some free compiler instead of the Borland version which is pretty expensive. My goal in this effort is to understand more of the system, and to add the r form of arc specification for the interpreter. I worked out the math for the r-form and would use it to calculate the i,j,k values in the existing interpreter.

[yell...@gmail.com]

I'm no software guy, but maybe MinGW would be a candidate for an open source Windows development toolchain?  That may then make the port to Linux a somewhat smaller lift.


http://www.mingw.org/

MinGW, a contraction of "Minimalist GNU for Windows", is a minimalist development environment for native Microsoft Windows applications.

MinGW provides a complete Open Source programming tool set which is suitable for the development of native MS-Windows applications, and which do not depend on any 3rd-party C-Runtime DLLs. (It does depend on a number of DLLs provided by Microsoft themselves, as components of the operating system; most notable among these is MSVCRT.DLL, the Microsoft C runtime library. Additionally, threaded applications must ship with a freely distributable thread support DLL, provided as part of MinGW itself).

MinGW compilers provide access to the functionality of the Microsoft C runtime and some language-specific runtimes. MinGW, being Minimalist, does not, and never will, attempt to provide a POSIX runtime environment for POSIX application deployment on MS-Windows. If you want POSIX application deployment on this platform, please consider Cygwin instead.

Primarily intended for use by developers working on the native MS-Windows platform, but also available for cross-hosted use, (see note below -- you may need to follow the "read more" link to see it), MinGW includes:

• A port of the GNU Compiler Collection (GCC), including C, C++, ADA and Fortran compilers;
• GNU Binutils for Windows (assembler, linker, archive manager)
• A command-line installer (mingw-get) for MinGW and MSYS deployment on MS-Windows
• A GUI wrapper (mingw-get-inst) for the command line installer

MSYS, a contraction of "Minimal SYStem", is a Bourne Shell command line interpreter system. Offered as an alternative to Microsoft's cmd.exe, this provides a general purpose command line environment, which is particularly suited to use with MinGW, for porting of many Open Source applications to the MS-Windows platform; a light-weight fork of Cygwin-1.3, it includes a small selection of Unix tools, chosen to facilitate that objective.

[Jeff]

There's an interesting set of trade-offs in running the G-code interpreter on an embedded controller.  For 3D printing, where you typically start a print and then walk away for hours, this makes good sense.  Sometime you do that with CNC machining, but more typically, you are tending the process - applying coolant, changing cutting tools, adjusting feedrates.  (This is particularly true fro a small hobby machine.)  For this level of interaction, it is nice to have a real control panel with lots of feedback and all your controls visible.  I'm using a $200 netbook for controlling my machine, which for not much more money than an embedded controller and small LCD control panel, I've got a much more functional environment.

[no...@nlbrewe.com]

I'll check out MinGW. I would like to make the following additions to the software, which I like very much:

1. Arc using R format
2. Space bar stops movement as well as button
2. Be able to set x,y, and z to user specified values as well as set to 0.

Jeff, are you actively developing or working on this software now?

[Jeff]

I haven't worked on the software in a bit, but I should...

The additions you are looking to implement should be fairly straightforward, except fro the Arc format using R.  The problem with R format is that if the goal point is close to the starting point, the calculation for the location of the center becomes unstable.  That is, small deviations in the locations of the ends points, if close together, can cause the center point location to vary considerably.  This doesn't matter so much for doing arcs less than 180 deg. , but it can be disastrously wrong for arcs close to 360 degrees.  If I implement this, I would probably restrict it to arcs less than 180 degrees.

I'll try to get to these things over the weekend.  Pester me again if I don't post something here by Monday.

-Jeff