Stepper Options

[109jb]

You DO NOT have .0001" resolution. You cannot count micro stepping to increase resolution.

Re-read and understand my post. I said theoretical right in my post because I do understand this.

Your linear mechanics have error as well . Something the encoder on the motor cannot compensate for.

That is what screw mapping takes care of and has nothing to do with whether a rotary encoder would detect an error in the commanded rotary position.

Having an encoder on an axis for absolute positioning so it has to move to a given spot and stop is a useful design. Trying to use it in a PID servo type loop is less so. It's your money and your idea. Its obvious you are a man of conviction and like to plow your own fields. Go for it. If you want high accuracy you go with servos , high encoder counts, precision slides and precision anti-backlash ballscrews. Gantry mass is important to prevent flexing. All costly, but high accuracy has high costs.

Nobody said anything about using the encoder for a PID servo type loop. Only for error detection and to throw a fault stopping machine motion if a deviation is detected which is quite simple on LinuxCNC and has been done by others using steppers and rotary encoders

Having cut literally hundreds of miles of aluminum with both steppes and servos I can tell you this: As soon as a bit starts to clog , about 1.5 seconds later it either snaps off (if its smaller) or makes a cut that looks like you cut it with a chisel! So there is no making up lost steps it will simply finally stop motion.

Again, you are misinterpreting my post and how I intend to use the encoders. I do not intend to "make up lost steps". Only to detect when the motor shaft isn't where it is supposed to be and stop everything. I am not trying to get it back to position.

[109jb]

There are so many things wrong with that argument, I wouldn't even know where to begin. It is clear you do not really understand how stepper motors work, nor how using encoders to detect "lost steps" is actually implemented. You will NEVER be able to detect one of your theoretical 0.0001" "lost steps", even it if were possible to "lose" a 0.0001" step (which it is most definitely not). And if you did somehow manage to build a system that could detect such a small loss, it would be constantly false-tripping due to following error alone. In reality, you'd be lucky to reliably detect even a 0.003" static position loss. And I can assure you a 0.003" loss is easy to detect visually.

So if you have a pocket that is 2.997" long and it is supposed to be 3.000" long, you can detect that VISUALLY?

I suggest you spend a lot of time reading and researching how stepper motors really respond, in the real world, where things like friction, stiction, inertia, and other physical factors interfere with the "theoretical". Learn how a real stepper motor responds to micro-stepping, and you'll realize even talking about 0.0001" is ridiculous. Factor in the real-world characteristics of the machines being talked about here, and it becomes downright ludicrous. Learn that micro-stepping has virtually nothing to do with increasing resolution, but is, rather, used primarily to reduce resonance at low-to-moderate speeds, and that many drivers automatically switch to full-step mode at higher step rates.

Why is it that everyone has to pick this out. I said theoretical exactly because I know it isn't real. It was only to depict how the machine is set up.

And, if I follow your argument, I am wrong to suggest that I can tell if my open-loop machine is losing steps, because I can't possibly detect a 0.0001" position error, but you are going to allow a 0.005" position error on your machine before you trip a fault? Do you see a logical contradiction there? How is a 0.005" position loss acceptable, when a 0.0001" loss is not? How do you suppose you are likely to ever achieve a 0.005" position loss without stalling the motor? The fact is, with steppers, once you've lost a single step while moving at anything other than extremely low speed, the motor is almost guaranteed to stall. THAT is easily detected without encoders.

I see no contradiction at all. What is acceptable is dependent on what you are making. A 0.005" detection error for the types of parts I usually make would mean that a fault at 0.005" would likely mean I would be able to change a tool or whatever, re-home, and then save the part. 0.005" would also insure that no further damage is done to machine, fixtures, etc.

Finally, consider this: If simply adding inexpensive encoders to a stepper motor (and decent optical encoders can be bought for a few $ now) has such wonderful, wide-ranging benefits, why is it so very, very rarely done, even in the industrial world, where cost is not nearly as much of an issue as it is here? A great many extremely high-precision machines use open-loop steppers, with virtually 100% reliability.

I never said that a machine with steppers without encoders wouldn't work or that it is necessary, I only said that it is "not totally useless"

[eldata]

Anyone from the open loop stepper (OLS) tribe, who embraces artifacts normally used in servo tribe rituals, should be banished forthwith from the OLS tribe. Seriously though, an encoder can be had for around $24.00 these days, also, purchasing dual shaft stepper motors would be the foundation for a servo setup further down the road if so desired. Even adding another shaft to an existing single shaft stepper motor is possible if one has a suitable lathe and the aptitude. I used to add shafts to tiny BDC motors back in the day.

