sherline, cnc, and masso

[RonGinger]

One thing (and probably more) that I forgot is spindle speed. What did you all do about that (if anything)?

Peter Homan offered a small add-in board to the Sherline speed controller that allowed computer control of speed.

I am not sure its worth it for a small machine. I led 3 classes at the CNC workshops a few years ago that built CNC conversions of the Little Machine Shop mills and lathes- we did 3 mill classes of 12 students and one lathe class for 14. We found it was simpler and more useful to simply use the machines speed knob manually. It is one less parameter you need to set and we found it best to run the program and tweak the speed knob if it needed it.

I would buy the CNC ready Sherline, then all the hardware is there except the motors. I would not buy Sherline motors, they are  under size and over priced. Get motors from AutomationTechnologiesinc.com

For steppers higher voltage is higher speed. Generally you want to use the highest voltage the driver can handle. 50v is Ok for the Gecko. I would use about 282oz-in motors on a Sherline, or whatever I can find at the lowest price in that range. DOnt go to high- say 400 oz-in or so and they become slower because of inertia.

I would probably select https://www.automationtechnologiesinc.com/products-page/nema-23/nema-23-bipolar-stepper-motor-quarter-inch-dual-shaft-with-flat-282-oz-in/. Duakl shaft lets you put the hand crank on the end. There are times when the machine powered off you simply want to move the table.

[awake]

I'll throw in a couple of comments, but PLEASE take what I say with a grain of salt (maybe a whole salt-shaker). On the one hand, my actual CNC experience is limited to building my own 3d printer from scratch, from the hardware up; on the other hand, I also have a good bit of experience with embedded systems based on early PC's (of various types - IBM, Apple, even Commodore). That experience, plus the fact that I use Linux exclusively, may offer some thoughts that may be relevant.

Comment # 1: "Parallel Port Translator" - this terminology reflects the persistence of a frightful and outdated kludge.

<TLDR warning ON>

Think of an early PC, circa mid-80's; in typical stock form, it had three or possibly four points of connection to the outside world: 1) A video output, 2) an RS232 serial port, 3) a parallel printer port, and 4) an audio port. Originally, each of these was provided through an interface card plugged into an expansion bus; over time, these were incorporated onto the motherboard.

Here's the key: Of all of these various I/O ports, the ONLY ONE that could be used for direct bit-level digital input/output was the parallel port. The early video outputs were analog only, and output only. Audio might have had both an input and an output, but again analog only. When used as intended, serial could send and receive any amount of information, but it was quite slow, AND - here's the key - there had to be some "smarts" on the other end of the line, essentially another computer, or at least a microcontroller, which was not particularly common or cheap at that time. "If used as intended" - but could it be used as direct bit-manipulated I/O? Possibly, but the way serial ports were implemented in hardware generally did not lend itself to such - and even if it did, it might use as few as two signal lines, one input and one output - and even if it had the maximum of half-a-dozen signal lines, they generally were fixed as input or output - and on top of everything else, all the signals ran at +/- 12V, not at the standard 5V digital logic that one typically needed.

But the parallel port, now, that allowed direct manipulation of at least 10 output bits and at least a couple of input bits - all of it running at 5V digital logic levels. Furthermore, the way the parallel port was almost always implemented in hardware, it was actually possible to configure any of the bits either as input OR output as desired. Thus, the PC could provide bit-level I/O, controlled solely by the smarts already in the PC - no additional microprocessors/microcontrollers needed. As a result, the parallel port became the go-to option for interfacing things to the PC that the PC designers had not originally intended or planned to be interfaced.

There was an alternative for achieving bit-level I/O controlled by the PC, and in one sense, it was very simple: just build a custom interface card. Many manufacturers did go that route, but that nearly always was for high-end equipment. Hobbyists already had the parallel port, and generally found ways to use it instead.

Thus was born the famous "parallel-port breakout board" that was used by hobbyists to run CNC machines. The PC did all of the work, generating the timing and sending out or reading the signals on the various individual bits, in order to generate pulse and direction signals to drive the stepper motors. There still had to be some additional hardware to translate these digital signals into the actual analog power outputs to the steppers - thus the Gecko or other stepper motor driver units. But even now, many of these have no smarts in them at all - they simply translate the digital signal into the appropriate analog power output.

So here we are, 35 years later. Nowadays, microcontrollers are ridiculously cheap, and serial communications have gotten incredibly fast - and the parallel port has disappeared as a standard option, because it is far more expensive to supply so many individual i/o lines than it is to supply a microcontroller at the other end of a serial connection. Of course, the serial connections in question are no longer the venerable RS232 with its +/- 12V signals, but rather various iterations of the USB port. Also standard with many PC's/laptops is an Ethernet port, which is at its heart a type of serial connection. Each of these expects to use a particular protocol, a particular set of "smarts," to handle the communication; neither is suitable for direct bit manipulation by the PC.