Answering the "Why would one want to do this?" question would probably be similar to answering the "Why would anyone want to use servos instead of OLSs?" question.

[RCaffin]

And to think, encoders used to cost hundreds of dollars - once.
Hum ... capacitive rather than optical? Interesting.

Cheers
Roger

[eldata]

And to think, encoders used to cost hundreds of dollars - once.
Hum ... capacitive rather than optical? Interesting.

Cheers
Roger

But one still gets what they pay for to a certain extent. Those CUI encoders, although suitable, have jitter causing slop between shaft adapter teeth and hub grooves which not only varies from sample to sample but increases with each mount/removal cycle (to change resolution for example). It should come as no surprise that they cite the following;

We recommend no more than three cycles of mounting and
removal of the AMT top cover base. Multiple cycles of mounting
and removing the top cover can cause base fatigue over time
and affect encoder performance.

Optical encoders, using screws instead of snaps and with the disc fixed to the shaft similar to a pulley, have no such slop/jitter issues.

[RCaffin]

Hi eldata

Yessss - I can imagine. Thanks for the warning.

I originally used HP optical encoders on servo motors, but that was 20 - 30 years ago. They still work just fine. Alignment is still good.
And the HEDS 5540 optical encoders I am using now are also just fine.
Hum ... differential line drivers would have been nice of course, but they can be added 1" away. It works.

Cheers
Roger

[eldata]

Yeah, HEDS or US Digital equivalents would be best for a more refined servo experience but for validating OLS integrity, like what 109jb has in mind, the CUI encoders should be more than suitable. I use them for R&D work in a similar manner.

[Torchhead]

Nobody said anything about using the encoder for a PID servo type loop.

Actually the original Post was about that and the basis for the comments , and it was your post that changed it to stop-on-loss rather than correction.

And "theoretical" was not ignored....the whole thing is theoretical and the proper numbers need to be argued (even in a theory) not some meaningless resolution that is not there.

[NIC 77]

In my limited experience (I have built one CNC and am building a second), I haven't had many opportunities to try out different systems.

On my first build I used Gecko G201X drivers, never lost any steps, I believe that adding encoders to the steppers would have added no value. It would have been a waste of $$$.

I'll be using the same G201X on my current build, but for my forth axis I will go with either a Leadshine (because of the $$, and because I have read good reviews on here) or perhaps an MDrive, which has the driver built in, because I know where I can get some N34 MDrives at a good price local to me in Canada.

I'm guessing the automation technologies drivers are good quality too, I just don't have any personal experience and haven't read any specific reviews on them. I was under the impression that they are made by leadshine, and I think that you and Ger believe this as well, so from what I've read, they would be a good choice.

As far as the motors go:

I'm not very familiar with this conversion you are doing, I googled it, so I have a little bit of an idea. From what I found, looks like a mini mill with 0.2" lead ball screws, so about 5mm. Is that correct? And what kind of speeds and acceleration do you want to achieve? Do you want to do some high speed machining with this? In my view, these are the appropriate questions to ask, more relevant than using encoders or not.

This conversion uses two nema 23 size and one nema 34, is that correct? So with 0.2" lead you'd want something with good performance at higher speeds (sufficient torque), low inductance. Have a look at the torque vs speed graphs and inductance value. Also the higher the power supply voltage, the better the performance at higher speeds, while you may never use the max amp draw at lower speeds and at higher speeds, your motors can't draw max amps. It depends on how fast you want to drive this machine.

As this is a common conversion, the easiest thing to do is to find someone who has achieved good results and copy what they did for motor selection.

In your shoes, on this project, I would be tempted to look on EBay, and see if I could find two Nema 23 MDrives, and one Nema 34 MDrive at a good price. Those are "smart" motors with good drivers built in.

Schneider Electric MDO1PSD23A7 MDrive23 Plus +12-75VDC Stepper Motor + Driver | eBay

I'm guessing the specs for those are found here:

https://motion.schneider-electric.co...-control-ip20/

At 75V, the single stack torque vs speed is almost flat at goes to 2000 RPM, looking at the numbers, I'm guessing that would work for you on X and Y. How heavy is the table on this mill? Anyhow, that's what I'd do. The higher torque at lower RPMs doesn't help if you never use it and don't have the torque at higher RPMs. I'm guessing you could get 300 to 400 IPM max speed with 0.15 to 0.2G accel using these on X and Y with a table that is less than 150 lbs all up weight, and a lead of approx 5mm, but that is just an initial guess.

If you want a sense of how other motors might perform, then find a torque vs speed graph for them and post it.

And here is a Nema 34

New IMS MDrive34 MDOF3424 Nema34 Stepper Motor w/ Built-in Driver - CNC Rep Rap | eBay

[RCaffin]

Hi NIC 77

As far as I can see (because the data sheets are seriously lacking in explanations), those MDrives use a serial RS488 interface. IF (IF) that is correct, they would be totally incompatible with any modern CNC controller such as Mach3, Mach4, UCCNC, LinuxCNC, etc. They would belong to a generation from 50 years ago. But I may be wrong: perhaps they do accept the modern Step/Dir signals. Do you know?

I use a G203V driver on one stepper - very happy. For the rest I use G320 servo drivers on Baldor DC motors. Unstoppable.

Cheers
Roger

[jfong]

Nic77

Need to be careful when choosing Schneider/IMS motor drives. Not all of them support standard step and direction inputs. Need to look at the datasheet.

I just picked up a pair of applied Motion TSM motors to test. Stepper servo with high resolution encoders.

[NIC 77]

Hi NIC 77

As far as I can see (because the data sheets are seriously lacking in explanations), those MDrives use a serial RS488 interface. IF (IF) that is correct, they would be totally incompatible with any modern CNC controller such as Mach3, Mach4, UCCNC, LinuxCNC, etc. They would belong to a generation from 50 years ago. But I may be wrong: perhaps they do accept the modern Step/Dir signals. Do you know?

I use a G203V driver on one stepper - very happy. For the rest I use G320 servo drivers on Baldor DC motors. Unstoppable.

Cheers
Roger

Nic77

Need to be careful when choosing Schneider/IMS motor drives. Not all of them support standard step and direction inputs. Need to look at the datasheet.

I just picked up a pair of applied Motion TSM motors to test. Stepper servo with high resolution encoders.

I haven't heard this before. I honestly don't know the answers. I haven't used them. It was my understanding that you provide the same inputs you do to any stepper driver. Now that some doubt has been indicated, I would like to know the answer! Perhaps you gentlemen or someone else can educate us before I display too much of my ignorance on the internet?

Here is a video I found on Youtube



To me, it looks just like the one in the first add.

I posted a link to the datasheet. With the drivers built in, if it works with a regular board, these would be a good choice, IMO.

[109jb]

All I ever said is that I don't regard encoders on steppers as totally useless as was stated by another user.

A rotary encoder can be bought for about $15, and LinuxCNC can read them through a $6, or surplus parallel port card. If you are like me and play around with 3D printers you can print up some simple mounts and for about $50 you can have a system that can detect lost steps and stop the machine. If a step is never lost then the machine never faults. In my opinion the peace of mind, and the education of doing it is worth the $50. It is also a lot cheaper to do this than to change to a closed loop stepper or servo system. If you disagree then fine, don't add encoders to your steppers

[RCaffin]

Using an encoder on a stepper to AUTOMATICALY pick up faulting seems fine to me. After all, you may not always be right beside the machine if it is on a 6 hour run.
But I would suggest that one should keep the fault-detection stuff outside the main computer - mostly because I don't know of any (modern) CNC programs which can handle that. But they can all handle an eStop signal.
-----------------
The MDrives - an interesting thing. Way back in the dark ages CNC machines had lots of dedicated electronics (huge boards of chips) but no 'PC controller'. One compromise to handle this was to drive the CNC in a completely different way: you sent a message to the X motor controller to tell it to go to point X at speed S with accel and decell as specified. Then you sent a similar message to the Y axis controller, and then to the Z axis controller. Then you broadcast a Start signal. All this communication was done over SERIAL lines. That was fine for a straight line move, but it could not handle arcs and spirals. In effect, that was back in the days of crank-starting your motor car. Today we have starter motors ... and tomorrow electric cars ...

But some older companies had thriving product lines for ancient machines, and they are unwilling (or too short-sighted) to replace that older technology with more modern concepts. They are scared of abandoning a dying product line. The result is that they are being replaced by more modern companies with more modern concepts and hardware (at a lower cost). It is what happens in any technology.

What will replace a PC controller and the Step/Dir interface in the future? Dunno. Could be a long while though.

Cheers
Roger

[109jb]

But I would suggest that one should keep the fault-detection stuff outside the main computer - mostly because I don't know of any (modern) CNC programs which can handle that. But they can all handle an eStop signal.