Ironically, many of the main "go to" options for the hobby CNC market are still implemented on the parallel port model of 35 years ago. Exhibit A is the Gecko G540, which is nothing more than a parallel port breakout board plus stepper motor drivers - as far as I can tell, no smarts at all, so it is depending on the PC to provide all the timing. Lacking a standard parallel port on a modern computer, people attempt to use a USB-to-parallel converter, but this is a device not even remotely akin to the bit-banging interface on which this whole now-ancient kludge depended.

Even more ironically, the accepted solution is to use a "smooth stepper" device, which has a microcontroller built in to handle either/both ethernet or USB connections ... and then translates them into - you guessed it - simulated parallel ports. At least these devices, as I understand it, take on the task of timing the pulses. But somehow we are still using the kludge of a parallel port to send the pulses on to the stepper drivers. Oi!

Further complicating the picture is that the modern OS is very, very, very different from the old systems on which this parallel-port approach was first built. In the old days, software running on a PC could be deterministic in its behavior - you knew exactly how long it would take for a given routine to complete. (Okay, that was not entirely true for the early IBM PC, with its interrupt-driven system for refreshing the DRAM, but now we're really down in the weeds!) Modern OS's, however, are multi-tasking, and the processors they run on use pre-fetch pipelines and predictive branching to wring out the last iota of speed. These factors make it more or less impossible to achieve deterministic behavior, and thus make it difficult to bit-bang the correctly timed pulses for smooth motion control. This is where the "smooth stepper" is headed in the right direction; the motions are commanded by the PC, but the microcontroller on  the smooth stepper handles the deterministic behavior needed to generate the correctly timed pulses. (Again, though, why it then sends these pulses out via a simulated parallel port ... !!)

Interestingly, the 3d printing hobby has taken a different approach. Rather than replicating the parallel port kludge, 3d printers have started with a microcontroller that will handle the deterministic bit-banging. This microcontroller typically has a USB port built in; alternately, it may have wifi or ethernet. A PC may be used to send the motion commands, or those commands may be stored in EEPROM (typically an SDRAM card) attached to the microcontroller. In either case, the microcontroller does not bother with simulating a parellel port interface - why bother? In the simplest 3d printers (e.g., those based on RAMPS or similar), the microcontroller attaches directly to the board that has the stepper drivers. For 3d printers, the stepper motors are relatively modest, so relatively low power stepper drivers will suffice. Alternately, one could feed the signals from the microcontroller board to high powered stepper drivers, or to servo drivers - generally these will be separate units, but the connection is a simple cable - no simulated parallel port needed, thank you very much.

Is there any reason to continue to perpetuate the parallel-port kludge? In my opinion, no; it is simply inertia. Interestingly, one sees the collision of the 3d printer approach and the old parallel-port kludge approach in the arena of CNC routers. Some of these are built around a parallel-port type approach, while others are built around something more like a 3d printer controller. If - when? - I do a CNC conversion of a mill or lathe, I would personally go with the latter. There are a few examples out there on the internet of folks who have gone this route - but only a few, compared to the vast sea of folks who are familiar with the parallel-port approach!

Whew! If you read all the way to the end of that lengthy dissertation, you might be a masochist. I'll put my other comment - much shorter - in a separate reply.

[awake]

Comment # 2: CAM / CAD, Linux vs. Windows / Mac

There are definitely more choices for CAD and CAM for Windows than for Linux, starting with Fusion 360, which many consider the best of the breed. I don't know about Macs, but assume there are some choices there.

For Linux, there are some viable choices; probably the best starting point is FreeCAD. Its CAM features (and actually, the whole package) is still a work in progress, but I have run across some tutorials that talk about using it for CAM.

In general, CAM is going to produce an output of g-code tailored to the specific features of the controller you will be using (Mach3/4, LinuxCNC, GRBL, etc.) You should be able to generate the g-code on one machine / OS, then take it / send it to the machine that actually runs the CNC equipment. Since g-code is just a text file, it doesn't matter if that machine is a different OS - or even a microcontroller, as described in my previous over-lengthy post - so long as g-code is in the proper "dialect" for that machine.

[zeeprogrammer]

Thanks Ron. Very helpful.
The reason why I'm going manual and then retro-fit (rather than getting the CNC-ready version) is that I expect it will be a while before I get a CNC system running and in the meantime I want to play with the machines. There's not that much cost difference in buying the CNC-ready versus manual and then modifying/retrofitting. Certainly, I can add the motors and then play before I get CNC going but I'd rather not have to turn through the motor.

Thanks Andy. Yeah, I started out with Apple II, IBM XT, IMSAI, Elf (not to mention my 1st program was written with Hollerith cards).

I see your point about the parallel port and have wondered myself why so many systems depend on it.
I haven't looked but it would seem a board that combines the driver (e.g. Gecko) and the "what I'll call translator" (e.g. SmoothStepper) would/should be available. If you know of such please point me to them. On the other hand, having separate boards allows (cheaper) swapping or to use each boards capabilities in separate different ways.

For me, when I hear 'parallel port' I immediately (and incorrectly) think of the D25 connector. It's really just a set of I/O pins which are necessary anyway regardless of how the information is sent to control them.

As a side note, many 3D printer boards have processing or port limitations that affect timing pulses (not to mention interrupts can also affect timing). Some boards, as the step rate increases, will switch from outputting one pulse per time tick to multiples of 2.

Also as a side note, I haven't looked to understand why USB appears to be a problem versus Ethernet. Perhaps isolation? When I worked on designs for banknote acceptors, sometimes my computer would reset as I plugged or unplugged USB. Some kind of ground loop I suspect.

Just saw your 2nd post Andy. Thanks!

[Hugh Currin]

Zee:

You could do something like this . That would allow buying CNC ready machines but using them manually for a time. Don't know the difference in cost but would avoid the trouble of switching parts for CNC.

FYI.

Thanks.

[Admiral_dk]

I have the Gecko 540 and it is a Parallel Port interface - and I would NOT buy it again ...!
If anybody would like to know why - one of the channels in it skips steps (the rest are fine), and I can't just change the single channel for a new unlike the other models from them. I was trying to go too their site for model info, but my Anti Virus will not allow me as the site is infected 

Gecko has other nice "Power Boxes" - the one that accepts Step & Dir signals, a power connection to the PSU (Power Supply Unit) and delivers this power to the Stepper Motor directly - and they do nice Servo Controllers too (same signals in, not to confuse with the Controller boxes I'm referring to in my previous posts).

AWAKE got through a lot of my arguments. The modern serious CNC controller has a Step & Dir output for each axis + all the other outputs and inputs you could need - but they usually can not drive the steppers directly as they do not have the power section.
I have just done a little search and I can see that there are a lot of boxes that has a Parallel Port output and to me those are also missing the point as we have to forget about it - as AWAKE mentions, it has served us well for a number of years without any better solutions, but it is completely outdated now.

USB can be nice - but I forgot another argument for an galvanic insulated interface and that is also protects the PC from being totally fried in case of serious mishaps ....

[Hugh Currin]

Their page on the G540 indicates it is made up of G250X stepper drivers. You may be able to replace a driver in the G540 using a G250X. Have you looked into this? I'd suggest contacting Gecko and see if it is possible.

Let us know. Thanks.

I have the Gecko 540 and it is a Parallel Port interface - and I would NOT buy it again ...!
If anybody would like to know why - one of the channels in it skips steps (the rest are fine), and I can't just change the single channel for a new unlike the other models from them. I was trying to go too their site for model info, but my Anti Virus will not allow me as the site is infected.

[DICKEYBIRD]

If you're tech savvy (hmm, yes you are) go with LinuxCNC/Mesa, etc, etc.  If you're not wanting to dive into Linux for whatever reason & want Windows, I strongly recommend a Centroid Acorn.  Too many advantages to blather about here but check them out before you plunk down cash.  I have 2 and love them, especially the encoder threading on the lathe:

https://www.centroidcnc.com/centroid_diy/acorn_cnc_controller.html

The forum and all the folks there are GREAT!  (The guys at Linux as well.)

https://centroidcncforum.com/viewforum.php?f=60

edit: Oh yeah, software & hardware from the same USA outfit...right here in good ol' Pennsylvania for 30 years!

[zeeprogrammer]

You could do something like this . That would allow buying CNC ready machines but using them manually for a time. Don't know the difference in cost but would avoid the trouble of switching parts for CNC.

I did consider that idea. Nice to know it's simple. Seemed odd to me that Sherline doesn't provide a way to do that. What I have to look into is whether/what kind of hand wheels come with the system.

Thanks Dickeybird. Looks interesting. Yet another shiny choice!

[kvom]

I had a nice talk with the Centroid Acord people at CF.  Looks like a nice way to go for under $300.

As for the Mesa card, it depends whether your mother board takes PCI or PCIe connectors.  In addition, you need to know whether you want the control to control the spindle speed, and what signal the motor wants.  The guys at Mesa can help sort that out and indicate which version of the firmware needs to be loaded to the card.

[zeeprogrammer]

At some point (soon!) I'll place orders to Sherline et.al.

My question is...should I stay on this thread or start one in "Tooling & Machines" or in "My Workshop"?
My goal would be to show the goodies, play with the machines manually, then log my trials, tribulations, successes, and melt-downs (oh there'll be at least one) as I add CNC.

I'm still somewhat stuck on spindle speed control. I understand Ron's point (i.e. probably not needed) but having some feedback as to RPM would seem nice.
But...little stuff can be added anytime.

[Hugh Currin]

Zee:

Two parts to this. 1) reading the speed the spindle is going and 2) being able to control the speed from the program.

You'll want to read spindle speed via an encoder for threading on the lathe. That should easily give an RPM display depending on software.

To control spindle speed you need to interface with the potentiometer on the Sherline motor control. See this thread particularly post #11 & #12. I haven't done this and would suggest you not worry about it till later.

I'm still somewhat stuck on spindle speed control. I understand Ron's point (i.e. probably not needed) but having some feedback as to RPM would seem nice.
But...little stuff can be added anytime.

[Mike R]

CAM: CamBam (Linux or Windows). The question is what else (free or cheap) is available. Must support lathe and mill. If Windows base can move output to a Linux based machine.

CAD: I have CubifyDesign and like it. Runs on Windows but output can be moved to a Linux based machine. I keep promising myself to look into Fusion360 but not happy with the cloud requirements.

If you can get over the cloud requirement then Fusion 360 becomes a real candidate for 2 things:
CAD and
CAM

Its a bit crazy how good it really is.  I used a copy of Pro Engineer WF4 for a long time (was used by my workplace) and it was a multi thousand dollar program, and I'm finding that Fusion 360 is beating it hands down on usability and functionality.  (workplace is using Solidworks now - another story)

The cloud bit - yes your data is in the cloud.  Took me a bit to accept this too, and the possibility it all goes poof one day!  But realistically, if you do things in a "serial" manner, you may eventually loose things you've done, but you don't really go back and do those things a 2nd time very often in the hobby. 
You don't go back and make the same thing 3 years later, so what is the real risk of having it cloud based?  Once I overcame this mental roadblock and embraced the "here and now" I was able to use Fusion 360 to do more than I ever could with previous programs.
If your fear is that your model could be pilfered by the Fusion people (or others) - then your working on things far more valuable than the hobby bits I'm playing with! If somebody finds my CAD models of somebody else's hand drawings from the 1950s worth stealing then so be it...I'm using Fusion360 for free as a hobbiest and if that is a risk - I'll take it.

The output from any CAM system has to be compatible with the control system chosen.  This is usually called "the post" (I believe for post processing) to convert the CAM programs language into the G code specific to your controller.  Just like any good language, there are dialects and each control system seems to understand the very basics ok but the details and accents if you will are different..
Most any CAM program will let you chose the appropriate post processor to create an output compatible with your controller,  and again these post processors are configurable as well. 
 
Spindle speed - any good interface card (i.e. ethernet based or USB - with on board pulse generation) should in my humble opinion have an analog output available for controlling spindle speed.  Now actually hooking that analog output (usually 0 to 10VDC) up to control your spindle becomes the challenge, but the control card should be capable.


Mike

[RonGinger]

Dont confuse parallel port with DB25 connector. A device like the smoothstepper or the gecko540 uses a 25 pin connector just because you need a bunch of  pins to do 4 axis control with step and direction. They are not parallel port in the sense of the old PC standard. The smoothstepper (or PMDX smartBOB) gets control information from Mach and generates the real time pulses needed to run steppers. Mach has a rather complicated API that involves a buffered scheme of commands to the motion device. The motion device provides pulses to a driver, which provide high current phase power to a stepper motor (or many servo motors that also use step/dir interface)

On my spindle motor comments, I agree the need to read spindle speed is required, I do not think the need to control the speed is required for mill. On lathe a full quadrature encoder is needed to do threading. Mach3 achieved threading with a single pulse per rev, but not highly reliable. Mach4 wants quad.

I looked at the acorn at Cabin Fever and found the screen very cluttered. One of the most brilliant features of Mach3 and 4 is a screen editor that allows fully customized screens. In many case thats why Mach3 is still selling way beyond its end of development- people have grown attached to certain screen designs.

[MJM460]

Hi Zee, I have been following this thread since you started it, and am finding it most instructive. Thank you for kicking it off.  And thank you to all those who have contributed to making it so instructive.

I am finding it a great summary of all the things I knew that I did not know about CNC, and feel it would be a  great help if I ever decide to take the plunge.  Of course I still don’t know what I don’t know, and I feel the thread might have a bit to run.  To me it deserves a sticky at the top of the board, depending on what others think.

On that basis I would suggest maintaining this thread as an overview which I think will be extremely helpful to others regardless of the specific path they choose to follow, and starting a new thread on either of the boards you mentioned to log your particular adventures once you start.  However the specific place you make the break is a grey area, as your initial steps will almost certainly clarify or amplify some of the questions you have raised.  And certainly will raise more.  Maybe two threads have a continuing place.

I am certainly looking forward to seeing how you go and looking forward to not only first chips, but to see how far you can take it.

MJM460