On quick thought, what you suggest should be able to be done outside the main computer using a microcontroller such as an Arduino by having the microcontroller count steps commanded as well as encoder position.

I don't know if you regard LinuxCNC as a modern controller, but LinuxCNC can do what I propose. For a hobby machine it works great, and even for non-hobby it works well and has tons of user definable functionality, although not user friendly if you deviate from what the setup wizards can handle. It can do the fault on missed steps through parallel port with the only reason for needing a second parallel port being the need for additional input pins.

[RCaffin]

Arduino - yes.

LinuxCNC - yes. (Probably anything fully based on the NIST Standard.)

Cheers
Roger

[jfong]

All I ever said is that I don't regard encoders on steppers as totally useless as was stated by another user.

A rotary encoder can be bought for about $15, and LinuxCNC can read them through a $6, or surplus parallel port card. If you are like me and play around with 3D printers you can print up some simple mounts and for about $50 you can have a system that can detect lost steps and stop the machine. If a step is never lost then the machine never faults. In my opinion the peace of mind, and the education of doing it is worth the $50. It is also a lot cheaper to do this than to change to a closed loop stepper or servo system. If you disagree then fine, don't add encoders to your steppers

LinuxCNC reading quadrature encoder signals with a parallel port might be a little slow. It's probably reliable to about 25khz pulses, only good for low resolution encoders. Better yet would be one of the Mesa FPGA cards. The FPGA can be programmed with quadrature counters with digital filtering. I've done that with Xilinx FPGA's.

Microchip has some micro controllers that have built in quadrature decoders. Really easy to use. Good for several MHz counting. I don't think Atmel has mcu that has built in quadrature but the last time I looked was a couple years ago. You would have to do the counting with hardware interrupts which is good for about 200khz on a atmega328

I have C code and Verilog fpga quadrature code if you need them.

[NIC 77]

So I spent a few minutes on this

https://motion.schneider-electric.co...-control-ip20/

Above is the part # data sheet from the first EBay add I posted a link to. The same data sheet I posted earlier. So this is for "MDI1" It says for

Control Type = Programmable Motion Control
# of I/O = 4 I/O points, programmable as sinking outputs or sinking and sourcing inputs
Logic Range = Inputs and outputs tolerant to +24 VDC, inputs TTL compatible

And then below is the data for "MDM1"

https://motion.schneider-electric.co...on-input-ip20/

Control Type = Step/direction input
Control Method = Clock and direction inputs
P1 Connector Options = Power & I/O Flying Leads, Pluggable, Wire Crimp

So good call guys. Looks like you need to pick the correct one.

I'm pretty good at looking at torque vs speed curves and doing the math with inertia and lead, etc., but I can miss things on the electronics side. Certainly, the feedback from RCaffin, and jfong, was appropriate, so again, good call guys.

The MDrives - an interesting thing. Way back in the dark ages CNC machines had lots of dedicated electronics (huge boards of chips) but no 'PC controller'. One compromise to handle this was to drive the CNC in a completely different way: you sent a message to the X motor controller to tell it to go to point X at speed S with accel and decell as specified. Then you sent a similar message to the Y axis controller, and then to the Z axis controller. Then you broadcast a Start signal. All this communication was done over SERIAL lines. That was fine for a straight line move, but it could not handle arcs and spirals. In effect, that was back in the days of crank-starting your motor car. Today we have starter motors ... and tomorrow electric cars ...

But some older companies had thriving product lines for ancient machines, and they are unwilling (or too short-sighted) to replace that older technology with more modern concepts. They are scared of abandoning a dying product line. The result is that they are being replaced by more modern companies with more modern concepts and hardware (at a lower cost). It is what happens in any technology.

What will replace a PC controller and the Step/Dir interface in the future? Dunno. Could be a long while though.

Cheers
Roger

Roger, are you saying that Schneider Electric MDrive is older technology with a dying product line? Or is this a general statement referring to something else?

There are many reasons why you could have different control inputs. Their target market could be factory automation for some models, for example, move a beer bottle over, wait for it to be filled, move it back.

It was my understanding that the MDrive was a step up from traditional steppers. These are "smarter" steppers with built in drivers optimized for the motors. From what I've seen in videos, you can't loose steps on these motors, they will adjust the speed if the load is too great. If the OP can find an appropriate model on EBay, I think that would be a good choice.

As far as why they aren't widely used, I think it is because unless you find a great EBay deal, they are alot more $$$ to buy direct than a traditional setup.

Correct me if I'm wrong.

With the Nema 23 steppers most are really not a good match with small mills. The 150 oz to 300 oz range are a little small so only a few are larger and most have fairly high inductance so are poor at high speed unless you run a 80V driver.

The one stepper that stands out is the 570oz 5A stepper. It has a really low inductance so is way faster at high speed and has more power than you need.

Run it at 4A on the X and Y and you will get 150 IPM at 50V all day long.

Really no reason to spend more. For normal use it will be fast and you should never loose steps.

Best stepper ever.....

For small mills at 50V

I don't think 150 oz to 300 oz is a little small for this kind of application, but that would only hold true if the inductance was low and they could hold torque over a long speed range. Obviously, the ones you have looked at don't do this, and at speed they don't have what is needed.

Really, you're looking at less than 100 oz in that is needed at final speed for a small mill. The initial torque at low speed doesn't matter, you won't use it. Of course, this depends on the lead you are using. That's why I mentioned the MDrive as being a potentially good choice. It has low torque but a fairly flat curve to a high RPM. The ballscrew inertia and motor inertia are low, and at accelerations 0.2G and below, not much torque is needed as far as I can tell, unless my initial look has missed something.

I don't see the OP ever using anywhere near the 570 oz in at low RPM on X and Y, however with a low inductance, and at 50V, I absolutely do not in any way disagree that this could be an excellent overall choice based on performance at higher RPMs.

Do you have a torque vs speed graph for comparison to other options?

Really, not disagreeing with you in any way, just pointing out that it is only the torque available at top end speed that bears relevance, which I'm guessing you know well, but the OP might be questioning. If you disagree, let me know.

As far as the discussion about encoders is concerned,

Well, I wouldn't bother with it, so I agree with Ger21 on that, but as 109jb has stated perhaps it's not much money, and if you want to do it, well, why not.

I don't see alot of value added, but.....some interesting points all around.

Certain jfong has a good insight into how electronics work, far better than mine. Really, all of the interested parties' comments are from people whos opinions I value based on other threads I have read or participated in.

I was thinking, didn't Jim Dawson say he had some kind of linear encoder in his machine with his custom control software? Probably not relevant, but interesting nevertheless.

I really wouldn't worry about encoders on steppers, but if the price isn't prohibitive, well you could, and if you can find a deal on a "smart" stepper like an MDrive, well, you could do that instead, or, you could just get the steppers that arizonavideo said, and those have proven to give a good result.

[jfong]

Plenty of Schneider and similar types of drives are used in industrial machines. You wouldn't really see them in CNC mill/gantry type machines (you certainly could) but mostly in manufacturing type assembly lines. Basically moving something from point A to B all day long. They sometimes use industrial communications systems like CANbus, rs485 etc which are better immune to noise on a factory floor. You wouldn't want to run 5volt step/direction signals hundreds of feet. Lots of specialized applications for these types of integrated motors/drives. They are usually connected to PLC controllers.

You can also query the motor for info such as what position, motor temperature, any errors since the communication interface is bi-directional. You can't do that through just step/direction.

Not all of the Schneider mdrive product line have closed loop encoders on them. They all have smart controllers but some are only open loop. Again check datasheet and interface options. We used to use these motors at my old old job.

My newest eBay toy are Applied Motion TSM stepper motors with closed loop encoders. Full PID servo capability. RS485, analog and step/direction. Going to use them for a 3d printer.

[109jb]

LinuxCNC reading quadrature encoder signals with a parallel port might be a little slow. It's probably reliable to about 25khz pulses, only good for low resolution encoders. Better yet would be one of the Mesa FPGA cards. The FPGA can be programmed with quadrature counters with digital filtering. I've done that with Xilinx FPGA's.

Microchip has some micro controllers that have built in quadrature decoders. Really easy to use. Good for several MHz counting. I don't think Atmel has mcu that has built in quadrature but the last time I looked was a couple years ago. You would have to do the counting with hardware interrupts which is good for about 200khz on a atmega328

I have C code and Verilog fpga quadrature code if you need them.

Agreed. I was just pointing out the lowest cost method. I bought some 100 ppr encoders and have a parallel port to test. With 4x encoding and 0.2" pitch screws each encoder count would "theoretically" be 0.0005". My initial plan will be to detect if the actual position is off more than 10 counts (0.005") from the commanded position, and if greater, halt the machine. With 400 counts per rev, 0.2" per rev, and my maximum rapids of 150 ipm, I should only be at 5 kHz on the encoder inputs so I think should be ok with parallel port. Time will tell, but right now I have so little time to do anything in the shop so it will be a while.